text:
Characters overlap sometimes with colored characters

Windows Terminal version
1.17.11461.0
Windows build number
19045.3448
Other Software
WSL 2
Steps to reproduce
This bug happens quite randomly, but I have noticed that it happens the most when there is colored text. The below screenshot is one example. You can see the colon after my username and the last dollar sign overlap with other characters. The font used is Monocraft, but this happens with almost any font, including the built-in ones.

The prompt string is ${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
Steps to reproduce:

Login to WSL.
cd to a relatively long path while having a colored prompt string. The longer the path, the more obvious the overlapping is.
Observe that some characters overlap with other characters.

Note that this doesn't only happen to prompt strings. I've also noticed this happening, for example, when installing npm packages when the output has colored text. Also, note that echoing that prompt string with colors directly doesn't cause this bug.
Expected Behavior
The characters don't overlap.
Actual Behavior
The characters overlap.

If you update Windows Terminal to 1.18, you can open the settings dialog (Ctrl+,) and navigate to the Rendering section on the left. There should be a toggle labeled with "AtlasEngine". If you enable it and restart the application it should be fixed. Let me know if that worked for you!
(AtlasEngine will be the default text renderer in a future version.)

Downloaded 1.18.2681.0 and it still looks the same.

Hmm I didn't quite expect that… What's your display scale, font family and font size? I'll try to reproduce it locally.

I am not sure what you meant by display scale so here's the whole settings.json:
{
    "$help": "https://aka.ms/terminal-documentation",
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "actions":
    [
        {
            "command": "paste",
            "keys": "ctrl+v"
        },
        {
            "command":
            {
                "action": "copy",
                "singleLine": false
            },
            "keys": "ctrl+c"
        },
        {
            "command": "find",
            "keys": "ctrl+shift+f"
        },
        {
            "command":
            {
                "action": "splitPane",
                "split": "auto",
                "splitMode": "duplicate"
            },
            "keys": "alt+shift+d"
        }
    ],
    "alwaysShowTabs": true,
    "autoHideWindow": false,
    "copyFormatting": "none",
    "copyOnSelect": false,
    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
    "experimental.rendering.forceFullRepaint": false,
    "experimental.rendering.software": false,
    "firstWindowPreference": "defaultProfile",
    "focusFollowMouse": true,
    "language": "en-US",
    "launchMode": "maximized",
    "newTabMenu":
    [
        {
            "type": "remainingProfiles"
        }
    ],
    "profiles":
    {
        "defaults":
        {
            "adjustIndistinguishableColors": "indexed",
            "antialiasingMode": "grayscale",
            "backgroundImage": null,
            "bellStyle": "none",
            "colorScheme": "One Half Dark",
            "cursorShape": "bar",
            "elevate": false,
            "experimental.retroTerminalEffect": false,
            "font":
            {
                "face": "Monocraft",
                "size": 11.0,
                "weight": "normal"
            },
            "intenseTextStyle": "all",
            "opacity": 100,
            "padding": "8",
            "useAcrylic": true,
            "useAtlasEngine": true
        },
        "list":
        [
            {
                "commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -nologo",
                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
                "hidden": false,
                "name": "Windows PowerShell"
            },
            {
                "commandline": "%SystemRoot%\\System32\\cmd.exe",
                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
                "hidden": false,
                "name": "Command Prompt"
            },
            {
                "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
                "hidden": false,
                "name": "Azure Cloud Shell",
                "source": "Windows.Terminal.Azure"
            },
            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": true,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl"
            },
            {
                "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc"
            },
            {
                "guid": "{2ece5bfe-50ed-5f3a-ab87-5cd4baafed2b}",
                "hidden": false,
                "name": "Git Bash",
                "source": "Git"
            }
        ]
    },
    "schemes":
    [
        {
            "background": "#0E1019",
            "black": "#232323",
            "blue": "#008DF8",
            "brightBlack": "#444444",
            "brightBlue": "#0092FF",
            "brightCyan": "#67FFF0",
            "brightGreen": "#ABE15B",
            "brightPurple": "#9A5FEB",
            "brightRed": "#FF2740",
            "brightWhite": "#FFFFFF",
            "brightYellow": "#FFD242",
            "cursorColor": "#FF0018",
            "cyan": "#00D8EB",
            "foreground": "#FFFAF4",
            "green": "#8CE10B",
            "name": "Argonaut",
            "purple": "#6D43A6",
            "red": "#FF000F",
            "selectionBackground": "#002A3B",
            "white": "#FFFFFF",
            "yellow": "#FFB900"
        },
        {
            "background": "#101116",
            "black": "#101116",
            "blue": "#00B0FF",
            "brightBlack": "#686868",
            "brightBlue": "#6871FF",
            "brightCyan": "#60FDFF",
            "brightGreen": "#5FFA68",
            "brightPurple": "#D682EC",
            "brightRed": "#FF6E67",
            "brightWhite": "#FFFFFF",
            "brightYellow": "#FFFC67",
            "cursorColor": "#76FF9F",
            "cyan": "#76C1FF",
            "foreground": "#00A2FF",
            "green": "#00FF9C",
            "name": "Blue Matrix",
            "purple": "#D57BFF",
            "red": "#FF5680",
            "selectionBackground": "#C1DEFF",
            "white": "#C7C7C7",
            "yellow": "#FFFC58"
        },
        {
            "background": "#0C0C0C",
            "black": "#0C0C0C",
            "blue": "#0037DA",
            "brightBlack": "#767676",
            "brightBlue": "#3B78FF",
            "brightCyan": "#61D6D6",
            "brightGreen": "#16C60C",
            "brightPurple": "#B4009E",
            "brightRed": "#E74856",
            "brightWhite": "#F2F2F2",
            "brightYellow": "#F9F1A5",
            "cursorColor": "#FFFFFF",
            "cyan": "#3A96DD",
            "foreground": "#CCCCCC",
            "green": "#13A10E",
            "name": "Campbell",
            "purple": "#881798",
            "red": "#C50F1F",
            "selectionBackground": "#FFFFFF",
            "white": "#CCCCCC",
            "yellow": "#C19C00"
        },
        {
            "background": "#012456",
            "black": "#0C0C0C",
            "blue": "#0037DA",
            "brightBlack": "#767676",
            "brightBlue": "#3B78FF",
            "brightCyan": "#61D6D6",
            "brightGreen": "#16C60C",
            "brightPurple": "#B4009E",
            "brightRed": "#E74856",
            "brightWhite": "#F2F2F2",
            "brightYellow": "#F9F1A5",
            "cursorColor": "#FFFFFF",
            "cyan": "#3A96DD",
            "foreground": "#CCCCCC",
            "green": "#13A10E",
            "name": "Campbell Powershell",
            "purple": "#881798",
            "red": "#C50F1F",
            "selectionBackground": "#FFFFFF",
            "white": "#CCCCCC",
            "yellow": "#C19C00"
        },
        {
            "background": "#282C34",
            "black": "#282C34",
            "blue": "#61AFEF",
            "brightBlack": "#5A6374",
            "brightBlue": "#61AFEF",
            "brightCyan": "#56B6C2",
            "brightGreen": "#98C379",
            "brightPurple": "#C678DD",
            "brightRed": "#E06C75",
            "brightWhite": "#DCDFE4",
            "brightYellow": "#E5C07B",
            "cursorColor": "#FFFFFF",
            "cyan": "#56B6C2",
            "foreground": "#DCDFE4",
            "green": "#98C379",
            "name": "One Half Dark",
            "purple": "#C678DD",
            "red": "#E06C75",
            "selectionBackground": "#FFFFFF",
            "white": "#DCDFE4",
            "yellow": "#E5C07B"
        },
        {
            "background": "#FAFAFA",
            "black": "#383A42",
            "blue": "#0184BC",
            "brightBlack": "#4F525D",
            "brightBlue": "#61AFEF",
            "brightCyan": "#56B5C1",
            "brightGreen": "#98C379",
            "brightPurple": "#C577DD",
            "brightRed": "#DF6C75",
            "brightWhite": "#FFFFFF",
            "brightYellow": "#E4C07A",
            "cursorColor": "#4F525D",
            "cyan": "#0997B3",
            "foreground": "#383A42",
            "green": "#50A14F",
            "name": "One Half Light",
            "purple": "#A626A4",
            "red": "#E45649",
            "selectionBackground": "#FFFFFF",
            "white": "#FAFAFA",
            "yellow": "#C18301"
        },
        {
            "background": "#002B36",
            "black": "#002B36",
            "blue": "#268BD2",
            "brightBlack": "#073642",
            "brightBlue": "#839496",
            "brightCyan": "#93A1A1",
            "brightGreen": "#586E75",
            "brightPurple": "#6C71C4",
            "brightRed": "#CB4B16",
            "brightWhite": "#FDF6E3",
            "brightYellow": "#657B83",
            "cursorColor": "#FFFFFF",
            "cyan": "#2AA198",
            "foreground": "#839496",
            "green": "#859900",
            "name": "Solarized Dark",
            "purple": "#D33682",
            "red": "#DC322F",
            "selectionBackground": "#FFFFFF",
            "white": "#EEE8D5",
            "yellow": "#B58900"
        },
        {
            "background": "#FDF6E3",
            "black": "#002B36",
            "blue": "#268BD2",
            "brightBlack": "#073642",
            "brightBlue": "#839496",
            "brightCyan": "#93A1A1",
            "brightGreen": "#586E75",
            "brightPurple": "#6C71C4",
            "brightRed": "#CB4B16",
            "brightWhite": "#FDF6E3",
            "brightYellow": "#657B83",
            "cursorColor": "#002B36",
            "cyan": "#2AA198",
            "foreground": "#657B83",
            "green": "#859900",
            "name": "Solarized Light",
            "purple": "#D33682",
            "red": "#DC322F",
            "selectionBackground": "#FFFFFF",
            "white": "#EEE8D5",
            "yellow": "#B58900"
        },
        {
            "background": "#000000",
            "black": "#000000",
            "blue": "#3465A4",
            "brightBlack": "#555753",
            "brightBlue": "#729FCF",
            "brightCyan": "#34E2E2",
            "brightGreen": "#8AE234",
            "brightPurple": "#AD7FA8",
            "brightRed": "#EF2929",
            "brightWhite": "#EEEEEC",
            "brightYellow": "#FCE94F",
            "cursorColor": "#FFFFFF",
            "cyan": "#06989A",
            "foreground": "#D3D7CF",
            "green": "#4E9A06",
            "name": "Tango Dark",
            "purple": "#75507B",
            "red": "#CC0000",
            "selectionBackground": "#FFFFFF",
            "white": "#D3D7CF",
            "yellow": "#C4A000"
        },
        {
            "background": "#FFFFFF",
            "black": "#000000",
            "blue": "#3465A4",
            "brightBlack": "#555753",
            "brightBlue": "#729FCF",
            "brightCyan": "#34E2E2",
            "brightGreen": "#8AE234",
            "brightPurple": "#AD7FA8",
            "brightRed": "#EF2929",
            "brightWhite": "#EEEEEC",
            "brightYellow": "#FCE94F",
            "cursorColor": "#000000",
            "cyan": "#06989A",
            "foreground": "#555753",
            "green": "#4E9A06",
            "name": "Tango Light",
            "purple": "#75507B",
            "red": "#CC0000",
            "selectionBackground": "#FFFFFF",
            "white": "#D3D7CF",
            "yellow": "#C4A000"
        },
        {
            "background": "#300A24",
            "black": "#171421",
            "blue": "#0037DA",
            "brightBlack": "#767676",
            "brightBlue": "#08458F",
            "brightCyan": "#2C9FB3",
            "brightGreen": "#26A269",
            "brightPurple": "#A347BA",
            "brightRed": "#C01C28",
            "brightWhite": "#F2F2F2",
            "brightYellow": "#A2734C",
            "cursorColor": "#FFFFFF",
            "cyan": "#3A96DD",
            "foreground": "#FFFFFF",
            "green": "#26A269",
            "name": "Ubuntu-ColorScheme",
            "purple": "#881798",
            "red": "#C21A23",
            "selectionBackground": "#FFFFFF",
            "white": "#CCCCCC",
            "yellow": "#A2734C"
        },
        {
            "background": "#000000",
            "black": "#000000",
            "blue": "#000080",
            "brightBlack": "#808080",
            "brightBlue": "#0000FF",
            "brightCyan": "#00FFFF",
            "brightGreen": "#00FF00",
            "brightPurple": "#FF00FF",
            "brightRed": "#FF0000",
            "brightWhite": "#FFFFFF",
            "brightYellow": "#FFFF00",
            "cursorColor": "#FFFFFF",
            "cyan": "#008080",
            "foreground": "#C0C0C0",
            "green": "#008000",
            "name": "Vintage",
            "purple": "#800080",
            "red": "#800000",
            "selectionBackground": "#FFFFFF",
            "white": "#C0C0C0",
            "yellow": "#808000"
        },
        {
            "background": "#010C18",
            "black": "#0B3B61",
            "blue": "#1376F9",
            "brightBlack": "#63686D",
            "brightBlue": "#388EFF",
            "brightCyan": "#FF6AD7",
            "brightGreen": "#74FFD8",
            "brightPurple": "#AE81FF",
            "brightRed": "#FF54B0",
            "brightWhite": "#60FBBF",
            "brightYellow": "#FCF5AE",
            "cursorColor": "#38FF9D",
            "cyan": "#FF5ED4",
            "foreground": "#ECDEF4",
            "green": "#52FFD0",
            "name": "coolnight",
            "purple": "#C792EA",
            "red": "#FF3A3A",
            "selectionBackground": "#38FF9C",
            "white": "#16FDA2",
            "yellow": "#FFF383"
        }
    ],
    "showTabsInTitlebar": true,
    "showTerminalTitleInTitlebar": false,
    "tabWidthMode": "equal",
    "theme": "dark",
    "themes": [],
    "useAcrylicInTabRow": false,
    "windowingBehavior": "useAnyExisting"
}

I noticed that this bug doesn't occur on my laptop. Maybe it's because my laptop screen is in 1080p while my desktop's screen is in 4K.

The display scale can be found in the "Settings" app under System > Display:

Going by your settings file and the screenshot you shared above, I figured you're using 100% scale. To reproduce your screenshot above, I've turned your prompt into a printf:
printf "\n\033[01;32mpalapapa@palapapa\033[00m:\033[01;34m/mnt/d/Desktop/Assembly/Hw\033[00m$\n\n"

With AtlasEngine disabled, it reproduces your screenshot almost perfectly:

(There are some subtle differences because you might not yet be using Monocraft v3 that was released recently, or because our ClearType settings differ. Those also affect grayscale rendering.)
As I already suspected, the issue is fixed if AtlasEngine is enabled:

If you don't like the glyph distance you can install Windows Terminal Preview. On first launch it'll copy our existing settings from non-Preview. Open the settings file (Ctrl+Shift+,) and merge this in:
{
    "profiles":
    {
        "defaults":
        {
            "font":
            {
                "cellWidth": "8pt"
            }
        }
    }
}

The cellWidth field supports the CSS specifiers px, pt, % and ch. There's also a corresponding cellHeight field.
Let me know if that doesn't work for you.

Enabling AtlasEngine does fix it. It is just that you need to restart the terminal for it to take effect, but the settings page doesn't tell you about that. I didn't restart so I thought it didn't work.
Also for some reason installing the newer Monocraft versions causes severe aliasing(not sure whether that's what you should call it) where some strokes are thinner and some others are thicker, as shown in your screenshot. Windows Terminal also doesn't think that the newer versions of Monocraft are monospaced fonts. I have always been using Monocraft 1.4 and Windows Terminal correctly recognizes it as a monospaced font. However, the same aliasing effect is also visible in VSCode, for example, so I think it might be an issue with the font itself.

authors: lhecker palapapa


text:
Terminal crashes after extended use with multiple tabs with SSH sessions

Environment
Windows build number: 10.0.18999.0
Windows Terminal version (if applicable): 0.5.2762.0

Any other software? No

Steps to reproduce
Work via multiple SSH sessions.
Expected behavior
Terminal continues to function normally.
Actual behavior
Terminal randomly crashes, I haven't found the specific cause. I do have the event data, though.
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Application Error" />
  <EventID Qualifiers="0">1000</EventID>
  <Level>2</Level>
  <Task>100</Task>
  <Keywords>0x80000000000000</Keywords>
  <TimeCreated SystemTime="2019-10-11T04:37:45.793053500Z" />
  <EventRecordID>753</EventRecordID>
  <Channel>Application</Channel>
  <Computer>boulder</Computer>
  <Security />
  </System>
- <EventData>
  <Data>WindowsTerminal.exe</Data>
  <Data>1.0.1910.3002</Data>
  <Data>5d969447</Data>
  <Data>TerminalControl.dll</Data>
  <Data>1.0.1910.3002</Data>
  <Data>5d96931e</Data>
  <Data>c0000005</Data>
  <Data>000000000001a68b</Data>
  <Data>6a50</Data>
  <Data>01d57fa8e0a8a2e6</Data>
  <Data>C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.5.2762.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe</Data>
  <Data>C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.5.2762.0_x64__8wekyb3d8bbwe\TerminalControl.dll</Data>
  <Data>b28e87f8-8675-4143-9172-92de557b1410</Data>
  <Data>Microsoft.WindowsTerminal_0.5.2762.0_x64__8wekyb3d8bbwe</Data>
  <Data>App</Data>
  </EventData>
  </Event>

Here too, I've been using Terminal for about a week (1-2 windows open, usually with a few WSL tabs in each), and I see at least one crash a day. My version is also 0.5.2762.0.
I doubt SSH has anything to do with it though. Whatever software runs in WSL doesn't concern the Terminal, it just handles console input and output.

I have experienced this too. A few tabs, ssh inside wsl, cmd, sqlplus (oracle tool). It will just abort when I'm not even actively using it. Also on version 0.5.2762.0.
Is there an option to enable better collection of crash data?

This might be a bit better as of v0.6. Would you mind reporting whether you still see sporadic crashes once you've updated?
Thanks!

source: gharchive/issue

authors: DHowett-MSFT foddrick mxplusb rennex

repo: microsoft/terminal

license: MIT

license_type: permissive

license_source: github-api


text:
Discussion about further improvements for the colored tab

@zadjii-msft @DHowett As mentioned in #3789 I'm opening this issue to have a discussion about further improvements and adjustments of the tab's custom color selection. If this was not what you had in mind, please close the issue.
The idea about ability to pick a custom color for a tab is described in #2994. Currently (at least in my opinion) there are two, maybe three things, which need to be discussed:

Should the coloring of the split button be removed and exactly which pieces of code need to go away? Or should be this activated by a setting?
How to signify the selected tab? Currently a lot of alpha transparency is added to color of the deselected tabs, is this good enough?
There was a suggestion that the painting of the non-client is maybe provided as a follow-up PR. Is this really needed, in which from, when (after or before the implementation of the xaml themeing)?

(I tagged this one for discussion and put in on the backlog. Thanks for filing it!)

So, about the first two things:

I think that the coloring of the split button should go away in any form. It is awkward and looks bad.
Regarding the signifying of the selected tab - I did a thing

Now the selected tab has a colored bar inside of it (like the orange one). Firefox does something pretty similar with its container tabs. Why within the tab not above it? Because I need to calculate the color of the selection bar based on the tab's background. But this can collide with the color of the non-client area (even if they are different colors, a low contrast between them can make the indicator bar invisible).
Pros:

it is better visible than if slapped above the tab
hey, I can make the corner of the tabs round again
Cons:
the tab is a little bit fatter and the split button looks a bit rectangular

I think I can bring the indicator bar a little bit closer to the bottom.
Also I'm pretty sure this is the way to go in regards to the indicating the selected bar. What are your thoughts/feedback?

I think this is a related question or issue but I'm looking for a way to set the tab color as part of the profile json file.

@jdhitsolutions That's actually been discussed in a whole bunch of threads recently (search, #6878,#6707,#7073) -  please refer to #1337, #3327, and the spec #5772 for more discussion.

You know, we've let this discussion fester for a while. In the meantime though, we shipped colored tabs a while ago, and we really haven't had any complaints from people about which tab is selected. Honestly, people seem really happy with it as is (myself included!)
For housekeeping purposes, I'm gonna close this one out. Thanks again for working on this!

authors: DHowett-MSFT gbaychev jdhitsolutions zadjii-msft


text:
Fix crash on save in rejuv'd Color Schemes page

Summary of the Pull Request
Fix a bug where if you pressed the "Save" button, WT would crash. This was caused by adding the possibility that no color scheme is selected in the main page. With no "current scheme", attempting to get its "name" would cause a null ptr exception.
The fix is simple: just check if we actually have a current scheme.
Bonus points: if we don't have a current scheme, don't bother looking throught the color schemes for a match because we'll never find one.
References
#13269 - Color Schemes Rejuv

FYI @DHowett as the 1.16 release guru

aw frick, i lied to you
Error C2451: a conditional expression of type 'const winrt::hstring' is not valid

check for .empty() >_<

@msftbot merge this in 1 minute

source: gharchive/pull-request

authors: DHowett carlos-zamora


text:
Reduce cost of cursor invalidation

Performance of printing enwik8.txt at the following block sizes:
4KiB (printf): 65MB/s -> 73MB/s
128KiB (cat): 135MB/s -> 173MB/s
This commit is fairly problematic. Support for more than one rendering
engine was hacked into Renderer rather forcefully and is not correct.
As such, this commit cannot fix cursor invalidation correctly either,
and while some bugs are fixed (engines may see highly inconsistent
TextBuffer and Cursor states), it introduces others (an error in the
first engine may result in the second engine not executing).
Neither of those are good and the underlying issue remains to be fixed.
Validation Steps Performed

TBD, this PR probably still contains bugs

ah this needs merges into it before it's reviewable, doesn't it

10-40% throughput improvement in conhost with this? Yea this is worth it IMO.

FYI the next best area to optimize would be AdaptDispatch::_DoLineFeed which would bring up to +32%. Its costs is a combination of overly zealous invalidation (currently required by ConPTY however), our current hyperlink implementation via hashmaps and a lot of smaller flaws.
For non-English text the cost distribution is wastly different and there we would get the biggest benefit via async rendering with buffer snapshots (+34%) and improving IsGlyphFullWidth (binary tree --> trie; +27%).

authors: lhecker zadjii-msft


text:
Introducing flag to add a required builder constructor

Currently, the only enforcement of required properties in a struct is in the ".build()" final methods of the StructBuilder. This change adds a flag to build a struct builder constructor consisting of the required fields that have not yet been statically defined in thrift. This provides a compile time enforcement of required properties for a struct.
Additionally, to fully enforce the required builder paradigm, we need to add an option to get rid of the empty constructor within the builder. The combination of these two flags should create a struct that will always have its required properties populated in addition to the null validation on build().

Codecov Report

Merging #398 into master will increase coverage by 0.00%.
The diff coverage is 58.33%.

@@            Coverage Diff            @@
##             master     #398   +/-   ##
=========================================
  Coverage     61.38%   61.39%
- Complexity     1043     1049    +6
=========================================
  Files            84       84
  Lines          6710     6732   +22
  Branches       1011     1018    +7
=========================================
+ Hits           4119     4133   +14
- Misses         2251     2258    +7
- Partials        340      341    +1

Impacted Files
Coverage Δ
Complexity Δ

.../com/microsoft/thrifty/compiler/ThriftyCompiler.kt
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

.../com/microsoft/thrifty/kgen/KotlinCodeGenerator.kt
81.61% <100.00%> (+0.33%)
141.00 <2.00> (+6.00)

...n/com/microsoft/thrifty/service/AsyncClientBase.kt
55.55% <0.00%> (-1.39%)
7.00% <0.00%> (ø%)

...ain/kotlin/com/microsoft/thrifty/kgen/TypeUtils.kt
88.13% <0.00%> (+1.69%)
0.00% <0.00%> (ø%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 80946e2...3d397d5. Read the comment docs.

Hi, thanks for the contribution!  (also, nice to see another Outlook person these days :)
I have to say I'm not entirely clear on the need for the required-only-ctor feature; neither am I opposed to it, necessarily.  What sort of problem does this solve for you?
Regarding the omit-default-ctor flag, I'm sorry to say that this is not workable in its current form.  Currently, generated adapters depend on being able to initialize an empty Builder; take, for example, this snippet generated by the integration tests:

I think this is a fatal flaw for leaving out the default ctor, and possibly for the required-only ctor.  This extra ctor won't interfere with serialization, but it kind of loses its potency when the default one is also available.  What do you think?

Also, you may want to look in to the (undocumented, experimental) flag --experimental-kt-builderless-structs.  It would no doubt be a far-reaching code change, but it generated structs that have no builders at all - you literally cannot make an "invalid" instance, so far as required/optional/etc goes.

Hello! :)
Thanks for the explanation! The motivation behind the required constructor is to essentially do just that - allow the consumer to only create the struct by defining all the required fields. Apart from that, I do think it's valuable to still retain the Builder paradigm for optional fields, as that would be a cleaner initialization rather than potentially a long ctor with many null parameters. This stems from occasions where a change to a struct was not followed by a change on the consumer code that supply the required parameter, which isn't ensured at compile time :(
On the empty constructor - thanks for pointing that out, I totally missed that! The intention here was to steer all consumers to ONLY use the required constructor instead of being able to initialize the Builder without any properties. I'll remove the empty constructor flag, as it is fairly important.

This stems from occasions where a change to a struct was not followed by a change on the consumer code that supply the required parameter, which isn't ensured at compile time :(

Yikes.  In that case, since we'd still have the empty default ctor, what do you think about adding a warning-level @Deprecated annotation to the default ctor and redirecting folks to use the required one?  (Kotlin's ReplaceWith is really nice for that, incidentally: https://readyset.build/kotlin-deprecation-goodies-a35a397aa9b5)

Thanks so much for the contribution!

JFYI, you happen to have arrived at an inopportune time - I just made some pretty big changes that have not yet been released (specifically, thrifty is now Kotlin-first, and the runtime is 100% Kotlin too), and there's more work to do before we're in a shippable state.
More than that, the major 3.0.0 goal is to move to Kotlin MPP for the runtime and the Kotlin generated code.
All that to say, I have no idea when this might ship in a release build.

Got it. In my preliminary testing, things seem to work as expected, most of the infra depends on the kotlin gen, and that seems to work just like before (with some changes to the post processor due to the fact that the lib wasn't bumped for a while). For now, I have a custom build that takes in my change, but once 3.0.0 comes along, at some point in the future, we should be ready to take that in :)

Although if it is possible to make a snapshot drop of the current state of the repo, maybe as 2.1.2 or 3.0.0-RC, I can use that instead of my custom build. Either way, nothing urgent here

Uh oh, did I break the postprocessor?  I remember that being a tricky bit of code to write, so I'm sorry to have given you such work to do.
I'll see about a 2.1.2 release; that seems doable.

Oh no, not at all, most of the changes that were made were due to TypeName from KotlinPoet being bumped up and missing some properties that the post processing code relied on (like the asNullable method). Everything works wonderfully, it's a fantastic tool with killer extensibility! :)

Thanks for your patience; I've pushed 2.1.2 to Maven Central, and it should be available within the next hour.

repo: microsoft/thrifty


text:
Generate serialization method bodies for models

This PR adds support for generating the serialization related method bodies for a model.
fixes: https://github.com/microsoft/typespec/issues/3330

API change check
APIView has identified API level changes in this PR and created following API reviews.
Microsoft.Generator.CSharp

authors: azure-sdk jorgerangel-msft

repo: microsoft/typespec


text:
[http-server-javascript] Some fixes for the petstore example

Closes #4053
@mario-guerra Identified some issues when running the http server generator with the petstore example.

The resulting output contained an extra comma when header or query paramters are transposed into options bag arguments, causing a syntax error.
The result types of accessing header and query parameters are slightly wrong when the parameters are mandatory, leading to a compile error in strict mode only.
The representation of enums was not correct if the enum is required to be written to a declaration instead of treated as a union.

This PR resolves these three issues.

All changed packages have been documented.

:white_check_mark: @typespec/http-server-javascript

Show changes
@typespec/http-server-javascript - fix ✏

Fixed enum representation, an edge case with optional parameter joining, and a couple of type errors around query/header params.

You can try these changes here

🛝 Playground
🌐 Website
📚 Next docs

authors: azure-sdk witemple-msft


text:
Import Directory.Build.props from parent if present

Resolve: #151
Add check if parent folder contains a Directory.Build.props file and import it if present.

@dthaler I am not understanding how the proposed solution in the linked issue would work. My understanding is that msbuild would only load the inner most directory.build.props when processing the vcxproj.

@Alan-Jowett please rebase

@Alan-Jowett please rebase

Rebased.

github reports "Merging can be performed automatically with 1 approving review." even though I approved, so I may not have permissions to be counted.

authors: Alan-Jowett dthaler

repo: microsoft/usersim


text:
Consider tools provided by Visual Studio.

It is frustrating that Visual Studio comes with perfectly good versions of some of our dependencies, but we stubbornly don't use them because they aren't available on a PATH or anything like that.
This change fixes that by looking at the VS instances from vswhere and considering tools therein if they are present.
This change needs approval from the teams that own Git, CMake, and Node in VS before it can land.

@dg0yt It is true that the CMake won't usually get selected due to
https://github.com/microsoft/vcpkg-tool/blob/8a83681f921b10d86ae626fd833c253f4f8c355b/src/vcpkg/tools.cpp#L237

Going to put this on the shelf for now...

repo: microsoft/vcpkg-tool


text:
[messages,flags] Shrinkify vcpkg-tool

I was bored on the bus, so I decided to play around with making the vcpkg binary smaller. Tested on an ARM64 macbook:
# Windows ARM64
6'241'792 vcpkg.exe       # -0
6'203'904 sc-vcpkg.exe    # -38K
5'200'384 os-vcpkg.exe    # -1.04M
5'170'688 os-sc-vcpkg.exe # -1.07M

# macOS ARM64
2'695'538 vcpkg       # -0
2'675'234 sc-vcpkg    # -20K
2'669'826 os-vcpkg    # -26K
2'645'730 os-sc-vcpkg # -50K

Both together result in a binary size reduction of 17% on Windows, and 1.8% on macOS (obviously not as big of a deal, but still a 50K reduction)

CI is failing (1) because of a clang-format needed and (2) because this change causes x-generate-default-message-map to crash.

@strega-nil @strega-nil-ms  Are you still working on this one?

Closing as I am no longer on the team.

authors: BillyONeal strega-nil-ms


text:
[New Port Request] DotNetSdk

Library name: .NET SDK
Source repository URL: https://github.com/dotnet/runtime
Anything else that is useful to know when adding (such as optional features the library may have that should be included):
Many ports (i.e. chakracore) are relying on .NET SDK so it will be reasonable to add it as a port.

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.

authors: PhoebeHui Pospelove

repo: microsoft/vcpkg


text:
[New port ]CSerialPort

hello   ,  add a new library " CSerialPort"

@icezhang88 ,Thanks for posting this issue,Could you please provide the source repository URL and Project homepage?

the source repository URL is  : https://github.com/itas109/CSerialPort.
I will use the lib to communicate with hardware serialport and get the sensor data.
and thank you so much for your help.

@JonLiu1993


text:
[oatpp] update to 1.3.0

Library name: oatpp
New version number: 1.3.0
Release notes can be found at https://github.com/oatpp/oatpp/releases/tag/1.3.0

Fix by #22419


text:
error: vcpkg was unable to detect the active compiler's information

Describe the bug
Tried to install gumbo and it throws me an error "error: vcpkg was unable to detect the active compiler's information. See above for the CMake failure output."
Environment

OS: Windows
Compiler: MSVC 16.11.2.50704

To Reproduce
Steps to reproduce the behavior:
C:\vcpkg>vcpkg install gumbo
vcpkg install gumbo
Computing installation plan...
The following packages will be built and installed:
    gumbo[core]:x86-windows -> 0.10.1#5
  * vcpkg-cmake[core]:x86-windows -> 2022-09-26
  * vcpkg-cmake-config[core]:x86-windows -> 2022-02-06#1
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x86-windows...
error: while detecting compiler information:
The log file content at "C:\vcpkg\buildtrees\detect_compiler\stdout-x86-windows.log" is:
-- Configuring x86-windows-rel
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:96 (message):
    Command failed: "C:/Program Files/CMake/bin/cmake.exe" C:/vcpkg/scripts/detect_compiler -G "Visual Studio 16 2019" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:/vcpkg/packages/detect_compiler_x86-windows -Tv142 -DBUILD_SHARED_LIBS=ON -DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=C:/vcpkg/scripts/toolchains/windows.cmake -DVCPKG_TARGET_TRIPLET=x86-windows -DVCPKG_SET_CHARSET_FLAG=ON -DVCPKG_PLATFORM_TOOLSET=v142 -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE -DCMAKE_VERBOSE_MAKEFILE=ON -DVCPKG_APPLOCAL_DEPS=OFF -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON -DVCPKG_CXX_FLAGS= -DVCPKG_CXX_FLAGS_RELEASE= -DVCPKG_CXX_FLAGS_DEBUG= -DVCPKG_C_FLAGS= -DVCPKG_C_FLAGS_RELEASE= -DVCPKG_C_FLAGS_DEBUG= -DVCPKG_CRT_LINKAGE=dynamic -DVCPKG_LINKER_FLAGS= -DVCPKG_LINKER_FLAGS_RELEASE= -DVCPKG_LINKER_FLAGS_DEBUG= -DVCPKG_TARGET_ARCHITECTURE=x86 -DCMAKE_INSTALL_LIBDIR:STRING=lib -DCMAKE_INSTALL_BINDIR:STRING=bin -D_VCPKG_ROOT_DIR=C:/vcpkg -DZ_VCPKG_ROOT_DIR=C:/vcpkg -D_VCPKG_INSTALLED_DIR=C:/vcpkg/installed -DVCPKG_MANIFEST_INSTALL=OFF -AWin32
    Working Directory: C:/vcpkg/buildtrees/detect_compiler/x86-windows-rel
    Error code: 1
    See logs for more information:
      C:\vcpkg\buildtrees\detect_compiler\config-x86-windows-rel-CMakeCache.txt.log
      C:\vcpkg\buildtrees\detect_compiler\config-x86-windows-rel-out.log
      C:\vcpkg\buildtrees\detect_compiler\config-x86-windows-rel-err.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_configure_cmake.cmake:338 (vcpkg_execute_required_process)
  scripts/detect_compiler/portfile.cmake:18 (vcpkg_configure_cmake)
  scripts/ports.cmake:147 (include)

error: vcpkg was unable to detect the active compiler's information. See above for the CMake failure output.

Failure logs
config-x86-windows-rel-CMakeCache.txt.log
config-x86-windows-rel-err.log
config-x86-windows-rel-out.log

-- Selecting Windows SDK version 8.1 to target Windows 6.1.7601.
-- The C compiler identification is unknown
-- Configuring incomplete, errors occurred!

Thanks for posting this issue. Please provide your host environment information. Also please provide the following logs:
See also "C:/vcpkg/buildtrees/detect_compiler/x86-windows-rel/CMakeFiles/CMakeOutput.log".
See also "C:/vcpkg/buildtrees/detect_compiler/x86-windows-rel/CMakeFiles/CMakeError.log".

System host: Windows 7 version 6.1.7601 32 bits
CMakeError.log
CMakeOutput.log
The logs are in spanish

LINK : fatal error LNK1104: no se puede abrir el archivo 'ucrtd.lib'

Please refer to this solution: https://social.msdn.microsoft.com/Forums/en-US/7a2f61b7-3c01-4767-9a30-e897dc240e60/lnk1104-cannot-open-file-ucrtdlib?forum=vssetup

Ping @Zukaritasu for response, does this issue still exist?

We hope your question was answered to your satisfaction; if it wasn't, you can reopen with more info.

authors: LilyWangLL Zukaritasu


text:
VS2015u3 boost-system 1.70 build fails due to tool chain identification and/or port mismatch

Please note this worked without issue until boost 1.70 venture.  I originally discovered this while trying to build the cpprestsdk for x64-windows, and narrowed it down to this.
Some platform and toolchain info
Windows 10 Pro
Microsoft Visual Studio Professional 2015
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.7.03056
There are several unusual build failures, but all roads eventually lead to boost 1.70
boost-system:x64-windows
Steps to Reproduce:

git a clean vcpkg
run bootstrap-vcpkg.bat
vcpkg install boost-system:x64-windows

The resulting failure takes us to the following, which is hopefully helpful in tracking down the disconnect: build-x64-windows-rel-out.log
Bending my mind was the lack of a compiler on the build line that failed. Just the switches. Odd.
Trying x86 Instead
Remember, this was discovered while attempting to build cpprestsdk. When switching to x86, again on a virgin clean vcpkg clone+bootstrap, I narrowed this failure down to boost-thread. Note that boost-system:x86-windows had no issue, but later boost-thread reported this: build-x86-windows-rel-out.log
Of particular note was the apparent miss-identification of the library for boost-chrono. That dependency was built successfully, but according to the build-failure log, the library being sought was

C:/vcpkg/installed/x86-windows/lib/boost_chrono-vc140-mt.lib

whereas the actual library on disk built during dependencies is/was:

C:/vcpkg/installed/x86-windows/lib/boost_chrono-vc6.lib

Whatever else is happening, it appears there is a disconnect in platform ids at this point.
Finally, note that nothing has changed regarding the tool chain on this machine for almost a year. VS2015u3 has been solid and unflappable, and was so until the recent changes in what appears to be boost (huge assumption on my part, but I'm sure you're correct me if that's inaccurate).
If you need anything else, let me know. IF I'm doing something wrong, definitely let me know. I was saddened by this, as vcpkg worked so well for our needs until this. Thanks.

If there is something else you need from me, please let me know. I had hoped the included logs and steps were sufficient to explain my problem, but if not, and there is additional info needed, feel free to ask. Likewise, If you need any scripts or tests executed to gather instrumentation.

Still unclear if there is something else I need to provide for this issue. If the build logs aren't enough please advise whatever information is needed. Thanks.

I now have two (and soon more) VS2015u3 environments that produce this problem. I'm not sure what repro steps you want. I'll be happy to scrape any system information you need, and I may be able to provide remote-desktop support access to one of the rigs. I sincerely would like this looked at, so again, if I'm missing something regarding information I need to provide, please let me know what else you need, or what I can do to assist.

Update: There is no update. With the latest pick of vcpkg, bootstrap and following instructions above, the identical problems continue to happen.
Same platform
Windows 10 Pro
Microsoft Visual Studio Professional 2015
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.7.03056
boost-system x64-windows still fails
In case anyone cares, the boost-system problem mentioned above still generates this for the link line::
[compile-c-c++ C:\vcpkg\buildtrees\boost-system\x64-windows-rel\boost\build\c9b01f15b8fde3c2f6a38607fe67ea92\error_code.obj
msvc.link.dll C:\vcpkg\buildtrees\boost-system\x64-windows-rel\boost\build\c9b01f15b8fde3c2f6a38607fe67ea92\boost_system-vc6-mt-x64-1_70.dll
'/DLL' is not recognized as an internal or external command, operable program or batch file.

      /DLL /DEBUG /OPT:REF,ICF /subsystem:console /out:"C:\vcpkg\buildtrees\boost-system\x64-windows-rel\boost\build\c9b01f15b8fde3c2f6a38607fe67ea92\boost_system-vc6-mt-x64-1_70.dll" /IMPLIB:"C:\vcpkg\buildtrees\boost-system\x64-windows-rel\boost\build\c9b01f15b8fde3c2f6a38607fe67ea92\boost_system-vc6-mt-x64-1_70.lib"    @"C:\vcpkg\buildtrees\boost-system\x64-windows-rel\boost\build\c9b01f15b8fde3c2f6a38607fe67ea92\boost_system-vc6-mt-x64-1_70.dll.rsp"
    if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL%

...failed msvc.link.dll C:\vcpkg\buildtrees\boost-system\x64-windows-rel\boost\build\c9b01f15b8fde3c2f6a38607fe67ea92\boost_system-vc6-mt-x64-1_70.dll C:\vcpkg\buildtrees\boost-system\x64-windows-rel\boost\build\c9b01f15b8fde3c2f6a38607fe67ea92\boost_system-vc6-mt-x64-1_70.lib C:\vcpkg\buildtrees\boost-system\x64-windows-rel\boost\build\c9b01f15b8fde3c2f6a38607fe67ea92\boost_system-vc6-mt-x64-1_70.pdb C:\vcpkg\buildtrees\boost-system\x64-windows-rel\boost\build\c9b01f15b8fde3c2f6a38607fe67ea92\boost_system-vc6-mt-x64-1_70.pdb...
...failed updating 1 target...
...updated 6 targets...](url)

You're reading that correctly. There is no program name before the cmdline switches; the same as a month ago were anyone to open the attached log and inspect it. Also worth mentioning, the library name being created is wrong. It is this:
boost_system-vc6-mt-x64-1_70.dll

it should be this:
boost_system-vc140-mt-x64-1_70.dll

For whatever reason, vcpkg and/or boost seem to believe that they're building with VC6.0, which I haven't had installed, nor owned, on a development workstation in well over a decade, and certainly not this one.
boost-thread x86-windows still fails
The identical problem of building x86 boost-system on VS2015u3 also fails, with one share symptom: the files are written with the wrong tool chain id for dependent projects, but not when actually trying to wire up the dependencies. That deserves an explanation.
Building boost-thread:x86-windows by doing this:
c:\vcpkg>.\vcpkg install boost-thread:x86-windows

will kick off a build task list of 54 packages. Most of them aren't even really builds per'se; they're literally just copying headers into include folders (boost is, after all, a template library for the most part). Once it does start building the actual libraries needed for boost-thread, several are built, including the following, taken from installed/x86-windows/lib:
08/14/2019  05:24 PM             3,474 boost_atomic-vc6-mt.lib
08/14/2019  05:23 PM            24,590 boost_chrono-vc6-mt.lib
08/14/2019  05:24 PM            45,356 boost_container-vc6-mt.lib
08/14/2019  05:25 PM            29,702 boost_date_time-vc6-mt.lib
08/14/2019  05:24 PM            31,886 boost_exception-vc6-mt.lib
08/14/2019  05:25 PM             8,072 boost_math_c99-vc6-mt.lib
08/14/2019  05:25 PM             8,210 boost_math_c99f-vc6-mt.lib
08/14/2019  05:25 PM             8,210 boost_math_c99l-vc6-mt.lib
08/14/2019  05:25 PM             6,816 boost_math_tr1-vc6-mt.lib
08/14/2019  05:25 PM             6,952 boost_math_tr1f-vc6-mt.lib
08/14/2019  05:25 PM             6,952 boost_math_tr1l-vc6-mt.lib
08/14/2019  05:24 PM         1,184,614 boost_regex-vc6-mt.lib
08/14/2019  05:23 PM             2,220 boost_system-vc6-mt.lib
              13 File(s)      1,367,054 bytes

Note that these libraries all have something in common: Like the previous problem, the tool chain is misidentified. That vc6 should be vc140. That's important, because the actual failure (the 54th and final project, boost-thread, fails with this:
error: Unable to find file or target named
error:     '/boost//C:/vcpkg2/installed/x86-windows/lib/boost_chrono-vc140-mt.lib'
error: referred to from project at
error:     '..'

The odd path notwithstanding (anyone taking a guess at what /boost// is doing in front of that file is welcome comment) the file name is wrong (or I should say, the file name is right , but was wrong when it was actually generated?
Directly above in the same log is this:
notice: Loading explicitly specified user configuration file:
    C:\vcpkg2\buildtrees\boost-thread\x86-windows-rel\user-config.jam
notice: Searching 'C:\vcpkg2\buildtrees\boost-thread\x86-windows-rel' for user-config configuration file 'user-config.jam'.
notice: Loading user-config configuration file 'user-config.jam' from 'C:/vcpkg2/buildtrees/boost-thread/x86-windows-rel'.
notice: [msvc-cfg] msvc-14.0 detected, command: 'C:\vs2015\VC\bin\cl.exe'
notice: will use 'C:\vs2015\VC\bin\amd64_x86\cl.exe' for msvc, condition <toolset>msvc-6.0
notice: [msvc-cfg] condition: '<toolset>msvc-6.0/<architecture>/<address-model>', setup: 'C:/vcpkg2/installed/x86-windows/share/boost-build/nothing.bat x86'
notice: [msvc-cfg] condition: '<toolset>msvc-6.0/<architecture>/<address-model>32', setup: 'C:/vcpkg2/installed/x86-windows/share/boost-build/nothing.bat x86'
notice: [msvc-cfg] condition: '<toolset>msvc-6.0/<architecture>x86/<address-model>', setup: 'C:/vcpkg2/installed/x86-windows/share/boost-build/nothing.bat x86'
notice: [msvc-cfg] condition: '<toolset>msvc-6.0/<architecture>x86/<address-model>32', setup: 'C:/vcpkg2/installed/x86-windows/share/boost-build/nothing.bat x86'

which I found interesting, because the correct tool chain appears detected, then one line later, the wrong tool chain seems to be selected. If that isn't the case, kindly correct the error of my ways.
I haven't given up yet, but I'm about to. I have two developers that are running out of things to do while waiting for advice or a response on this, so if you have anything (willing to try meditation and chanting) please let me know.

So I gave up. It's been over a month since I asked for any assistance on this, two days later the issues was marked for "needs repro", and though I begged and pleaded, have heard nothing but crickets since. So, I...

Wiped, then installed virgin-pure licensed Windows 10 Pro on a new SSD.
Windows Update to current.
Installed VS2015U3 from hash-checked ISO to c:\vs2015
Windows Update to current
Installed git version 2.23.0.windows.1
Cloned master vcpkg
Ran bootstrap.bat
Ran vcpkg install boost-thread:x86-windows
Build failure is STILL there.

You can't get cleaner than that. If you did that and it doesn't repro in your rig, then kindly tell me what you did different than above, because at this point I'm concluding the words "needs-repro" means "did-not-try-to-repro"
After much pain, I found the last sha hash of the repository prior to update to boost 1.70, checked that out, then proceeded from (7) onward in the above list, and the build SUCCEEDS (which I somewhat expected, as I've been saying all along this has to do with the boost upgrade). So please let that settle any question about whether it is my environment or not.
Related to the above, in the failing case (current of master), when perusing the build library results, all libs that should be boost*vc140-mt.lib are instead boost*vc6-mt.lib, which eventually leads to failure when someone expecting vc140 libs doesn't find them. That problem does NOT happen prior to the boost 1.70 upgrade checked in back in May. Synced to that hash, the build succeeds without issue and all generated libs are vc140-mt as expected.
I don't know where the problem is, and I suspect I never will, as I simply don't have anymore time to pour into this. I was originally the proponent for vcpkg to management, but it looks like they're going to choose a different package management system now, in part because of this issue.
Thanks. I hope someday someone else finds this useful.

Here is your repro:
Install VS2015 to any path other than the default path. (I used c:\vs2015 because I hate the MS love-affair with long, space-embedded path names that eventually end up clogging my PATH environment). Use that for vcpkg build and management
That's it
Doing everything else as you normally would, building will fail for both boost-thread:x86-windows and boost-system:x64-windows, and in both cases it is because the build detection (a) find the correct build tools, but then (b) derives the toolset moniker (vc120, vc140, vc141, vc6) from the actual folder path to those tools. Since it doesn't succeed in matching known paths mapped to monikers the derivation algorithm runs home to momma and defaults to vc6, which is completely wrong. Later code that correctly detects the vc140 build tool usage expects to find libraries from dependent projects matching that moniker, but none exist.
Thanks for the help. Somehow I suspect this stands no chance of being fixed anytime soon.

@whozcraig  thanks for posting this issue. If this is still a problem for you, please don't close it. Sorry for the late reply.

@whozcraig, very sorry for late reply.
Boost currently upgrade to 1.71.0, could you build boost-thread with latest source and see if this issue repro? I can't repro it with 1.71.0.
The name looks correct for me.
12/09/2019  03:41 PM             3,506 boost_atomic-vc140-mt.lib
12/09/2019  03:39 PM            24,688 boost_chrono-vc140-mt.lib
12/09/2019  03:41 PM            45,564 boost_container-vc140-mt.lib
12/09/2019  03:43 PM            29,820 boost_date_time-vc140-mt.lib
12/09/2019  03:39 PM            32,646 boost_exception-vc140-mt.lib
12/09/2019  03:43 PM             8,148 boost_math_c99-vc140-mt.lib
12/09/2019  03:43 PM             8,286 boost_math_c99f-vc140-mt.lib
12/09/2019  03:43 PM             8,286 boost_math_c99l-vc140-mt.lib
12/09/2019  03:43 PM             6,882 boost_math_tr1-vc140-mt.lib
12/09/2019  03:43 PM             7,018 boost_math_tr1f-vc140-mt.lib
12/09/2019  03:43 PM             7,018 boost_math_tr1l-vc140-mt.lib
12/09/2019  03:41 PM         1,186,870 boost_regex-vc140-mt.lib
12/09/2019  03:38 PM             2,246 boost_system-vc140-mt.lib
12/09/2019  03:44 PM            28,802 boost_thread-vc140-mt.lib

@whozcraig, does this still be a problem for you? btw, boost upgrade to 1_72_0 currently.

We no longer install boost 1.70, closing this.

authors: BillyONeal NancyLi1013 PhoebeHui whozcraig


text:
[opencascade] Fix static build

Fixes #14874.

@fauder Can you test this PR?
Thanks.

@fauder Can you test this PR?
Thanks.

Thank you for taking the time to fix this.
What I did:

Cloned vcpkg into a fresh directory.
pulled your pr with git fetch origin pull/14901/head:dev/jack/14874.
git checkout dev/jack/14874.
Don't know if was necessary but I ran bootstrap.sh and vcpkg integrate install anyways.
vcpkg install opencascade:x64-windows-static.

Build failed unfortunately:
(Omitting the successfull build of 5 dependencies)
Starting package 6/6: opencascade:x64-windows-static
Building package opencascade[core]:x64-windows-static...
-- Downloading https://github.com/Open-Cascade-SAS/OCCT/archive/V7_4_0.tar.gz...
-- Extracting source C:/Users/Burak/Desktop/vcpkg-test/vcpkg/downloads/Open-Cascade-SAS-OCCT-V7_4_0.tar.gz
-- Applying patch fix-msvc-32bit-builds.patch
-- Applying patch fix-static-build.patch
-- Using source at C:/Users/Burak/Desktop/vcpkg-test/vcpkg/buildtrees/opencascade/src/V7_4_0-3a470d68c8.clean
-- Configuring x64-windows-static
-- Building x64-windows-static-dbg
-- Building x64-windows-static-rel
CMake Error at ports/opencascade/portfile.cmake:51 (file):
  file RENAME failed to rename

    C:/Users/Burak/Desktop/vcpkg-test/vcpkg/packages/opencascade_x64-windows-static/debug/bind

  to

    C:/Users/Burak/Desktop/vcpkg-test/vcpkg/packages/opencascade_x64-windows-static/debug/bin

  because: No such file or directory

Call Stack (most recent call first):
  scripts/ports.cmake:136 (include)

Error: Building package opencascade:x64-windows-static failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: opencascade:x64-windows-static
  Vcpkg version: 2020.11.12-nohash

Additionally, attach any relevant sections from the log files above.

Pulled f58bacb and tried again and got errors:
Computing installation plan...
The following packages will be built and installed:
    opencascade[core]:x64-windows-static -> 7.4.0#2
Detecting compiler hash for triplet x64-windows-static...
Could not locate cached archive: C:\Users\Burak\AppData\Local\vcpkg\archives\a0\a0eafdba50e48d441b9c5192b4b5647ac2682625.zip
Starting package 1/1: opencascade:x64-windows-static
Building package opencascade[core]:x64-windows-static...
-- Using cached C:/Users/Burak/Desktop/vcpkg-test/vcpkg/downloads/Open-Cascade-SAS-OCCT-V7_4_0.tar.gz
-- Extracting source C:/Users/Burak/Desktop/vcpkg-test/vcpkg/downloads/Open-Cascade-SAS-OCCT-V7_4_0.tar.gz
-- Applying patch fix-msvc-32bit-builds.patch
-- Applying patch fix-static-build.patch
-- Using source at C:/Users/Burak/Desktop/vcpkg-test/vcpkg/buildtrees/opencascade/src/V7_4_0-bb62db8ee1.clean
-- Configuring x64-windows-static
-- Building x64-windows-static-dbg
-- Building x64-windows-static-rel
-- Installing: C:/Users/Burak/Desktop/vcpkg-test/vcpkg/packages/opencascade_x64-windows-static/share/opencascade/copyright
-- Performing post-build validation
There should be no bin\ directory in a static build, but C:\Users\Burak\Desktop\vcpkg-test\vcpkg\packages\opencascade_x64-windows-static\bin is present.
There should be no debug\bin\ directory in a static build, but C:\Users\Burak\Desktop\vcpkg-test\vcpkg\packages\opencascade_x64-windows-static\debug\bin is present.
If the creation of bin\ and/or debug\bin\ cannot be disabled, use this in the portfile to remove them

    if(VCPKG_LIBRARY_LINKAGE STREQUAL "static")
        file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/bin" "${CURRENT_PACKAGES_DIR}/debug/bin")
    endif()

Found 1 error(s). Please correct the portfile:
    C:\Users\Burak\Desktop\vcpkg-test\vcpkg\ports\opencascade\portfile.cmake
-- Performing post-build validation done
Error: Building package opencascade:x64-windows-static failed with: POST_BUILD_CHECKS_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: opencascade:x64-windows-static
  Vcpkg version: 2020.11.12-nohash

Additionally, attach any relevant sections from the log files above.

@fauder I will ping you when I finish this PR.

Sure.

@fauder I will ping you when I finish this PR.

@fauder Ready

@fauder Ready

It builds without any errors on a fresh vcpkg clone 👍 I'll wait for it to be merged to try it on my actual vcpkg directory. It took 40 minutes sheesh.
Thanks a lot by the way.

Thanks for your help!

authors: BillyONeal JackBoosY fauder


text:
[akali] Update to v1.43

Describe the pull request

What does your PR fix?
Update to v1.43

Which triplets are supported/not supported? Have you updated the CI baseline?
<linux, windows, macOS / arm, uwp>,

Does your PR follow the maintainer guide?
Yes

If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

@winsoft666 Thanks for your PR! Can you please correct the git-tree field in the akali.json file?
Please run the command ./vpckg x-add-version akali --overwrite-version after each change, and you can get more information from maintainer-guide.md.

@winsoft666 Thanks for your PR! Can you please correct the git-tree field in the akali.json file? Please run the command ./vpckg x-add-version akali --overwrite-version after each change, and you can get more information from maintainer-guide.md.

Sorry, I don't know how to correct the git-tree field, I have never manually modified this file

@winsoft666  Do you mind if I make changes on your PR?

@winsoft666 Do you mind if I make changes on your PR?

Please do it

Thanks for the update and modernization!


text:
[OpenBLAS] Upgrade to 0.3.21 and add arm64-windows support

What does your PR fix?
Upgrades to 0.3.21 and adds arm64-windows triplet. arm-uwp removed

Which triplets are supported/not supported? Have you updated the CI baseline?
!(arm & uwp), Yes

Does your PR follow the maintainer guide?
Yes

If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?
Yes

Thanks for submitting this PR,  I got an error when I tested arm64-windows locally, can you confirm it?  :) @nursik
PS E:\feature-test\vcpkg> ./vcpkg install openblas[*]:arm64-windows
 Computing installation plan...
 The following packages will be built and installed:
	openblas[core,dynamic-arch,simplethread,threads]:arm64-windows -> 0.3.21
 Detecting compiler hash for triplet arm64-windows...
 Restored 0 package(s) from C:\Users\test\AppData\Local\vcpkg\archives in 299.1 us. Use --debug to see more details.
 Installing 1/1 openblas:arm64-windows...
 Building openblas[core,dynamic-arch,simplethread,threads]:arm64-windows...
 -- Using cached xianyi-OpenBLAS-b89fb708caa5a5a32de8f4306c4ff132e0228e9a.tar.gz.
 -- Cleaning sources at E:/feature-test/vcpkg/buildtrees/openblas/src/32e0228e9a-ba8c0c7bab.clean.  Use --editable to skip cleaning for the packages you specify.
 -- Extracting source E:/feature-test/vcpkg/downloads/xianyi-OpenBLAS-b89fb708caa5a5a32de8f4306c4ff132e0228e9a.tar.gz
 -- Applying patch uwp.patch
 -- Applying patch fix-space-path.patch
 -- Applying patch fix-redefinition-function.patch
 -- Applying patch fix-uwp-build.patch
 -- Applying patch install-tools.patch
 -- Using source at E:/feature-test/vcpkg/buildtrees/openblas/src/32e0228e9a-ba8c0c7bab.clean
 -- Found external ninja('1.10.2').
 -- Configuring arm64-windows
 -- Building arm64-windows-dbg
 CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:129 (message):
	 Command failed: "C:/Program Files/CMake/bin/cmake.exe" --build . --config Debug --target install -- -v -j9
	 Working Directory: E:/feature-test/vcpkg/buildtrees/openblas/arm64-windows-dbg
	 See logs for more information:
		E:\feature-test\vcpkg\buildtrees\openblas\install-arm64-windows-dbg-out.log

 Call Stack (most recent call first):
	 installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process)
	 installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_install.cmake:16 (vcpkg_cmake_build)
	 ports/openblas/portfile.cmake:71 (vcpkg_cmake_install)
	 scripts/ports.cmake:147 (include)

 error: building openblas:arm64-windows failed with: BUILD_FAILED
 . . .
PS E:\feature-test\vcpkg>

Log from install-arm64-windows-dbg-out.log:
E:/feature-test/vcpkg/buildtrees/openblas/src/32e0228e9a-ba8c0c7bab.clean/driver/level3/syrk_kernel.c(65): error C2057: expected constant expression
E:/feature-test/vcpkg/buildtrees/openblas/src/32e0228e9a-ba8c0c7bab.clean/driver/level3/syrk_kernel.c(65): error C2466: cannot allocate an array of constant size 0
E:/feature-test/vcpkg/buildtrees/openblas/src/32e0228e9a-ba8c0c7bab.clean/driver/level3/syrk_kernel.c(65): error C2133: 'subbuffer': unknown size

install-arm64-windows-dbg-out.log

@FrankXie05 Are you using Visual Studio 17.3 Preview 3 or later? Because it only works with it.

@nursik Sorry, the version I tested is  Visual Studio 16.11 , I will retest with the latest version  Visual Studio 17.4  Preview 1.  :)

I tested with the latest VS version, but the result is still the same error.   :(
Log from install-arm64-windows-dbg-out.log:
E:/test/openblas/buildtrees/openblas/src/32e0228e9a-ba8c0c7bab.clean/driver/level3/syrk_kernel.c(65): error C2057: expected constant expression
E:/test/openblas/buildtrees/openblas/src/32e0228e9a-ba8c0c7bab.clean/driver/level3/syrk_kernel.c(65): error C2466: cannot allocate an array of constant size 0
E:/test/openblas/buildtrees/openblas/src/32e0228e9a-ba8c0c7bab.clean/driver/level3/syrk_kernel.c(65): error C2133: 'subbuffer': unknown size

And the version of Visual studio version is  Visual Studio 17.4.0 Preview 1.0

Log from config-arm64-windows-out.log:
-DVCPKG_PLATFORM_TOOLSET=v143

install-arm64-windows-dbg-out.log
config-arm64-windows-out.log

Can you send me your Visual Studio's configuration file?

@nursik Sorry for the late reply, here is the configuration file I exported for my Visual Studio.
vsconfig.txt

@FrankXie05 I was trying to figure out why you cannot build it, while my machine and CI/CD could do that. And only now I figured out that you trying to install openblas[*], not only core :) I tried openblas[core,simplethread,threads] on x64 and it works. For dynamic-arch feature I need to check a possible regression from 0.3.20.

@FrankXie05 I tested various combinations of features, and you can see the results below. Could you please confirm that openblas[*]:x64-windows did not work before (using 0.3.20 version)? Because it seems there is no regression, and it was not supported before.
ARM machine
arm64-windows triplet

V\F
core
core,simplethread,threads
*

0.3.20
no
no
no

0.3.21
yes
yes
no

x64-windows triplet

V\F
core
core,simplethread,threads
*

0.3.20
no
no
no

0.3.21
yes
yes
no

x86_64 machine
arm64-windows triplet

V\F
core
core,simplethread,threads
*

0.3.20
no
no
no

0.3.21
yes
yes
no

x64-windows triplet

V\F
core
core,simplethread,threads
*

0.3.20
yes
yes
no

0.3.21
yes
yes
no

@nursik Thank you for your test results, based on the latest test results of CI, I chose to approve this PR, maybe there is something wrong with my local vs setup, I asked other members of my team to test and the test passed.  :)

Change label for JavierMatosD review.

Thank you!

authors: FrankXie05 JavierMatosD nursik


text:
[cwapi3d] Add CwAPI3D port

[x] Changes comply with the maintainer guide.
[x] The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
[x] Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx.
[x] The versioning scheme in vcpkg.json matches what upstream says.
[x] The license declaration in vcpkg.json matches what upstream says.
[x] The installed as the "copyright" file matches what upstream says.
[x] The source code of the component installed comes from an authoritative source.
[x] The generated "usage text" is accurate. See adding-usage for context.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is in the new port's versions file.
[x] Only one version is added to each modified port's versions file.

Tested usage successfully by cwapi3d:x64-windows：
The package cwapi3d provides CMake targets:

    find_package(CwAPI3D CONFIG REQUIRED)
    target_link_libraries(main PRIVATE CwAPI3D::CwAPI3D)


text:
.NET RID not supported

It would be good if we don't need to explicitly specify <Platform> if it has been implied by <RuntimeIdentifier>/<PlatformTarget>.
dotnet publish -c Release -r win10-x64

-or-
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
  </PropertyGroup>

</Project>

It's valid to add a project reference from a Any CPU project to a x64 one.
exe> dotnet add reference ..\lib\
Reference `..\lib\lib.csproj` added to the project.

exe> dotnet build
  Determining projects to restore...
  lib -> lib\bin\x64\Debug\net5.0\lib.dll
  exe -> exe\bin\Debug\net5.0\exe.dll

Related to this, we need the vcrtforwarders dlls to be in the correct runtimes\win10-x64\native directory, so that they are copied to the proper location for .NET5 apps. We can't rely on native assemblies being copied next to the .exe, as it breaks behavior with DllImport. See related issue https://github.com/microsoft/CsWinRT/issues/266

authors: NextTurn stevenbrix

repo: microsoft/vcrt-forwarders


text:
Allow more granular skipping of tests via VS Version

Today the IDEFact will let you set a minimum and maximum VS version, but the granularity is only to the level of "2022, 2019, etc". It would be helpful in some instances to have more granular control than that. Ideally we'd be able to specify a specific build as Min or Max.

For now, you should be able to return immediately (without running the test) based on the result of TestServices.Shell.GetVersionAsync.

authors: ryanbrandenburg sharwell

repo: microsoft/vs-extension-testing


text:
Suggestion: Auto-complete should not insert ()

Experience in TS:

Find an item to auto-complete

Press tab:

Press (:

Start typing var name:

Experience with ARM tools:

Find an item to auto-complete:

Press tab:

Press ':

Notice signature help doesn't show up, this is particularly bad since very few users actually know the ctrl+shift+space shortcut. Instead of inserting the brackets the extension should be relying on VS Code's core capability to auto-insert closing brackets, this also has the benefits of respecting settings like this (which I happen to use as well):
"editor.autoClosingBrackets": "never"

Ideally this would be the state when ' is pressed:

This issue really messes with my muscle memory and makes typing out concat() entries manually really frustrating.

Thanks @Tyriar I see your point here and will prioritize this where it makes sense.

ALSO:

Completing a user namespace should not add a "."

Shipped yesterday

authors: StephenWeatherford Tyriar neilpeterson

repo: microsoft/vscode-azurearmtools


text:
No command works

When using the extension, no command works. It always returns:
Internal error: Expected value to be neither null nor undefined: resourceIdMatches

Could you provide more details for us to reproduce this issue?

VS Code version
Azure Storage extension version
Do you have a workspace open
What commands did you try?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!

authors: AzCode-Bot JanDonnermayer alexweininger

repo: microsoft/vscode-azurestorage


text:
Cmake/build output with invalid encoding when the cmake geneartor are Ninja

Brief Issue Summary
The outputs
[main] Building folder: jerryscript
[build] Starting build
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --build c:/work/study/languages/typescript/jerryscript/build/reldeb --config RelWithDebInfo --target all -- -j 18
[build] [1/1   0% :: 0.000] Re-running CMake...
[build] -- CMAKE_BUILD_TYPE               RelWithDebInfo
[build] -- CMAKE_C_COMPILER_ID            MSVC
[build] -- CMAKE_SYSTEM_NAME              Windows
[build] -- CMAKE_SYSTEM_PROCESSOR         AMD64
[build] -- BUILD_SHARED_LIBS              OFF
[build] -- ENABLE_AMALGAM                 OFF
[build] -- ENABLE_LTO                     ON
[build] -- ENABLE_STRIP                   OFF (FORCED BY COMPILER)
[build] -- JERRY_VERSION                  2.4.0
[build] -- JERRY_CMDLINE                  ON
[build] -- JERRY_CMDLINE_TEST             OFF
[build] -- JERRY_CMDLINE_SNAPSHOT         OFF
[build] -- JERRY_LIBFUZZER                OFF (FORCED BY COMPILER)
[build] -- JERRY_PORT_DEFAULT             ON (FORCED BY CMDLINE OR LIBFUZZER OR TESTS)
[build] -- JERRY_EXT                      ON (FORCED BY CMDLINE OR TESTS)
[build] -- JERRY_MATH                     OFF
[build] -- UNITTESTS                      OFF
[build] -- DOCTESTS                       OFF
[build] -- JERRY_CPOINTER_32_BIT          ON (FORCED BY HEAP SIZE)
[build] -- JERRY_DEBUGGER                 OFF
[build] -- JERRY_ERROR_MESSAGES           OFF
[build] -- JERRY_EXTERNAL_CONTEXT         OFF
[build] -- JERRY_PARSER                   ON
[build] -- JERRY_LINE_INFO                ON
[build] -- JERRY_LOGGING                  OFF
[build] -- JERRY_MEM_STATS                OFF
[build] -- JERRY_MEM_GC_BEFORE_EACH_ALLOC OFF
[build] -- JERRY_PARSER_DUMP_BYTE_CODE    OFF
[build] -- JERRY_PROFILE                  es.next
[build] -- JERRY_REGEXP_STRICT_MODE       OFF
[build] -- JERRY_REGEXP_DUMP_BYTE_CODE    OFF
[build] -- JERRY_SNAPSHOT_EXEC            OFF
[build] -- JERRY_SNAPSHOT_SAVE            OFF
[build] -- JERRY_SYSTEM_ALLOCATOR         OFF
[build] -- JERRY_VALGRIND                 OFF
[build] -- JERRY_VM_EXEC_STOP             OFF
[build] -- JERRY_GLOBAL_HEAP_SIZE         512000
[build] -- JERRY_GC_LIMIT                 (0)
[build] -- JERRY_STACK_LIMIT              (0)
[build] -- JERRY_GC_MARK_LIMIT            (8)
[build] -- FEATURE_INIT_FINI              OFF
[build] -- ENABLE_LINK_MAP                OFF
[build] -- ENABLE_COMPILE_COMMANDS        ON
[build] -- JERRY_TEST_STACK_MEASURE       OFF
[build] -- Configuring done
[build] -- Generating done
[build] -- Build files have been written to: C:/work/study/languages/typescript/jerryscript/build/reldeb
[build] [18/197   0% :: 0.136] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\base\ecma-helpers-string.c.obj
[build] FAILED: jerry-core/CMakeFiles/jerry-core.dir/ecma/base/ecma-helpers-string.c.obj
[build] C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe  /nologo -DJERRY_CPOINTER_32_BIT=1 -DJERRY_DEBUGGER=0 -DJERRY_ERROR_MESSAGES=0 -DJERRY_EXTERNAL_CONTEXT=0 -DJERRY_GC_LIMIT=(0) -DJERRY_GC_MARK_LIMIT=(8) -DJERRY_GLOBAL_HEAP_SIZE=512000 -DJERRY_LINE_INFO=1 -DJERRY_LOGGING=0 -DJERRY_MEM_GC_BEFORE_EACH_ALLOC=0 -DJERRY_MEM_STATS=0 -DJERRY_NDEBUG -DJERRY_PARSER=1 -DJERRY_PARSER_DUMP_BYTE_CODE=0 -DJERRY_REGEXP_DUMP_BYTE_CODE=0 -DJERRY_REGEXP_STRICT_MODE=0 -DJERRY_SNAPSHOT_EXEC=0 -DJERRY_SNAPSHOT_SAVE=0 -DJERRY_STACK_LIMIT=(0) -DJERRY_SYSTEM_ALLOCATOR=0 -DJERRY_VALGRIND=0 -DJERRY_VM_EXEC_STOP=0 -I..\..\jerry-core\include -I..\..\jerry-core -I..\..\jerry-core\api -I..\..\jerry-core\debugger -I..\..\jerry-core\ecma\base -I..\..\jerry-core\ecma\builtin-objects -I..\..\jerry-core\ecma\builtin-objects\typedarray -I..\..\jerry-core\ecma\operations -I..\..\jerry-core\jcontext -I..\..\jerry-core\jmem -I..\..\jerry-core\jrt -I..\..\jerry-core\lit -I..\..\jerry-core\parser\js -I..\..\jerry-core\parser\regexp -I..\..\jerry-core\vm /DWIN32 /D_WINDOWS /W3 /wd4996 /MD /Zi /O2 /Ob1 /DNDEBUG /showIncludes /Fojerry-core\CMakeFiles\jerry-core.dir\ecma\base\ecma-helpers-string.c.obj /Fdjerry-core\CMakeFiles\jerry-core.dir\jerry-core.pdb /FS -c ..\..\jerry-core\ecma\base\ecma-helpers-string.c
[build] ..\..\jerry-core\ecma\base\ecma-helpers-string.c(680): error C2061: �����: ��ʶ����ecma_get_internal_string��
[build] ..\..\jerry-core\ecma\base\ecma-helpers-string.c(680): error C2059: �����:��;��
[build] ..\..\jerry-core\ecma\base\ecma-helpers-string.c(680): error C2059: �����:��<parameter-list>��
[build] [18/197   1% :: 0.259] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\base\ecma-literal-storage.c.obj
[build] [18/197   1% :: 0.274] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\base\ecma-lcache.c.obj
[build] [18/197   2% :: 0.274] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\base\ecma-init-finalize.c.obj
[build] [18/197   2% :: 0.289] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\builtin-objects\ecma-builtin-arraybuffer-prototype.c.obj
[build] [18/197   3% :: 0.289] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\builtin-objects\ecma-builtin-set-prototype.c.obj
[build] [18/197   3% :: 0.301] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\base\ecma-helpers-errol.c.obj
[build] [18/197   4% :: 0.306] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\base\ecma-helpers-value.c.obj
[build] [18/197   4% :: 0.312] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\base\ecma-property-hashmap.c.obj
[build] [18/197   5% :: 0.315] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\builtin-objects\ecma-builtin-set.c.obj
[build] [18/197   5% :: 0.322] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\builtin-objects\ecma-builtin-regexp.c.obj
[build] [18/197   6% :: 0.325] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\builtin-objects\ecma-builtin-array-iterator-prototype.c.obj
[build] [18/197   6% :: 0.328] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\builtin-objects\ecma-builtin-regexp-prototype.c.obj
[build] [18/197   7% :: 0.329] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\base\ecma-module.c.obj
[build] [18/197   7% :: 0.329] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\builtin-objects\ecma-builtin-array-prototype-unscopables.c.obj
[build] [18/197   8% :: 0.334] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\builtin-objects\ecma-builtin-array.c.obj
[build] [18/197   8% :: 0.337] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\base\ecma-helpers.c.obj
[build] [18/197   9% :: 0.352] Building C object jerry-core\CMakeFiles\jerry-core.dir\ecma\builtin-objects\ecma-builtin-array-prototype.c.obj
[build] ninja: build stopped: subcommand failed.
[build] Build finished with exit code 1

Does setting "cmake.outputLogEncoding": "utf8" fix it?  The extension tries to select the active Windows Codepage on win32 by default, and it may not be getting the correct result.

Does setting "cmake.outputLogEncoding": "utf8" fix it?  The extension tries to select the active Windows Codepage on win32 by default, and it may not be getting the correct result.

Does setting "cmake.outputLogEncoding": "utf8" fix it? The extension tries to select the active Windows Codepage on win32 by default, and it may not be getting the correct result.

It's not work as you expect,
  "cmake.outputLogEncoding": "gbk",

"cmake.outputLogEncoding": "utf8" cause encoding problem
The ninja is output with windows codepage. does cmake treat ninja output always to be utf8?
I think that works for non-win platform but not for windows

Does setting "cmake.outputLogEncoding": "utf8" fix it? The extension tries to select the active Windows Codepage on win32 by default, and it may not be getting the correct result.

It's not work as you expect,
  "cmake.outputLogEncoding": "gbk",

"cmake.outputLogEncoding": "utf8" cause encoding problem
The ninja is output with windows codepage. does cmake treat ninja output always to be utf8?
I think that works for non-win platform but not for windows

does cmake treat ninja output always to be utf8?

Unfortunately, I don't know the answer to that.  Does the output look correct when you run the cmake command in the VS Code Terminal, or a PowerShell/CMD prompt?

does cmake treat ninja output always to be utf8?

Unfortunately, I don't know the answer to that.  Does the output look correct when you run the cmake command in the VS Code Terminal, or a PowerShell/CMD prompt?

does cmake treat ninja output always to be utf8?

Unfortunately, I don't know the answer to that. Does the output look correct when you run the cmake command in the VS Code Terminal, or a PowerShell/CMD prompt?

Valid in PowerShell/CMD prompt, VS Code Terminal not working because the MSVC bat env not setup properly

does cmake treat ninja output always to be utf8?

Unfortunately, I don't know the answer to that. Does the output look correct when you run the cmake command in the VS Code Terminal, or a PowerShell/CMD prompt?

Valid in PowerShell/CMD prompt, VS Code Terminal not working because the MSVC bat env not setup properly

@taoyouh, @lygstate, if you would like, you can try this vsix (https://github.com/microsoft/vscode-cmake-tools/actions/runs/811030625) to get unblocked with a fix for this issue before we release 1.7.2.

CMake Tools 1.7.2 was released today and it contains a fix for this problem. Upgrade the extension and let us know if you encounter any other issues.

thanks, works now

authors: andreeis bobbrow lygstate

repo: microsoft/vscode-cmake-tools


text:
"Apply In Editor" Very slow for simple requests and applies code incorrectly

Sorry if this is a duplicate, I did search and could not find it.   I don't think it is a new issue but as "Copilot Edits" continues to get better, I am hoping that the regular chat applying can also be improved.

Copilot Chat Extension Version:  v0.23.2024102903 (pre-release)
VS Code Version: Version: 1.95.3
OS Version: Windows 11
Logs: I could not find logs that mentioned anything about this.

Steps to Reproduce:

Suggest change to simple code block (in my case, 2 lines)
Chat returns a change that modifies those 2 lines and adds 2 more lines
Click "Apply in Editor"
Counted ~45 Seconds of loading before anything happens
Once it applied, it only modified the 2 lines and did not enter the 2 new lines.

I would expect all 4 lines to be applied, not only the 2 existing ones. I also don't think it should take that long to apply when the only context given was ~8 lines.

@AlfredoDinunzioTR Do you remember, was the initial file very large?

this happens to me, maybe code base larger? because the file actually small

You're right, this shouldn't happen.

authors: AlfredoDinunzioTR Shaerif VanderSP alexdima

repo: microsoft/vscode-copilot-release


text:
Fail to configure firewall to the PostgreSQL Single server on Mac

OS: Mac
Build Version: 20210715.8
Repro Steps:

Create a PostgreSQL Single Server.
Drill down the server -> Postgres -> Click "Configure firewall to connected to...".
Pop up a prompt asking to continue? -> Yes.
Check whether succeed to configure firewall to the PostgreSQL Single server.

Expect:
Succeed to configure firewall to the PostgreSQL Single server.
Actual:
Fail to configure firewall to the PostgreSQL Single server.
More Info:
This issue only reproduces on Mac.

I am not able to repro this for Single Server. Does this happen often and what is the error that it is failing with?

Yes, we test on both machines are stable and reproducible without any error.

Looks like this is resolved. Thanks for retesting @v-mengwe!

authors: neelip v-mengwe

repo: microsoft/vscode-cosmosdb


text:
Failed to start go devcontainer

Issue Type: Bug
Hi,
i'm trying to start a dev container from the example provided by microsoft
https://github.com/Microsoft/vscode-remote-try-go
im getting the following error message
[100739 ms] The command '/bin/sh -c apt-get update     && apt-get -y install --no-install-recommends apt-utils dialog 2>&1     && apt-get -y install git iproute2 procps lsb-release     && mkdir -p /tmp/gotools     && cd /tmp/gotools     && GO111MODULE=on go get -v golang.org/x/tools/gopls@latest 2>&1     && GO111MODULE=on go get -v         honnef.co/go/tools/...@latest         golang.org/x/tools/cmd/gorename@latest         golang.org/x/tools/cmd/goimports@latest         golang.org/x/tools/cmd/guru@latest         golang.org/x/lint/golint@latest         github.com/mdempsky/gocode@latest         github.com/cweill/gotests/...@latest         github.com/haya14busa/goplay/cmd/goplay@latest         github.com/sqs/goreturns@latest         github.com/josharian/impl@latest         github.com/davidrjenni/reftools/cmd/fillstruct@latest         github.com/uudashr/gopkgs/cmd/gopkgs@latest          github.com/ramya-rao-a/go-outline@latest          github.com/acroca/go-symbols@latest          github.com/godoctor/
godoctor@latest          github.com/rogpeppe/godef@latest          github.com/zmb3/gogetdoc@latest         github.com/fatih/gomodifytags@latest          github.com/mgechev/revive@latest          github.com/go-delve/delve/cmd/dlv@latest 2>&1     && go get -v github.com/alecthomas/gometalinter 2>&1     && go get -x -d github.com/stamblerre/gocode 2>&1     && go build -o gocode-gomod github.com/stamblerre/gocode     && mv gocode-gomod $GOPATH/bin/     && curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin 2>&1     && groupadd --gid $USER_GID $USERNAME     && useradd -s /bin/bash --uid $USER_UID --gid $USER_GID -m $USERNAME     && apt-get install -y sudo     && echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME     && chmod 0440 /etc/sudoers.d/$USERNAME     && chmod -R a+w /go/pkg     && apt-get autoremove -y     && apt-get clean -y     && rm -rf /var/lib/apt/lists/* /go/src /tmp/gotools' returned a non-
zero code: 1

[100776 ms] Failed: Building an image from the Dockerfile (this can take a while).
[100778 ms] Command failed: C:\Program Files\Docker\Docker\resources\bin\docker.exe build -f c:\git\go\vscode-remote-try-go\.devcontainer\Dockerfile -t vsc-vscode-remote-try-go-9b871051e418f26c06e7f29e1759bc67 c:\git\go\vscode-remote-try-go\.devcontainer

did you know the problem ? i've updated all the tools like vscode and docker-desktop (windows 10)
VS Code version: Code 1.42.0 (ae08d5460b5a45169385ff3fd44208f431992451, 2020-02-06T10:51:34.058Z)
OS version: Windows_NT x64 10.0.17134
Remote OS version: Linux x64 4.19.76-linuxkit
Fetching remote diagnostics for 'Dev Container: Go Sample' failed.

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (8 x 3592)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_offsurface_control: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.94GB (4.41GB free)

Process Argv
C:\git|

Screen Reader
no

VM
0%

Item
Value

Remote
Dev Container: Alpine 3.10

OS
Linux x64 4.19.76-linuxkit

CPUs
Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (2 x 3591)

Memory (System)
1.92GB (0.80GB free)

VM
0%

Fetching remote diagnostics for 'Dev Container: Go Sample' failed.
Extensions: none

I have seen some issues lately where certain go packages temporarily stopped working and then got fixed again. I will take a closer look

It seems like github.com/uudashr/gopkgs/cmd/gopkgs is no longer present

I pulled that package out temporarily from the Dockerfile and was able to build

Yeah it's odd - error I see is:
[2020-02-13T23:06:39.608Z] [PID 70740] [34704 ms] go get: github.com/uudashr/gopkgs/cmd/gopkgs@v0.0.0-20191024034442-58e9141cd7d6 requires
	github.com/uudashr/gopkgs/v2@v2.1.0 requires
	github.com/uudashr/gopkgs@v0.0.0: reading github.com/uudashr/gopkgs/go.mod at revision v0.0.0: unknown revision v0.0.0

...which implies the package is there (since we use @latest and its finding 2.1.0).

Yep - there's an upstream issue for the package PR to fix it.
Issue: https://github.com/uudashr/gopkgs/issues/22
PR: https://github.com/uudashr/gopkgs/pull/24

Latest upstream issue is here: https://github.com/uudashr/gopkgs/issues/25
FWIW, you can tweak the Dockerfile to install the package without using a go module as a tactical solution - the upstream issue appears to be getting some traction, but if it dies I may update the repo with this workaround.
Remove:
        github.com/uudashr/gopkgs/cmd/gopkgs@latest  \

Then update ...
    #
    # Install Go tools w/o module support
    && go get -v github.com/alecthomas/gometalinter 2>&1 \

to...
    && go get -v github.com/alecthomas/gometalinter \
        github.com/uudashr/gopkgs/cmd/gopkgs 2>&1 \

The latest on this is that the bad gopkgs version is being cached by the global goproxy.  So, to resolve this, updating to "v2" appears to fix the problem.  This has been done in commit https://github.com/microsoft/vscode-dev-containers/commit/4579be1efbf4b0bb086c3b9c9803e3bbdc8ab99b since this has been going on too long.
It changes
        github.com/uudashr/gopkgs/cmd/gopkgs@latest  \

to
        github.com/uudashr/gopkgs/v2/cmd/gopkgs@latest  \

This workaround is in v0.101.1 of the stable extension and will be in the v0.102.0 insiders version that will be released soon.  If you have an existing Dockerfile, make the small update above.

authors: Chuxel TaylorBarrick weischermanuel

repo: microsoft/vscode-dev-containers


text:
can't run in browser

Environment (please complete the following information):

OS (e.g., Windows 10):
Extension version (e.g., 1.2.3):

Describe the bug:

Repro steps:

Expected behavior:

Additional context:

Closing as incomplete. Please feel free to add more information if you have any and we can re-open the issue.

authors: Akatamvdth captainbrosset

repo: microsoft/vscode-edge-devtools


text:
eslint.codeActionsOnSave.rules not working with "editor.formatOnSave": true for ts and tsx files

Bug Report

This issue occurs only when .eslintrc.json extends plugin:@typescript-eslint/recommended.
🔎 Search Terms

eslint.codeActionsOnSave.rules
related issue: 1431
🕗 Version & Regression Information

VSCode: 1.66.1
dbaeumer.vscode-eslint: 2.2.3 (pre-release)
Node.js: 16.13.0
eslint: 8.13.0
@typescript-eslint/parser: 5.18.0
@typescript-eslint/eslint-plugin: 5.18.0

💻 code
test.ts
var test = 2

.vscode/settings.json
{
  "[typescript]": {
    "editor.defaultFormatter": "dbaeumer.vscode-eslint",
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "dbaeumer.vscode-eslint",
  },
  "editor.formatOnSave": true,
  "editor.formatOnPaste": false,
  "editor.formatOnType": false,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true,
  },
  "eslint.format.enable": true,
  "eslint.useESLintClass": true,
  "eslint.codeActionsOnSave.rules": [
    "*semi*",
  ],
}

.eslintrc.json
{
  "env": {
    "browser": true,
    "es2021": true,
    "node": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaFeatures": {
      "jsx": true
    },
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "plugins": [
    "@typescript-eslint"
  ],
  "rules": {
    "semi-style": 2,
    "semi-spacing": 2,
    "semi": 2
  }
}

🙁 Actual behavior
On save, the test.ts gets formatted:
const test = 2;

🙂 Expected behavior
On save, the test.ts gets formatted:
var test = 2;

(because I declared to opt-in only *semi* rules in eslint.codeActionsOnSave.rules)

You also need to enable ESLint as a formatter using eslint.format.enable

@dbaeumer In my .vscode/settings.json, eslint.format.enable has always been true, yet it hasn't properly worked.

I am also having this issue. @cdpark0530 did you ever get this resolved or is this still occurring?

@samlythemanly Without formatOnSave, yes I found a solution satisfying at least to me.

@cdpark0530 could you please provide me with a GitHub repository I can clone that demos that. That ensure that we are using the exact same setup.

This issue has been closed because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!

authors: cdpark0530 dbaeumer samlythemanly

repo: microsoft/vscode-eslint


text:
v0.3.9 error win32 x64

:warning:Please attach log.txt and AdoptOpenJDK-MSI.log under *%TEMP%\vscode-java-installer* for more details.
version: 0.3.9
env:
JAVA_HOME: C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Programs\AdoptOpenJDK\jdk-11.0.8.10-hotspot\
PATH:
C:\Program Files\AdoptOpenJDK\jdk-14.0.2.12-hotspot\bin
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\iCLS\
C:\Program Files\Intel\Intel(R) Management Engine Components\iCLS\
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\WINDOWS\System32\OpenSSH\
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL
C:\Program Files\Intel\Intel(R) Management Engine Components\DAL
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT
C:\Program Files\Intel\Intel(R) Management Engine Components\IPT
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\WINDOWS\System32\OpenSSH\
C:\Program Files\dotnet\
C:\Program Files\Microsoft SQL Server\130\Tools\Binn\
C:\Program Files (x86)\dotnet\
C:\Program Files\nodejs\
C:\Program Files\Git\cmd
C:\Program Files\Java\jdk-14.0.2\bin
C:\Program Files\RedHat\java-14-openjdk-14.0.2-1\bin
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Programs\AdoptOpenJDK\jdk-11.0.8.10-hotspot\bin
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Programs\Python\Python38\Scripts\
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Programs\Python\Python38\
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Microsoft\WindowsApps
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Programs\MiKTeX 2.9\miktex\bin\x64\
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Programs\Microsoft VS Code\bin
C:\Users\enyia.DESKTOP-TUU2H13\.dotnet\tools
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Roaming\npm
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Python 3.7
C:\Python27
C:\Python27\Scripts
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\learn_ide_3\bin
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Microsoft\WindowsApps

JDKs:
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Programs\AdoptOpenJDK\jdk-11.0.8.10-hotspot	env.JAVA_HOME
C:\Program Files\RedHat\java-14-openjdk-14.0.2-1\	WinReg
C:\Program Files\RedHat\java-14-openjdk-14.0.2-1\	WinReg
C:\Program Files\AdoptOpenJDK\jdk-14.0.2.12-hotspot	env.PATH
C:\Program Files\Java\jdk-14.0.2	env.PATH
C:\Program Files\RedHat\java-14-openjdk-14.0.2-1	env.PATH
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Programs\AdoptOpenJDK\jdk-11.0.8.10-hotspot	env.PATH
C:\Program Files\Java\jdk-14.0.2	defaultLoc
C:\Program Files\AdoptOpenJDK\jdk-14.0.2.12-hotspot	defaultLoc
C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Programs\AdoptOpenJDK\jdk-11.0.8.10-hotspot	defaultLoc

log:
[2:15:36 PM] AdoptOpenJDK-11-x64
[2:17:30 PM] Download JDK ... [Completed]
[2:17:30 PM] Install JDK
[2:17:30 PM] Installing AdoptOpenJDK-11-x64...
[2:17:35 PM] Install JDK ... [Completed]
[2:17:35 PM] Configure Java Settings
[2:17:36 PM] Error occurred
[2:17:36 PM] Error: Java Home not found.

You can work it around by manually installing Java Extension Pack.
To help us understand this issue, please attach %TEMP%\vscode-java-installer\log.txt for more details.
Meanwhile, can you check below locations, see if a) <base path>\bin\javac.exe exists, and b) <base path>\bin\java.exe -version has correct output in CMD?

C:\Users\enyia.DESKTOP-TUU2H13\AppData\Local\Programs\AdoptOpenJDK\jdk-11.0.8.10-hotspot
C:\Program Files\RedHat\java-14-openjdk-14.0.2-1\
C:\Program Files\AdoptOpenJDK\jdk-14.0.2.12-hotspot
C:\Program Files\Java\jdk-14.0.2

Thanks.

repo: microsoft/vscode-java-installer


text:
Native Notebooks - Cells running out of order

Expected behavior
Cells to run in order
Actual behavior
Cells run out of order
Steps to reproduce:

Open notebook
Run 3 cells to connect to kernel
Cells run out of order
(Once connected to kernel, the issue does not exist, only happens when running to connect to kernel)

Validated

Validated

authors: DonJayamanne claudiaregio

repo: microsoft/vscode-jupyter


text:
Native Notebooks + Custom Editor Error?

Got the following customer error from survey.
"CustomEditor and NativeNotebook experiments cannot be opened together" - this is the error i get everytime i try to open an .ipynb file.  I undestand bugs happen, but when they do, a detailed explanation of what went wrong should be available (most of us vscode users are devs ourselves, when something breaks, we like to know why, so we might address the issue)."
Can someone clarify what logic would trigger this error to a user? Would like to update the error to be more clear + potentially provide location to resolution instructions.

We believe we have resolved this issue in the recent point release.
Hence closing this issue.
If this comes up again we can re-visit it.


text:
Title does not get refreshed after document is loaded

Consider the following document:
<!DOCTYPE html>
<html>
<head>
	<title>Title from HTML</title>
	<script>
		document.addEventListener(
			"DOMContentLoaded",
			function (event) { document.title = "1" }
		);

		function test() {
			document.title = "2";
		};

		document.title = "Title from JavaScript";
	</script>
</head>
<body>
	<button onclick="javascript:test()">Hello</button>
</body>
</html>

Expected

Document title should be 1
Document title should change to 2 on clicking the button

Actual

Document title is 0
Document title stays 0 on clicking the button

If I use "Open in Browser", everything works as expected.

Here is an image:

repo: microsoft/vscode-livepreview


text:
Changes in commit appear without folder info

I would have expected either to see the folder as description or a tree structure:

I've added a directory tree for commits nodes when githubPullRequests.fileListLayout is tree.
For folder info when it's flat, here's what we get now:

I think I can add a resourceLabelFormatters if you wouldn't expect to see the commit in the path like that.

repo: microsoft/vscode-pull-request-github