text:
Allow a workspace to show individual files from other folders

Update from @bpasero: this issue was renamed based on the discussion at the end (see https://github.com/microsoft/vscode/issues/45177#issuecomment-1341005532 and above)
Original below:

VSCode Version: 1.20.1
OS Version: Microsoft Windows [Version 10.0.16299.248]

Steps to Reproduce:
N/A

Does this issue occur when all extensions are disabled?: Yes

Currently, .code-workspace only contains folders field which allows to add folders into workspace. I prefer a way to add single files into workspace for the entire project, such as README or something else.

I seem to be able to add files to the 'workspace'  by just using file > open.  However, they don't show in the workspace side bar, so can't do things like rename when doing versioning numbers. Also 'gitlens' doesn't seem to track them either.

Or, to put this in different words:
I can create a workspace from a couple of folders.  But if I want to add a couple of files as well, I can't get the same workability The .workspace file seems to record the files that I have open but as they don't show in the side bar ....

.gitignore, README and docker-compose.yml(my case) are the good examples to be in the root of my app folder.
Besides, I feel weird that although I can't add those files to my workspace I can just open a new window to open my app folder. All files inside my app folder will show but I can't debug my app like when I use workspace.

Yes please.
Due to the setup of the repository I'm working in, a particular project might have its own subfolder but also has to have a package file at root-level. Would be great to have the package as part of the workspace.

And i would say even more. Due to the project specific that i'm working on, i have several c# projects in the several folders that included into one visual studio solution. And there are hundreds of xml files in this folders that can't be made as part of solution.
So it would be really great and convinient to include all of them into vs code workspace by simple pattern like \xmlfolder**.xml

I am closing this "as designed". This is not a scenario we will support anytime soon. Please also see https://github.com/Microsoft/vscode/wiki/Issue-Grooming#out-of-scope-feature-requests

@bpasero I have to wonder if the bar isn't being set a bit high.  There's an under-diiscussion label for bugs. Maybe the same is required for feature request.
@others since contributing to this thread have wondered at times if it is actually desirable:

I have started using symlinks as a work around,  storing the files in the main folder and placing external links to these where needed.

Other IDE's don't have, or may not have this feature. This feature would limit the intersharability of code and makes me wonder about my support for it.

Looking at the criteria in https://github.com/Microsoft/vscode/wiki/Issue-Grooming#out-of-scope-feature-requests, I'm a little confused why this was closed.

Does the functionality described in the feature request have any reasonable chance to be on the next roadmap?

This doesn't really seem to be a criterion on its own. It's very dependent on (2) and (3).

Are the costs to implement the functionality reasonable given the size of our team? I.e. can we afford the feature?

If allowing some loose files or folders at the same level as project folders has a particular high cost, it would be helpful to get a brief explanation why that is the case. The project folders themselves would seem much more complicated to implement, given all the special UI treatment they get. I would also argue that allowing a .vscode folder for the whole workspace, rather than embedding settings and launch configuration into the code-workspace file and ignoring certain settings set at the project-level that conflict (like zoom), you would end up with a much cleaner, "fully baked" system.

Has the community at large expressed interest in this functionality? I.e. has it gathered more than 10 up-votes or more than 10 comments over the last 6 months? Just for reference, the up-vote criterion alone covers more than 500 feature requests as of right now, September 10th, 2018. We also look at the duplicates for this analysis.

This post has 28 upvotes in the last seven months and this comment will be the 10th.
Would the team consider giving this one more look?

30th Upvote.
I was very glad to start using workspaces, instead of having my entire root folder in VS Code which has word documents and crap. I was able to just have the main folders I code in (Web, API, and DB for this main project I'm on).
I was surprised to find I couldn't add a couple other files to the workspace that would be nice to show up right next to the main folders. Specifically Readmes would be nice and also I like to put the API .sln there so I can quickly go to view it in explorer and open it in VS (I avoid going in there).
Anyway, this seems like it would obviously be on the roadmap to go along with Workspaces as they are. If there's a ton of other backlog more important I'd get a delay but to close this seems wrong.
If a workspace files feature is so far down on the list that it will never get done, then workspace folders should be right there with it and shouldn't have been done. I'm not following the logic that implementing with folders was important enough to do and just stop there...

@TuxVinyards
Thanks for suggesting Symlinks, I ended up going this route as well for a workaround and it's not too bad, basically achieves what I was trying.
I added a "Links" folder to my workspace which just has a list of Symlinks to files I wanted to include in the workspace.

There does seem to be interest for this feature.
Maybe an easier way to implement this would be the ability to hide files/folders from the workspace structure?
I wouldn't mind adding the entire root folder and then choosing what I don't want to see in the explorer, probably.
This approach also makes more sense in cases where you create new files in the project, they would automatically show up in the explorer if they're not in an exclusion list, otherwise you would have to manually add new files to the explorer.

@MrGoDuck @TuxVinyards
Yeah, that would work and offers plenty of flexibility - I would absolutely be in favor of that.
PS - My hard links are breaking (not sure which app is overwriting files but it happens - I hope it's not VS Code). So I had to get rid of my "Links" folder. I am back to just searching for the files I'm looking for when I'd ultimately like hard links in the root, included in the workspace.
Ex of the ideal:
API
-Models
-Model.cs
-A bunch of other files crowding the space...
Web
-Models
-App Model.ts
-Etc.
AppModel.ts (h link included in ws)
APIModel.cs (h link included in ws)
A bit unrelated but it seems like VS Code might be the one breaking my hard links...! I had the two links in a "Links" folder included in the workspace and it was working perfectly for a session and then broke. I didn't open the files in any other app.

@MrGoDuck Sounds like the start of an algorithm. What are you like at Typescript? Might work adding lines to the .jsn. manually ..
Not tried the above. @MrRobboto my symlinks method is still working for me. Maybe VS Code doesn't play nicely with links? I have only 'real' files in the working folder. The outside files as links works but does have limitations. Maybe an OS issue?

I found it hard to believe I could not add files to my workspace. Please reconsider this feature request.

We need this to be able to work efficiently per feature development !

I too found it ridiculous that this was not a feature.

Yes. Please add the ability to add individual files to the workspace.

+1

Please add the ability to add individual files to the workspace by some pattern (e.g. *.txt).
Thank you.
Best regards,
Ivan Grechko
On Wed, Nov 28, 2018 at 11:25 PM +0300, "safield" notifications@github.com wrote:
+1
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

+1 MS PLZ
I have a walk around:

I add folder that contains files I need.
I install Make Hidden extension.
I hide files that i do not want to see in my workspace.

@EstevezCarlos
This should be available without the use of an extension.

@MrGoDuck
100% Agree. So I voted +1 for Microsoft to see we need this.

@bpasero, this has gained a lot of traction since you closed it. Please reopen.

@bpasero
Possible use-case: You want to see some temporary files from other directories while working in your project-folder. You can not add the entire Temp-folder because it contains so many files.
No feature???

Would also really like this feature!

This should really be considered - how can this not be useful?

Lol, there is workaround, my workspace file:
{
"folders": [
{
"name": "bin",
"path": "bin"
},
{
"name": "etc",
"path": "etc"
},
{
"name": "Source",
"path": "src"
},
// as file
{
"name": "Makefile",
"path": "./Makefile"
}
}

+1
Basic functionalities enabled in every other ide available.

Good news! Though undocumented, individual files can be referenced in a workspace. Open your_project.code_workspace as a file (if confused, simply use notepad, etc. Not vscode).
Then, create a Folder element that simply refers to a file. I.e.
your_project.vscode_workspace:
other settings here
...
 "folders": [
          {
                "path": "Readme_haiku.txt",
                "name": "!Readme (poem)"
          },
         {
                "path": "roles/pki.settings",

          },

...

@malefficient  Doesn't work for me.
Got 'spawn ENOTDIR' error.
https://github.com/Microsoft/vscode/issues/63226

Sorry to hear that :\  FWIW I'm running the latest insider version:
Version 1.35.0-insider (1.35.0-insider)

Hi @malefficient. Is it possible to add several files in the following way: "path": "*.settings" for the folder element?
Best regards,
Ivan Grechko
On Thu, May 23, 2019 at 9:28 AM +0300, "Johnny C" notifications@github.com wrote:
Sorry to hear that :\  FWIW I'm running the latest insider version:
Version 1.35.0-insider (1.35.0-insider)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Good news! Though undocumented, individual files can be referenced in a workspace. Open your_project.code_workspace as a file. (If confused by this, use something other than VSCode. Notepad, etc.)
Then, create a Folder element that refers to an individual file.
I.e. 'Readme_haiku.txt' below.
your_project.vscode_workspace:
...
 "folders": [
          {
                "path": "Readme_haiku.txt",
                "name": "!Readme (poem)"
          },
         {
                "path": "roles/pki.settings",

          },
...

be warned, this breaks other functionalites like Debug Multiple-function-projects)

As a devops, I also think it would be very useful to have individual files in the workspace (ie: instead of adding an entire /etc folder, I could be able to add only files I'm interested in for my sysadmin tasks, like my.cnf or samba/smb.conf).
Even better: it would be great to organize these files in logical groups (ie: "db" group with my.cnf, "other services" group with samba/smb.conf and cups/printers.conf, etc...)
"fileGroups": [{"name": "db", "files": [{
"name": "mysql config",
"path": "/etc/my.cnf"
}]}, {"name": "misc", "files": [{
"name": "samba",
"path": "/etc/samba/smb.cnf"
}]}]

The Favorites extension seems to be a decent substitute for this feature. However, I would prefer to simply add files to the workspace as I think this would be very useful.

{
"path": "README.me",
"name": "MyReadme (on root)"
},

@manivi For me it shows the files in VScode but I cannot open the file. It is handled like an empty folder.

I just can't understand this "It's not a bug, it's a feature" attitude.
I usually scaffold related projects in a single metarepo set to track my dev server (so I can upstream-track the children repos) together with folders for integration tests, building tools and artifacts and an an ever-increasing number of related files.
One of these files is a .code-workspace which is, as the rest of them, obviously part of the project.
I believe this kind of scaffolding, either gitted or not, is increasingly common. And whatever the argument, or excuse for wontfix, it seems hard to understand why any of them (especially .code-workspace) should remain outside the explorer.
I think this petition has gained significant traction so as to deserve a place in a (albeit distant) milestone.
Meanwhile I'm relying on a nasty hack to overcome this limitation and the jerky globbing of files.exclude in multi-root workspaces:
{
    "folders": [
        {
            "name": ".",
            "path": "."
        },
        {
            "path": "back"
        },
        {
            "name": "data",
            "path": "_data"
        },
        {
            "path": "front"
        }
    ],
    "settings": {
        "files.exclude": {
            "back/": true,
            "_data/": true,
            "front/": true
        }
    }
}

I've written a little script which makes the .code-workspace while preventing any project dirname from matching with some inner dirname by prepending it with an underscore. I hope that it may be of some help to somebody.
from pathlib import Path
import json
import os

# not project dirs, they only belong to the metarepo
metadirs = {'.dev', '.git', 'bin', 'dist', 'docs', 'tests', 'vendor'}
template = {
    'folders': [{'name': '.', 'path': '.'}],
    'settings': {'files.exclude': {}}
}

def make_multiroot_workspace():
    # It's inside './.dev', hence the '..'
    root = Path(__file__).parent.joinpath('..').resolve()
    dirs = [d for d in root.iterdir() if d.is_dir() and d.name not in metadirs]
    for d in dirs:
        walk = os.walk(root)
        next(walk)
        if any(d.name in dirs for _, dirs, _ in walk):
            d.rename(d.with_name(f'_{d.name}'))
            v = {'name': d.name, 'path': f'_{d.name}'}
        else:
            v = {'path': d.name}
        template['folders'].append(v)
        template['settings']['files.exclude'].update({f'{v["path"]}/': True})
    root.joinpath(f'{root.name}.code-workspace').write_text(
        json.dumps(template, indent=4))

I am working on projects where there are a few files in a massive build environment that need to be updated in a coordinated fashion. I don't want to add folders, because there are too many files in there that are just completely irrelevant for the particular project (and I don't want to wast time searching them for every search that I launch in my work space).
So my projects should be workspaces with nothing but files added to them. And I then I want to context switch from one workspace to another, with only the files associated with that workspace, and not the other files in the same folder as the files I'm working on...
Here is to hoping that my comment with the flood of others makes for reconsideration of this feature as a valuable feature that make VSCode the go-to editor for developers...

It is highly welcome if this functionality could be included.

There are currently 28 people signed up for notifications on this issue.  It continues to stay active despite its status being auto-changed to 'closed' during a mass crud cull this time last year.
Given that the development team have over 5000 open issues at present & that they even have to use a bot to scan those, I find myself struggling to see why they would even continue to look at the 68,000 'closed' issues.
I would like to refer people a thread that currently has an 'open' status. I am wondering if this might be a target for us all to bump up.
@johndog :   https://github.com/microsoft/vscode/issues/73511

Also, spotted this seemingly new addition to Code's inner workings:
"the idea of FileType is that I can have FileType.SymbolicLink | FileType.Directory so that I can signal both types right?"   https://github.com/microsoft/vscode/issues/71055
Long shot but might this fire up someone enough to create something for a pull request?

Another common use case: having a simple workspace to manage personal config files like ~/.bashrc, ~/.gitconfig, ~/.vimrc, &c., without opening one's entire home directory.
Is this the sort of thing that would be open for user contribution? (Not that it's like I'd have time in the near future, but prima facie it doesn't seem like it'd be a large delta.)

Our repo has several components in it, each with subdirectories and files (such as Dockerfile, docker-compose) at the root level. To make a workspace for an individual component I cannot directly include the single files, instead I have to exclude all the others. This is time consuming and the workspaces tend to become out of date. When you add a file to root level you have to exclude it from all of the workspaces.
Would love to see this addressed.

My workaround right now is to add the current folder to the folders list in .code-workspace.
{
  "folders": [
    {
      "path": "projects/frontend",
      "name": "frontend"
    },
    {
      "path": "projects/backend",
      "name": "backend"
    },
    {
      "path": ".", //  <---------------------- THIS
      "name": ".workspace"
    },
  ],
  "settings": {
    "files.exclude": {
      "**/node_modules": true,
    }
  }
}

You could add the projects folder to the files.exclude list, but I found that to be unnecessary.
Hoping that helps someone!

I'm using Nordic's SDK which has MANY directories with different drivers, etc.
I really need FILE specific control not general globbing. A files EXCLUDE list is hilariously backwards (imagine if when compiling we listed all the directories we DIDN'T want include files from).
I'm puzzled why MS team feels this is so problematic/not worth the time. I'm a dev. That's all I do. Been doing it for some time.
This feels like people who were never devs made decisions.

Recently I've been using this extension which adds a 'Favorites' view and stores its data in the .code-workspace file by default. There are other similar extension available too.

I would love to see this feature added.  One practical example are credential files that are such as that for azure or aws, a number of different projects refer to this file but none of them own this file.  When I need to update the credentials I need to manually open the file each time.  It would be super handy to have this in workspace

Create a separate folder and symlink scattered files into it, then add the folder to your workspace.

I'm up for this too!

Let me clarify to Microsoft and others. My use case (and there are actually others) is that the SDK I'm working with is NOT IN my repo nor do we want it to be. It is in a different directory (lets call it two directories above for fun).
I need files IN MY PROJECT that come from this SDK. Copying them into my repo is not reasonable because when there are bug fixes to the SDK I do not want to have to copy the many files (or worse, remember which files) -- I shouldn't have to.
The point is, project files should make things EASIER not more difficult for the user. It has been two years and still, nothing. We CAN NOT move our project to VSCode because we have to include SOURCE files from the SDK (not just headers). All of this has to be compiled.
Symlinks in a repo is just a bad idea all around.

Is this feature planned??, they should consider the possibility to show files in workspace root tree

+1

I would also welcome this feature. My use case is that I have some important files that is global to the project located in the root folder of the project. Next to the workspace file, that is.
I have to add subfolders like app, backend, docker and such to the workspace rather than opening the whole root folder as one. The main reason for that is to have ES-Lint (and extension that relies on it) function properly.
With this setup, I can't see the files in the root folder of the project.
The optimal solution for me, would be to have the option to add with some matching syntax, perhaps something like this:
"files": [
	{
		"path": "./",
		"match": "*.*",
	}
],
"folders": [
	{
		"path": "app"
	},
	{
		"path": "backend"
	},
]

A very long waited feature indeed. Lacking this feature is what makes us bouncing between VSCode and other IDEs.
In our project repo we have different flavors of products that sometimes require different set of files. We can do it on makefile level, but we can't achieve it on IDE level with VSCode. On Win32 platform we can resolve it with MS VS, but on Linux we have to go for other alternatives. It would be nice to use the same IDE, and it would be great if it were VSCode.

+1 for me.
My use case:  I have a bunch of files in one folder that make up a library of bash functions.  I've created a workspace for those but it's a royal PITA not to be able to include my .bash_profile and .bashrc files in the workspace, without including my entire home folder.
I've read all the above, and the other issue flagged as a duplicate of this one.  I'm happy to see this has been reopened, and now added to a backlog, although a little disconcerted that it's somewhere in the middle of a milestone that has 2200 other issues in it.
This issue has gotten a lot of votes and traction and has now been an issue worth discussing for some people for two and a half years.  Any chance this can be prioritized? 😊

symlinks in a folder don't work. Is there another solution?

I basically have config files in the root of my project that I'd like to include in my workspace.

+1

Another workaround that I have is to just create an alias by leveraging the code command. So if i wanted to create a workspace for all of my ZSH files (for instance), I just added this alias to my .zshrc:
alias edit='code -n ~/.zshrc ~/.zshenv ~/.zlogin ~/.zlogout ~/.zcompdump ~/.zsh_history'

I've never realized that you couldn't add a single file to the workspace until I had to add a single file 🤯 😵
@bpasero do you have any estimates of when this functionality should be available?

I've never realized that you couldn't add a single file to the workspace until I had to add a single file 🤯 😵
@bpasero do you have any estimates of when this functionality should be available?

"files": [
	{
		"path": "./",
		"match": "*.*",
	}
],
"folders": [
	{
		"path": "app"
	},
	{
		"path": "backend"
	},
]

This is an excellent solution.
An "only folder" approach, nuanced narrowly by an "exclude file" list which doesn't handle lookaheads very well seems pretty shortsighted.  Once you're using JSON-based file setting, why make such narrow use of it?
The greater the sophistication of the terms of a Workspace the better, files and folders both, whether you want to include or exclude classes of files, whether it involves regex, lookaheads, lookbehinds, or just a brute force list of files and/or folders.

++supporters;
In my use case I would like to support VS Code IDE for a rather complex project structure of several nested sub-projects for embedded applications. Depending on the platform, different source files are relevant to a project, which are located in individual sub-directories or even within the same directory. If those directories and files are not filtered correctly, there are ambiguities, which can not be resolved by the IDE.
For this reason I am still using QtCreator, which supports these features for years now (decades even?), but has become less popular so I feel the need to extend the list of supported IDEs for my project.
I'd also like to mention another use case: add folders without sub-directories.
Imho, adding sub-directories by default is an undesired behavior (e.g. I don't want to have any build/ folders in my workspace) and should be stated explicitly, like
"folders": [
	{
		"path": "."
		"recursive": "true"
	}
],

For the sake of compatibility, however, I guess recursion has to be the implicit default and needs to be deactivated explicitly.

+1
Use case: Working in a large company, where folders tend to contain 100 files, but I'm only interested in 1 per folder.

Any movements in this direction? I need either be able to add a single file to a workspace or filter in or out files in an added folder.

Any movements in this direction? I need either be able to add a single file to a workspace or filter in or out files in an added folder.

Maybe the best thing about VS Code is that it's codeable.  Rather than wait, assuming you have patience, you can build your own extension with your own custom view in the Explorer.  At that point you can extend the .code-workspace in any way you want: a "files" array that will hold an unlimited number of paths, wild cards, even complex regex searches if you want.  It takes some work, but by the time you're done, you realize you can make VS Code do anything else as well.

Took me a bit, but I was able to find an... acceptable workaround for my specific use-case
TL;DR:
Add the root folder to your workspace:
./workspace.code-workspace
{
  "folders": [
    // Backend Code
    {
      "path": "./backend"
    },

    // Frontend Code
    {
      "path": "./frontend"
    },

    // Infrastructure as Code
    {
      "path": "./iac"
    },

    // The root directory
    {
      "name": "root",
      "path": "."
    }
  ],
}

Then, add settings to the root folder (NOT the global settings defined in the code-workspace file) that hide the other directories in the workspace
./.vscode/settings.json
{
  "files.exclude": {
    "**/backend": true,
    "**/frontend": true,
    "**/iac": true,
  }
}

This will give access to all the loose files in the root directory, without cluttering up the workspace with redundant directories. The main downside to this is that using the workspace becomes required in VSCode, since most of the files are hidden if opening the root directory directly
Using the workspace like this produces the following result:

For context... I am working in a directory with the following structure:
backend/
frontend/
iac/
.conf.default.js

The idea is that all three sub-folders are distinct projects (with their own project.json files and everything) but they share a single config between them. During development, it's critical that the config file is accessible for editing, but we are unable to just open the root directory directly because we are using Vuejs and a lot of the VSCode Vuejs tools make assumptions about what should be found in the root project folder
Workspaces are a good way of dealing with this, but not having the ability to add loose files to a workspace means this janky workaround is required :(

News on this please?, this feature is a must on a workspace concept, thanks!

News on this please?, this feature is a must on a workspace concept, thanks!

still workarounds

+1
Use case: Working in a large company, where folders tend to contain 100 files, but I'm only interested in 1 per folder.

+1 Same use case

+1
Use case: Working in a large company, where folders tend to contain 100 files, but I'm only interested in 1 per folder.

+1 Same use case for me

Another +1 for the same use case

Agreed. This is ridiculous.
This feature should have been included from the get-go.
Hacks are not a solution.

+1. It's hard to believe there's no way to achieve this.

Also would appreciate to add single files to a workspace

I may be over simplifying this, but couldn’t VS Code implement this by having a dedicated .single-files folder in .vscode then, when a user adds a single file to the workspace, VS Code just:

Creates a symlink to the file in .single-files
Adds .single-files to the workspace
Displays the folder as ‘Single Files’ in the file explorer.

Then whenever a user removes the file from the workspace you just delete the symlink.

Over complicating! All this needs is an array of filenames in the workspace file format, TBH.
Symlinks behave differently depending on the OS and Viscose is a cross OS product.
Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: Russell Hawkins @.>
Sent: Friday, April 15, 2022 2:44:56 PM
To: microsoft/vscode @.>
Cc: Keith Jackson @.>; Comment @.>
Subject: Re: [microsoft/vscode] Allow "files" field in .code-workspace file (#45177)
I may be over simplifying this, but couldn’t VS Code implement this by having a dedicated .single-files folder in .vscode then, when a user adds a single file to the workspace, VS Code just:

Creates a symlink to the file in .single-files
Adds .single-files to the workspace
Displays the folder as ‘Single Files’ in the file explorer.

Then whenever a user removes the file from the workspace you just delete the symlink.
—
Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode%2Fissues%2F45177%23issuecomment-1100119079&data=04|01||e844f67a8ae34375ea6408da1ee6292f|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637856271116124492|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=jAwopbqIYHU2UCdFqXblNv8UpV8POIDrH60MfQyOlq8%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAN6CYPEEFOLONXBWMXMPFLVFFXFRANCNFSM4ET7XQAQ&data=04|01||e844f67a8ae34375ea6408da1ee6292f|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637856271116124492|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=qMBmoICme%2F2jwb0jahagePTs8NPuGfCaQQgMlY4BaRU%3D&reserved=0.
You are receiving this because you commented.Message ID: @.***>

Agree, no need for symlinks: I think that a JSON file in .vscode where we can organize individual file's path in groups would be fine for +90% use cases

Ah good points! Agreed.

This thing has been open for over 4 years and nothing happened.
Do they even care ?
Has the issue any chance to be solved ?
This is quite frustrating.

+1. Need this with similar usecase with the ones mentioned in earlier comments.
Would be a great feature to have without having to resort to hacks.

Meanwhile, is there any extension that adds this feature to VScode what anyone is aware of?

bump for updates

Bruh, I didn't need this until I need it now, and to come think about it, it seems absurd that such basic request is been around for more than 4 years and still being ghosted on. Ridiculous and embarrassing.

Absolutely necessary feature! Workspace doesn't make much sense without it.

Encountered the need of the feature recently (for workspace-wide docker-compose.yml); Please add this feature to VSCode Workspace, this will be really useful for people.

How in the world is this missing?

VSCode is free, open-source software, which means two things:

Nobody owes you a feature, no matter how obvious, fundamental or important it may be.
You have the option of contributing to the project.

I'm subscribed to this thread because I'd like to follow the conversation and find out if/when there's a better solution to the workarounds people have already shared (you can use those, btw), but please stop posting comments unless you're trying to move the conversation forward.
(P.S. I'm sorry for adding more noise.)

VSCode is free, open-source software, which means two things:

Nobody owes you a feature, no matter how obvious, fundamental or important it may be.
You have the option of contributing to the project.

I'm subscribed to this thread because I'd like to follow the conversation and find out if/when there's a better solution to the workarounds people have already shared (you can use those, btw), but please stop posting comments unless you're trying to move the conversation forward.
(P.S. I'm sorry for adding more noise.)

Quite a useless, unhelpful comment.
Among other things:

Users requesting features is one way to contribute to make a software better.
No need to tell us what we already know. Tell us something we don't know, or keep your useless comments for urself.

Who are u to tell people to stop expressing feature requests or their views ?

Next time, I will use ur comments to my boss who regularly wants new features. I will tell him: "well, dude, if u're not happy with the software I shipped, maybe u could code it urself".

@infinity7592 is your boss not paying you then?

Next time, I will use ur comments to my boss who regularly wants new features. I will tell him: "well, dude, if u're not happy with the software I shipped, maybe u could code it urself".

@infinity7592 is your boss not paying you then?

Does it make a difference to the reasoning ?
If I developped some tools for free in my spare time, it wouldn't be an excuse or reason to provide ill-conceived software or not taking up feature requests, or dismissing user's views.

Next time, I will use ur comments to my boss who regularly wants new features. I will tell him: "well, dude, if u're not happy with the software I shipped, maybe u could code it urself".

@infinity7592 is your boss not paying you then?

At the end of the day VSCode is primarily developed by salary Microsoft employees, and is 100% a strategic commercial play by Microsoft. This isnt a FOSS product like VIM or emacs.

VSCode is free, open-source software, which means two things:

Nobody owes you a feature, no matter how obvious, fundamental or important it may be.
You have the option of contributing to the project.

Nobody owes us a feature, but demand for this one continues to grow, yet it doesn't seem like anyone from Microsoft has taking a look at it since @bpasero unceremoniously closed it on September 11, 2018, saying it was "out of scope" (whatever that means). I'm ultimately more frustrated over the four-year silence by the maintainers than the absence of the feature. Keeping a community happy is as much about communication and transparency as it is about giving us what we want.

As for contributing actual code (if that's what you meant), pull requests that haven't been discussed with the core maintainers of a project of this size are unlikely to be accepted, so I don't think that's a solution in this case.

I also want to be able to add a single file to multiple root workspaces, simply because I want to use VS Code instead of Notepad++ to open multiple files in different paths and automatically open those files the next time I open the software.

Guess there are many people who have the same idea as me, use VS Code to replace other editors in the computer

+1

Is it that complicated?

+1
I want the feature, very much.

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding, and happy coding!

This is essential for a monorepo structure where you might have multiple workspaces in a repo - but need to include some but not all top level files in each workspace

I understand the end of year housekeeping of issues. But could you please suggest if there is another open issue which talks about this ask which is not necessarily about .code-workspace file?
This is one key thing available even in Notepad++
As a code editor, it is kind of an important requirement don't you think? You could merge this with another feature request if needed.
Can this be reconsidered as a feature request if not an issue. So this feature will have scope of it own. That we need files support in workspace.

You might get a better response from the hundreds of people interested in this issue giving an explanation about why workspaces should not have individual files. There have been many valid use-cases noted in the 100+ comments.
Your only contribution to this issue has been to say "out of scope", then "in scope" a year and a half later, and then "out of scope" again three years later. I think they deserve a little better than that.

Is this feature hard or are there other features that are so much more urgent?  It’s just odd to see a feature with so much community interest get so little priority.
In case it matters, the request is for vscode to track individual files where a folder is too large in scope, and a ‘files’ field isn’t necessarily the only way to do that.  A "filtered root” might be a better fit for the schema.  I personally opened:
Allow addition of individual files to a workspace · Issue #73511 · microsoft/vscode (github.com)https://github.com/microsoft/vscode/issues/73511
That was duped to this issue, #45177.
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows
From: Benjamin @.>
Sent: Tuesday, December 6, 2022 8:36 AM
To: @.>
Cc: John @.>; @.>
Subject: Re: [microsoft/vscode] Allow "files" field in .code-workspace file (#45177)
The intent of a multi-root workspace file is to list folders of the workspace, not files. This issue is marked as "out of scope" because neither did we plan to add support for files when this issue was reported 4y ago nor do we currently plan to add support for this.
Please see #167999https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode%2Fissues%2F167999&data=05|01|johndog%40microsoft.com|dac563e8449f4d86cf8108dad7a8073f|72f988bf86f141af91ab2d7cd011db47|1|0|638059413924936816|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=avtJbxIhQFFXp6NuglpwIWGIR9StwFCQcalf%2F5HSa6s%3D&reserved=0 for our plan this month to clean up and "groom" all opened issues.
—
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode%2Fissues%2F45177%23issuecomment-1339647574&data=05|01|johndog%40microsoft.com|dac563e8449f4d86cf8108dad7a8073f|72f988bf86f141af91ab2d7cd011db47|1|0|638059413924936816|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=SnTD36FrFoBD0ExyL%2BAU0ymr6y4NyHrcEs5kY6CpXm4%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFJPJFCMIUO3AA4IETZR75DWL5TQ3ANCNFSM4ET7XQAQ&data=05|01|johndog%40microsoft.com|dac563e8449f4d86cf8108dad7a8073f|72f988bf86f141af91ab2d7cd011db47|1|0|638059413924936816|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=6GSzLq9uiXs8AA%2F%2FLkgcVhSePiE5a975v8ZAzXRvx8Q%3D&reserved=0.
You are receiving this because you were mentioned.Message ID: @.***>

The intent of a multi-root workspace file is to list folders of the workspace, not files. This issue is marked as "out of scope" because neither did we plan to add support for files when this issue was reported 4y ago nor do we currently plan to add support for this.
Please see #167999 for our plan this month to clean up and "groom" all opened issues.

@bpasero,
You're basically saying,, "We don't want to build this because we didn't envision building this before people started using it." It's great that you had a strong vision, but you now have real-world evidence of what developers need, yet for some reason, you seem to be anchoring hard to your original idea rather than being open to new possibilities. I appreciate you chiming in to let us know your plans, but many of us would really like to understand beyond a superficial level why you think this is out of scope.

Sure, its totally fair to ask for reasons, otherwise I would have locked this issue to avoid discussion and I am happy to have this discussion, that is why I am still engaged here.
Workspaces are an incredibly complicate thing for users to understand, once we introduced multi root workspaces. This made me eventually write this document, unfortunately only years after we had released support for multi root workspaces: https://code.visualstudio.com/docs/editor/workspaces
It is still complex, as you can see from the length of the document.
Having yet another dimension into what a workspace is - by adding loose files to it, I fear makes this even more complicate. To throw in a few things:

what is a workspace without folders but just files? do we even allow for it?
how can a user distinguish a single-folder workspace with a multi root workspace that has top level files?

Especially the last point worries me: a multi root workspace behaves different from a single folder. For example, you cannot just drag a file out of one folder to the root to copy it to the root. Visually users might get soon frustrated that a file explorer that looks like a single folder workspace does not behave like one.
We did not really enforce it in all themes, but our minimal theme has a notion of distinguishing a root folder from another folder within making it easier to understand these concepts:

Now maybe towards alternatives, throwing in some random ideas:

using symlinks for this purpose, to link loose files into the root?
adding the parent folder of a loose file to the workspace and configuring files.exclude rules to only show that file?

The issues you mentioned are not related to functional features, but to visualization of workspaces only. I understand that there might be concernes about "loose" files at this point, but I'd expect this to be easily addressable by some additional visual hints to the user.
The original issue of this thread, however, is of functional nature. Your proposed alternatives are no solutions, because:
Symlinks potentially mess up compile chains, project files of other IDEs or whatever. Actually, I can hardly believe that you seriously proposed to "fix" VSCode via the file system.
Excluding all unintended files works well until for some reason (and there are plenty) another file is generated by or for some other tool. That new file is loaded into the existing workspace and will most certainly confuse users. Moreover, if explicitly excluding files is a viable option, I do not understand why explicitly including files is not.
As others pointed out, this is a basic feature even rudimentary editors support and developers simply expect it to be there. In my use case, this missing feature is the only reason why almost none of our developers use VSCode, although most rate it among their favorite IDEs. They can adapt to hiccups of other IDEs which are less efficient, but they cannot adapt to broken projects/workspaces.
I apologize if my comment is a bit rough, but it is really frustrating to see that a highly demanded feature request by the community is rejected to be out-of-scope. Maybe there never was an intent for VSCode workspaces to list individual files, but afaik there was the intent to act on user feedback.

From your reply, I understand the main problem is explaining to users how the "files" workspace would work.
Would it help calling this feature as a "per-project bookmark/favourite files list"?
It would get its own "root folder", visually distinct from other real folder (distinct icon?)

I think a good metaphor for this problem is git and its sparse-checkout feature.  A git repo has a root, but when you sparsely checkout the tree, you have a filtered view of that tree on disk.  The sparse checkout list is a list of file path patterns that essentially filter the look.
Applying this metaphor, the top level schema of multiple-roots can be maintained as-is; your multi-root workspace is still a set of root directories.  But now you would have the ability to filter which files are visible to (and within) vscode for each of those directories.  If you want individual files, you add the root directory containing it, then specify a filter.  If there was an "add individual file" feature (which isn't technically required), it would be translated into this process.

@tschoepping

The original issue of this thread, however, is of functional nature.

I think most issues start like that but almost all changes have an impact on UX. We cannot just ignore the UX problem when we fix a "functional" issue. I think I made the UX challenge clear in my comment, so I will not repeat it. But maybe I add a point to it: workspace files can be crafted by someone that understands the concepts but then used by many that do not. We try to make workspace files as simple as possible to reduce the friction.

Moreover, if explicitly excluding files is a viable option, I do not understand why explicitly including files is not.

👏 , I think we are getting somewhere constructive. I think https://github.com/microsoft/vscode/issues/869 will help here a lot and I agree it is needed for this purpose.

As others pointed out, this is a basic feature even rudimentary editors support and developers simply expect it to be there.

Can you give me an example of a "rudimentary" editor to look at? Maybe there is another solution possible that does not involve making changes to workspace files?
@dlordi

Would it help calling this feature as a "per-project bookmark/favourite files list"?

Maybe, but then on the other hand I think a workspace file can be used for this in combination with https://github.com/microsoft/vscode/issues/869, so we would not have to bring in another concept? You can even change the name of the workspace folder in the .code-workspace file to make clear the folder is about some loose files of the repo.
@johndog

I think a good metaphor for this problem is git and its sparse-checkout feature.

Yes, we support that but limited to folders only for the sake of simplicity.

@bpasero
I agree that UX is very important and one of the biggest strengths of VSC, imho. However, your statements sound like you don't consider any functional changes that might entangle modifications/challenges for the UI categorically. Of curse, any functional change must be communicated clearly to the user to be useful.
That said, deliberately not supporting files is a "feature" that needs to be communicated to users as well. But as this thread and the other one you pointed out (#869) show, communication in this regard is clearly lacking. Everyone understands the concept of files and folders, but nobody seems to understand, why VSC does not intent to support files the same way as folders, causing a sort of "friction". Perhaps there are reasonable arguments for this decision, but so far they have not been communicated clearly (for 7 years!).
As mentioned earlier, Notepad++ supports this feature as a simple editor. QtCreator is a more sophisticated example, supporting this as well. The approaches they take are rather cumbersome, imho, and I definitively prefer the JSON-based method of VSC. Perhaps you should have a look at SublimeText.
In any case, a solution to this issue will most certainly involve changes to workspace files, simply because it is about the contents of workspaces.

@tschoepping it is probably not a secret that multi root workspace files were inspired by Sublime Text Projects and thanks for pointing out to revisit their documentation. From https://www.sublimetext.com/docs/projects.html I see no evidence that I can add files to a project. From my testing I am not able to add loose folders either.
However what I find cool is support for configuring what to include/exclude in any of the roots. So given a project config of this:
{
	"folders":
	[
		{
			"path": "/Users/bpasero/Desktop/test-ts",
			"file_include_patterns": ["package.json"],
			"folder_exclude_patterns": ["**"]
		},
		{
			"path": "/Users/bpasero/Development/Microsoft/vscode"
		}
	]
}

The result will be:

I find this a good approach and it goes into the direction of what I had mentioned in #869

FWIW I built a personal extension.  Haven't posted it b/c of its limited scope, but the basic idea is this:
It creates a new Sidebar Panel (in addition to the existing Workspace Panel.  I think everyone would prefer to simply extend the existing Workspace panel).  It uses the same (albeit modified) .code-workspace file.
The original plan was to create a panel whose file list would be populated

by the existing "Folders" array in the 'workspace' file
by a newly-added "Files" array for additional items
by an array of regex entries, so that file items could be included dynamically.
There's really no limit to what's possible.

I got as far as the "Files" array, it worked, and discovered the others weren't even needed, at least not immediately, so to date haven't gone back and elaborated the extension.  Haven't used the built-in Workspace panel since.
In the end it would seem there's probably no need to even distinguish between "Folders" and "Files" or even a "Regex" arrays.  They could all be listed in one array, and a bit of coding could figure it out.

It would be a really useful feature. I have a Workspace that includes an admin-like folders for quick settings change like .ssh, .dbt folders but I would like there singular files that are also important like .gitconfig

Thanks, @tschoepping, for the stack overflow answer. I have used it to do this walk arround :

So I add the "folders" I want and the folder with everything too (the last "folder")
Then I ignore everything except the ones I want. In this case "package.json" but It will be in another "workspace folder" (the one I named Project folder)

I'm wondering if the developers are reacting to the percieved confusion after introducing mulit-root workspaces.
The problem was that the multiple roots can be anywhere. Anywhere just happened to include a folder used ot organize materials for an overall project that needed to treat sub-projects as independently buildable.
The fact that they are independent workspaces makes them independently buildable in Visual Studio code.  Nice
But there's an aspect of this the VSCode project hasn't considered.  The fact that these are in a multi-root workspace implies that there is some relationship between the individual projects, and that there may be some infrastructure above those projects to manage that.  A directory is the place to organize those materials, and it can b a directyory containing only the files that pertain to the project as a whole, without including the sub-project in which case there is not a problem, just add that directory as yet another folder in the workspace.  If on the other hand, you want to organize all the work under one directory, the top level will show each sub-folder twice.  Once as part of "." and once as indivicual roots.  That's what people are struggling with.
So two approaches work.

Keep everyting in one project directory's tree, and use [bdetry's comment from  Dec 28, 2022
use a separate tree for the project level stuff.and include it as just another root in the workspace.

#2 has the disadvantage that terminal now has to be somewhere specific and the hierarchy can't be used causing exactlyl the kind of cofusion the developers of Visual Studio Code are afraid will happen if they simply allow files to be specified as part of the workspace.
Why #1 works is a bit beyond me, but it does and it's good enough.  I hope the developers don't somehow break it, because I'll be using it a lot.
One thing the devs might want to consider is the actual workflows of real people other than themselves actually using multiple workspaces.

I use projects with just a few files all the time - it is often required to make changes in a group of functionally related files that live in completely different places.
Another common use is top level code (perl/python/bash etc.) that uses a relative library dir, but itself lives amongst a bunch of other executables.
I am a recent convert to vs code after decades of using bbedit - for an example of how individual files can work easily and powerfully in a workspace, take a look at bbedit's implementation (they call them projects) - it is excellent and shows that it can be done without any UX confusion.  I greatly prefer this approach over using hard or soft links as they always seem to bite me on the bum eventually...

FWIW I built a personal extension. Haven't posted it b/c of its limited scope, but the basic idea is this: It creates a new Sidebar Panel (in addition to the existing Workspace Panel. I think everyone would prefer to simply extend the existing Workspace panel). It uses the same (albeit modified) .code-workspace file.
I would really appreciate it if you were to release this.

Thanks, @tschoepping, for the stack overflow answer. I have used it to do this walk arround :

So I add the "folders" I want and the folder with everything too (the last "folder")
Then I ignore everything except the ones I want. In this case "package.json" but It will be in another "workspace folder" (the one I named Project folder)

I use this approach and I think it's not workaround. I think this is the correct way.
@bpassero, I think this approach should be on documentation.

To me, it seems like a temporary workaround. The list of "files.exclude" could get very long and this setting applies to every folder so you could inadvertently exclude a "file" (or folder) somewhere else in your project.

This looks like another workaround to me.

Unbelievable that this isn't addressed yet

Actually shocking that this isn't implemented yet. Seems so simple

+1 would be great to see

What kind of confusion would adding a feature that people have been asking for for years entail?
Workaround:
Create a directory for symbolic links to the files you are interested in for a given workspace.
Add that directory to your .code-workspace folders list.
No confusion at all...
Could anyone explain why the vscode development community is reluctant to add this feature?

I’ve started using this workspaces but damn yeah this is really missing feature.

What kind of confusion would adding a feature that people have been asking for for years entail?
Workaround: Create a directory for symbolic links to the additional files you are interested in for a given workspace. Add that directory to your .code-workspace folders list.
No confusion at all, but the extra effort should not be necessary.
I should be able to add something like this to my.code-workspace:
"folders": [ ], "additional_files": [ "path-to-file", "path-to-another-file" ]
Could anyone explain why the vscode development community has been reluctant to add this feature?

THANK YOU! I didn't think of symbolic links and this works perfectly.♥
I tried "macOS-GUI-aliases" before and that didn't work.

How many singular files we have these days to compliment our programming? All the files that start with the dot and so on. It would be extremely useful to have access to files that pertain to our folders and repositories but are stored outside of it .ssh .dbt .bashrc and all the other ones

^per the above i use all these config files frequently and it would be incredibly handy to have this feature.

Here's my ridiculous workaround:

use a random directory as VSCode project
create a FILES.md file and pin it
use markdow links to refer files around the disk, ALT+click to open them

Here's my ridiculous workaround:
* use a random directory as VSCode project

* create a FILES.md file and pin it

* use markdow links to refer files around the disk, ALT+click to open them
  ![Image](https://github.com/user-attachments/assets/561f1cec-bbc6-43a9-9f8d-56b42e2a8c23)

Hey @dlordi, FYI, symbolic links work just fine.

Hey @dlordi, FYI, symbolic links work just fine.

Sure they do, but I feel markdown makes a project more manageable, ie: it can be add to a project versioning, inner project file links are usable in both Win and Linux/Mac, you can have different heading sections that match your logical project structure, each one listing its more relevant files, etc... Anyway, its just an hack: really hope VSCode team will address this issue sooner or later.

Please implement this Microsoft. Seems the most basic of functionality.

authors: Calamitizer Dealerpriest Detnator-Neo EntranceJew EstevezCarlos GraysonFreking IvanG96 Jeffrey-Hall MariuzM Merott MrGoDuck MrRobboto N7K4 Oleksandr-Silin Ovsyanka83 PeterTucker SBANASGH Sneezry ThatGuyRussell TheJoshuaEvans Turburlar TuxVinyards UmanShahzad VSCodeTriageBot a3y3 alex-unikorny alex4998 are-scenic bdetry beltaurus bpasero brent-charlton buster95 callahanp casey6 ch0rl chanced code1line communque devuxer dlordi doc-E-brown elalecs erenseymen fuzzthink gjsjohnmurray gsimardnet hisuwh hubua iireland-ii illustrious-otter infinity7592 ivellioscolin jalovatt jgf5013 jirpok johndog jon-wesneski josiah47 jurzza karimmortabit kevcmk lloydsargent42 maheffa malefficient manivi matias-harding merqrial mijlouis moseleyi nateinindy nmocruz nuno-andre paaksing patrick330602 qiulang qns7 raosatish safield sfsccn starship863 stuartthomson theanurin thomasrea0113 tiefling tolisaverkios tsanyqudsi tschoepping yujiang


text:
Issue Reporter: Issues arriving with "paste from clipboard" - Instructions or missing logic?

Many issues are coming in like
https://github.com/Microsoft/vscode/issues/60235
https://github.com/Microsoft/vscode/issues/60230
with only version information and the clipboard message.  Is it not clear for people to paste in the detailed info?  we cannot transfer everything directly?  Maybe a warning message to the user before submission?

Closing this since I've added an additional dialog prompt for this case - https://github.com/microsoft/vscode/issues/50659

source: gharchive/issue

authors: RMacfarlane cleidigh

repo: microsoft/vscode

license: MIT

license_type: permissive

license_source: github-api


text:
Please do not use esoteric jargon in the error messages

I'm not sure whether this error is reported by VSCode itself or some extension. Does anyone recognize the cause? It's being displayed in a header file that is part of a Windows node-gyp (C++) project that just builds fine:
http://prntscr.com/nn3zm1
Can someone translate it for me into normal English? Thanks. :)

Please file for https://github.com/microsoft/vscode-cpptools

authors: chrmarti zhulika


text:
Improve error message when trying to save a file that is locked by another program

VSCode Version: 1.35.1 (user setup)
OS Version: Windows_NT x64 10.0.16299
-VSCommit: c7d83e57cd18f18026a8162d042843bda1bcf21f
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32

Steps to Reproduce:

Open a folder containing an XML file (such as a POM) (update: that is opened by another process)
Modify the XML file
Ctrl-S, or File -> Save

(Update - After filing the bug, the thought of "sharing violation" came. When I tried editing using Notepad++, sure enough, the message "Please check if this file is opened in another program." came up. I'll keep this issue here in case someone would want to address VSCode handling file locks a little more gracefully. Thank you. -Robert)

Does this issue occur when all extensions are disabled?: Yes
Also:
Removed extensions. Results are the same.
Also ran VSCode as Administrator. Result are the same.

Error Message:
Failed to save 'pom.xml': Unable to write file (Unknown (FileSystemError): Error: UNKNOWN: unknown error, open 'c:\gitprojs\Panacea-ReleaseUtility\branch\BranchingScriptDir\Panacea-DataTools\pom.xml')

Yah. I just got it and solved it.
You just reboot your system or device that run VS and then retry to run that code.


text:
Edge: Web view sample is not working with http and local resource

Testing https://github.com/microsoft/vscode/issues/78050
Cat coding web view sample is not loading the gif with http or local file resource.

What edge version / os did you test this on?
With  77.0.235.5  on MacOS, I see the image loading but the script sometimes does not execute. Always seems to work in normal Chrome (76.0.3809.100)

Yeah chrome was working. Its on MacOS and edge Version 77.0.235.5 (Official build) Dev(64-bit)

@sandy081 You still see the images not loading as well? This could potentially be https://bugs.chromium.org/p/chromium/issues/detail?id=978325


text:
Can't open a script on Unity

I'm opening a Unity project, which has the latest Visual Studio Code Editor package, when I double click on a script it does not open. In Unity Preferences/External Tools, I set the External Script Editor to Visual Studio Code.
If I open VS Code and "open file..." to open a script in the Unity project folder it still does not work.
What is weird is that other Unity projects work and that this bug in suddenly appearing, I was working properly on that project before.

I'm using Unity 2019.2.0f1.

It was a Rider package that blocked VS Code, I uninstalled it and it works now.

I also ran into this problem with this version and 2019.2.6.  No solution works.

Just started happening to me.  Yesterday was fine.
It seems to only affect specific projects, as other projects open VS code fine..

@ProvencalG what is a Rider package? Could you explain how you got rid of the issue

I had a rogue vscode process. So I manually killed any process related to vscode and it’s launcher. It solved it. It happens from time to time and this still works.

ah resolved for me as well
I was confused as restarting computer didnt seem to help, but ending vs code through taskmanager seems to have done the trick
Thanks!

authors: ProvencalG coreyjs max-pi


text:
VS code terminal cursor does up 2 lines when a closed terminal is maximized with keyboard shortcut

The issue is shown in the following video.
https://youtu.be/nl5efRzhPek

VSCode Version: 1.42.1
OS Version: Windows 10 Enterprise 1809
Using VS code using remote SSH feature of an Ubuntu machine

Steps to Reproduce:

Set keyboard shortcuts as shown in video.
workbench.action.closePanel to Ctrl+ Shift + 2  , and When to terminalFocus
workbench.action.toggleMaximizedPanel to Ctrl+ Shift + 2 and When to !terminalFocus
Open remote-SSH connection
Open terminal and press Enter few times (say 10 times)
Press Ctrl+ Shift + 2 repeatedly.

Does this issue occur when all extensions are disabled?: No
Issue is in remote-ssh and terminal.

I also encountered this problem, it is really very annoying. Is there any progress?

This looks like an issue with our old terminal backend "winpty", going forward we are focusing our efforts on the new backend "conpty" which is build by the Console team at Microsoft and should fix many issues with the terminal under Windows. You can read more about getting ConPTY here.
/duplicate https://github.com/Microsoft/vscode/issues/45693

@Tyriar Actually I'm using ConPTY as my settings.json contains the following Settings
{
  "terminal.integrated.windowsEnableConpty": true
}

@finite-light OP is on Windows 1809 (build no. 17763) in which case that setting is ignored as per it's docs:

Whether to use ConPTY for Windows terminal process communication (requires Windows 10 build number 18309+). Winpty will be used if this is false.

@Tyriar I'm using Windows 18363.

And as English is not my mother tongue, I cannot understand the meaning of OP, can you explain it, thank you.

@finite-light np, OP means original poster; the person who created the issue.

@Tyriar Oh, thanks for your patience to explain, I may have mistaken whom you replied to before. In fact, I encountered the same problem with OP, and my OS is Windows10x64-18363 as mentioned before, do you have any clue?

@finite-light yes you're on the newer version of Windows. Make sure you have the windowsEnableConpty setting set to true. There's another issue which sounds a lot like this but on Linux in https://github.com/microsoft/vscode/issues/91817, it could be related to yours/

@Tyriar Thanks for your guidance, you are right, that issue is closer to mine. The operating system of my remote host is ubuntu-18.04-x64, and this strange behavior of the terminal cannot be reproduced in the local machine (the Windows-x64 OS). I have subscribed to that issue, but I cannot provide more valid information than the OP provided at the moment.

authors: Tyriar finite-light karthikeyann


text:
Orca is too chatty when switching tabs due to aria-label being redundant to title

Step to Reproduce:

Switch between open documents with Alt+n (where n is the index of the tab)

Orca's presentation for a file named "hello world" is:
hello world. page tab /path/to/hello world

The reason why is that Orca by default presents (at least) the following information for a widget:

accessible name (e.g. the value of aria-label)
accessible role (e.g. the localized value of ARIA's role)
accessible description (e.g. the value of aria-description, aria-describedby, or the title)

From the inspector, I see:
<div ... role="tab" class="tab ... aria-label="hello world" title="/home/jd/hello world" ...>

I get that knowing the path is of value and makes sense as something which appears when the user hovers the mouse over the tab. By the same token, I don't think this amount of verbosity is great for the screen reader user.
And yes, I believe I said in some other issue that putting the path where it would be exposed as the accessible description made sense because users could interrupt speech, etc. But in this particular case, user interruption might not be ideal because what Orca says immediately after is relevant to the user, namely: That the editor has focus and the current line.
I'd be interested in hearing what users (@jvesouza, @webczat, et al.) and @isidorn think.

For me that is not really a problem. I probably have some issues with things being too chatty, for example when pressing numpad enter and I want to read current line of text I am on... but not when switching editors.

I think reading the path to a file when a tab gets focused is too verbose. There are other ways to figure out the path of the file and imho it should not be read out every time a user focuses on a file.
I just tried VoiceOver and it nicely ignores the title attribute and only reads the file name.
imho in general when aria-label is present screen readers should ignore title as the aria-label should containt the fully description. title should only be used when aria-label is not present as a substitute. Though you would know better, this just makes sense from my standpoint.

@isidorn Fair enough. But here's the thing:

accessible name != accessible description. See under https://w3c.github.io/aria/#terms. As you'll see there:

An accessible description provides additional information, related to an interface element, that complements the accessible name.

For most elements when there is an aria-label and a title attribute (and no other source of name/description info), the value of aria-label gets exposed to platforms as the accessible name; the title attribute gets exposed to platforms as the accessible description. Given the definition/explanation I quoted above, screen readers that include the accessible description by default are operating under the assumption that the accessible description is providing additional information rather than redundant information.

Screen readers using their accessibility APIs to get the accessible name and the accessible description don't necessarily know what authoring caused those accessible properties to be there. If the description was put there by, for instance, the new aria-description property, it would look the same to me as if it came from the title.

I suppose I can add a heuristic to Orca to handle this particular case (description looks like a file path and the filename seems to be in the accessible name)....

Ok thanks for clarifying. I oversimplified things.
So for me this more feels like a screen reader verbosity setting. If the screen reader is set to be very concise it should only read aria-description when explicitly asked for by the user.
If the screen reader is in a very verbose mode than it should always first read aria-label then aria-description.
And after reading the docs I take back what I said that the aria-label is a substitue for the title. That is incorrect, however aria-description is a substitue, thus if aria-description is set I think you should ignore the title.
That heuristic you propose is imho a bit too specific and sounds like a hack.
A heuristic which imho makes sense is to do some string matching is see how similar the name and description are. But even then this feels a bit magical. I still think this shuold be user configured via verbostiy setting and there shuold be an explicit action to get the description being read.

Orca already has a verbosity setting for description so it can be disabled. Orca also has a command to get detailed information for the current object. But the user is only very briefly on the page tab because focus immediately goes to the editor.
And I agree about sounds like a hack. Orca already has simple comparisons for name and description, but it's not yet catching this particular case.

Ok makes perfect sense.
Then I think the only way to fix this if you want is to fine tune that simple comparision which you already do.
💡 or even better, vscode sets the aria-description to be an empty string "". aria-descirption takes precendence over title and orca does not read anything 💡

To be honest, I'm not 100% sure that would work. Just to be sure, I asked in the associated PR.

@joanmarie ok thanks! Let me know what they say and if we should do the aria-descirption change on the vscode side.
For me it feels like the client should have some way to tell the screen reader that the title should be ignored.

Just tried out setting aria-description to an empty string and it does not work. Orca is still too chatty, but in theory if that is the right thing to do, we can do that change and you can fix it on the Orca side. So let's wait for the reply on the PR. Thanks!

So the comparison stuff I have locally (not yet committed) solves the original problem.
BUT it seems like now I'm sometimes (but not always) seeing a selection event for the tab after the editor claims focus. This is a new development and leads to different chattiness (which sounds very similar to the chattiness I reported here).
I tried to filter out this new chattiness, but because sometimes the events are missing the filtering resulted in Orca saying nothing. I'll get to the bottom of that in a bit (hopefully!) and then open a new issue if appropriate.

So Aaron just responded. We should get an empty description. I can confirm that's the case by loading this simple test in chromium built locally: data:text/html,<input aria-label="enter stuff here" title="tooltip!" aria-description=""> So I guess it's just a matter of VSCode / Electron using a more recent version of Chromium.

@joanmarie fantastic. I have just pushed a change that we set the aria-description on the tab area to empty.
Next milestone we should update to Chrome 80 so hopefully it should just work then.
We should have this aria-description in mind in case more situations appear where Orca is reading a title and it should not.

authors: isidorn joanmarie webczat


text:
Fixes #95883.

Added display: inline-table; to .monaco-icon-label::after
to force its integer width. This in turn forces action icons
to appear at integer positions and avoid blurring.

This PR fixes #95883.
Per this comment actually: https://stackoverflow.com/a/45234850/796121
Before:

After:

Hmm. I understand that you don't want to pull some random hacks, alas i'm not a CSS expert, i'm just a guy who tries to fix a bug because nobody else fixed it. I want to update vscode eventualy, but i can't be looking at blurry icons 12 hours a day. I'm also not sure if display: inline-table; would the best for this, but i can not be more specific on what would be.
What about this one?
.scm-view .monaco-list-row .resource > .name > .monaco-icon-label > .actions .action-label.codicon {
	line-height: 22px;
	transform: scale(1.000001); /* #95883, rescale slightly to remove blur when icon position is fractional */
}

This is 100% og hack without "stackoverflow programming" if that is of concern. It's isolated in SCM view and shouldn't introduce any visible differences or influence other elements, or so i think.
Before:

After:

Better or worse?
Anyway, please let me know if you don't want this PR, i'll discard it so it doesn't clog your stuff.

I see why this is dubious. On Windows those icons just always blurry and display: inline-table; or transform: scale(1.000001); do not look like improvements at all, icons just stay blurry.
Good luck with the icon font, looking forward to it.

source: gharchive/pull-request


text:
Remove legacy smoke test driver

This PR fixes #147381

Wow just saw this 👏

authors: bpasero joaomoreno


text:
Initial Strict Typing Support for Telemetry Events

This PR is quite large as it sets the foundation for the changes needed to enable stricter type checking when sending our telemetry events. There are plenty more locations in the code that I haven't touched as this PR was starting to get out from under me, but this gives plenty of examples of what stricter type checking would look like. This will replace GDPR comments with typings which will force the event sent to match the classification provided. This is part of the work for #75527

can we split this up just a bit more? One PR for adding publicLog2 and the gdprTypings. A second PR for after that's in with your initial sweep.
Also, why do all the implementations of publicLog2 copy the code of publicLog instead of just calling publicLog?

We could split it up, I just had then together because it also tests to make sure the publicLog2 works was intended. I felt it was weird to just have a function definition with no changes. The reason all the implementations of publicLog2 are just copies of publicLog is because once the change was done I was just going to delete publicLog and rename publicLog2. I could do that just by calling publicLog as well, but this was just less work

Modified Events:
issueReporterSearchError
issueReporterSubmit
issueReporterViewSimilarIssue
issueReporterGetElementError
windowerror
workbenchActionExecuted
galleryService:requestError
galleryService:cdnFallback
galleryService:requestError
UnhandledError
optInStatus
updateConfiguration
updateConfigurationValues
updateKeybindings
extensionActivationTimes
activatePlugin

@lramos15 @sbatten what is a WBAction.*? I find names that are acronyms rather hard to understand, can we try to avoid them and spell them out?

@bpasero I tried not to abbreviate many things, but took the liberty in certain cases due to the names for each type getting way longer than I would like. I can go back and fix them, but I didn't think it was a huge deal since just going to the references of the types would point you to the publicLog call which contains the eventName which the type is referring to. I see I did WB instead of WorkBench, RE instead of RequestError, and Val instead of Values. Let me know what you think.

@lramos15 I think I am reacting up a bit because I see no other case of abbreviation in our code base like that. I do not mind longer names because quick open is smart enough so that you can e.g. type only the capital letters of a class and it will auto complete just fine:

Doing it with abbreviations just asks for trouble because a different person does not know what you mean.

@lramos15 see https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions#using-abbreviations-and-acronyms
Please change it back to the long form, thanks :+1:

authors: bpasero lramos15 sbatten


text:
Increase the limit of adding country code in Marketing ticket

Currently Marketing team can add maximum fourteen countries in the marketing ticket, they are not able to add more than fourteen countries in the marketing ticket as per their requirement.
I want to be able to add more than fourteen countries in a marketing ticket, so that I can accommodate all necessary countries for our marketing campaigns so that it will save marketing teams manual effort and onsite team effort to cross check while performing the quality checks.

Thank you for your feedback. We have tested the functionality, and it works as expected. You can now add more than fourteen countries in a ticket. Please verify and let us know if you encounter any further issues


text:
The readme misses some config parameter for "cargo new"

https://github.com/microsoft/windows-drivers-rs/blob/e127a84a90e63d4f124177960d45785d78839ded/README.md?plain=1#L39
--config needs a KEY=VALUE

Hi @mhandb. This is a typo in the readme. --config is not needed.

Hey @wmmc88 - would you be open to a PR removing that option in the README?

Yup. Theres some Readme updates I need to make and will be opening a PR later today.

Theres some other Readme updates I need to make and I will be opening a PR later today to resolve this.

No worries - I'll leave the change up to you, then. I've looked at that PR and it looks good!

authors: mhandb shymega wmmc88

repo: microsoft/windows-drivers-rs


text:
Provide vtables from COM and WinRT as raw bindings

Motivation
I recently wanted some raw bindings for mmdevice and mme api so I used the windows-sys crate as a dependency. It all went smoothly in the beginning but soon I needed to construct and call the MMDeviceEnumerator COM Interface. From there on it was a huge pain. The windows-sys crate as stated in "Choosing between the windows and windows-sys crates" does not support COM in favor of compilation speed. At first I just copied the required vtables provided by the windows crate into my project but that was really unpleasant experience. I still wanted raw bindings but had no easy access to the vtables for COM Interfaces. So I chose to scrap the idea and just import both windows and windows-sys and use the windows crate whenever I need COM.
Why is there no crate with the full set of raw bindings for the windows apis?
I think this is a big issue for usability, especially for other rust libraries. I have seen some examples on the way (e.g cpal PR#778) which also just copy the vtables into their source code to interact with COM while using windows-sys. The windows crate provides a lot of convenient wrappers but I would still appreciate to have a complete raw binding crate like other C-style apis for rust provide. What are your thoughts?
Drawbacks
I am not sure if this would require a new crate. I would expected it from the windows-sys crate because the "sys" suffix seems to be used for raw binding libraries but as stated COM and WinRT were explicitly removed to improve compilation speed.
Rationale and alternatives
No response
Additional context
This also relates to #2187

Rust doesn't directly support virtual functions the way that C++ does (and required by COM) so simply providing the "raw" bindings does not in practice help very much to call COM or WinRT APIs since a lot of code is still required to deal with calling conventions, membership, vtable indirection, queries, and ownership. As such, adding all of that to the windows-sys crate would negate the benefits of the crate.
Your best bet it is to use the windows crate as I described here:
https://kennykerr.ca/rust-getting-started/windows-or-windows-sys.html
If the compilation cost is too high due to the overall size of the windows crate, standalone code generation is provided and lets you generate just the bindings you need:
https://kennykerr.ca/rust-getting-started/standalone-code-generation.html
This is what @Jake-Shadle, the author of the PR you cite, indicated he would use for such scenarios (#1720) so it's unclear why he's taken the approach of adding all that hand-rolled/copied code into the PR. That seems entirely unmaintainable.

For me its not so much about the compilation time, but more about the idea that bindings should provide a minimal interop to C/C++ even for virtual functions. In this case it would translate to a crate for rust wrapped types (windows) and a crate with only the minimum but still complete set of unsafe interop with vtables, structs and no altered function parameters. An example are these C# interop packages (P/Invoke) that basically act like a bare metal bridge between C# and C/C++.

I appreciate that the "idea" of raw COM bindings might be appealing in Rust, but they're not very practical due to the amount of extra scaffolding required to actually make them work in practice. I continue to optimize and streamline the windows crate and its code gen to eliminate or minimize the real or perceived overhead, but providing another alternative doesn't seem beneficial at this point.

Anyway, closing for now but feel free to keep the conversation going!

Could there be a middle ground with another crate for COM support ? Something like https://lib.rs/crates/com or https://lib.rs/crates/com-rs.
It would not weigh in on windows-sys and would be far lighter than using windows.

The windows-implement and windows-interface crates are essentially equivalent to the old com crate. They are dependencies of the windows crate but could in theory be standalone:
https://crates.io/crates/windows/dependencies
But that's different to providing the pre-generated bindings for existing COM and WinRT interfaces in the Windows SDK.

repo: microsoft/windows-rs


text:
Add aarch64-pc-windows-gnullvm and x86_64-pc-windows-gnullvm targets

Creating new target as told to do so in https://github.com/microsoft/windows-rs/pull/1846#pullrequestreview-1026401722
Fixes #1881

I don't know what is wrong but git keeps interpreting crates/targets/aarch64_gnullvm/lib/libwindows.a as a text file.

I don't know what is wrong but git keeps interpreting crates/targets/aarch64_gnullvm/lib/libwindows.a as a text file.

That's odd, the .gitattributes includes *.a so it shouldn't.
https://github.com/microsoft/windows-rs/blob/4ba369acb36218429e3ea38c8a1660c47677a323/.gitattributes#L7

It is suspiciously small.

It is suspiciously small.

Yeah, noticed it as well before opening the PR but I had compared outputs of llvm-nm crates/targets/aarch64_gnullvm/lib/libwindows.a and llvm-nm crates/targets/aarch64_msvc/lib/windows.lib and they were mostly the same.
At least when it comes to symbols count they are the same:
$ llvm-readobj --coff-exports crates/targets/aarch64_gnullvm/lib/libwindows.a | grep Symbol | wc -l
34210

$ llvm-readobj --coff-exports crates/targets/aarch64_msvc/lib/windows.lib | grep Symbol | wc -l
34210

Any general pointers/tips on building your toolchain locally for testing? I'm going through the steps of compiling rustc now, which I assume is the starting point.

You could try first if unstable -Z build-std feature will suffice your needs, it's the easiest way to play with this target right now.
For an example you can even run tool_gnullvm using x86_64-pc-windows-gnullvm target with these steps:

Open MSYS2 CLANG64 environment
Run pacman --needed -S mingw-w64-clang-x86_64-toolchain
Run PATH=$(cygpath -u $USERPROFILE)/.cargo/bin:$PATH cargo r --target x86_64-pc-windows-gnullvm -Z build-std -p tool_gnullvm -- all
It requires nightly Rust though.

If you want full toolchain I'll provide you the exact steps on how to build it today/tomorrow evening CEST.

Ah cool, I didn't realize this made it into nightly. 👍 No full toolchain steps needed for our purposes at this time, although it might be handy to add to the docs at some point.
Compiling tool_gnullvm (targeting *-gnullvm) results in libunwind failures. I see clang was invoked with --unwindlib=none so not sure what's going on there yet.

Full output:
$ PATH=$(cygpath -u $USERPROFILE)/.cargo/bin:$PATH cargo +nightly r --target x86_64-pc-windows-gnullvm -Z build-std -p tool_gnullvm -- all
   Compiling tool_gnullvm v0.0.0 (C:\Sources\windows-rs\crates\tools\gnullvm)
error: linking with `C:\msys64\mingw64\bin\clang.exe` failed: exit code: 1
  |
  = note: "C:\\msys64\\mingw64\\bin\\clang.exe" "-nolibc" "--unwindlib=none" "-m64" "C:\\Users\\Rafael\\AppData\\Local\\Temp\\rustcC65uNT\\symbols.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.12ezno69lpmyuu43.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.182fhvj1u3z7iewp.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.18libnrriw98oxa5.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.19coswx6llvdnn7o.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.19u62jculx1rys4c.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.19zyo4y10v97pxyc.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.1c7w2c0kmw4vax41.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.1fhaabranfwg26qr.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.1kb989b60cwsp40k.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.1lmdnorj2y13sjqj.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.1lufaybp8bgbxryf.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.1rscad6yb11zdupb.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.1v0oocqexrv9smmf.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.1zmgck2so313w7wv.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.23fsy0jzoccnj3gw.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.25so6al963q2emyd.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.26bn02cwg0enjfjp.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.2awck9hsuryladm7.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.2carsqilgwqywkd8.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.2e7djchnlh0ww7o7.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.2hhaykeo7gz5yd5y.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.2s7xba4l2cafbheb.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.2utj8qikjdawum8r.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.2wotsgfes5l9gc8u.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.2xb3pn7who3lfhvs.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.31tcqypfx8sy7tho.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.34jalpnpzia2w46x.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3c62t39ncatq5vlz.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3chyhombgrxzrnat.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3dsup3ekjghugufa.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3iju24uwbpdjkow4.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3jgisacdr7dgejlt.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3kdd597cu0ixmadb.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3lumt0z74ue70uuy.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3nnqtye7nfbh53f7.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3obygl2afdjpl1s6.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3s6g8dpesmhs2c6g.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3sbotzh55gfflxdt.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3sjwyk8dpeo5642h.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.3zf7avs5a1a4m75u.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.44yyo97bgsjpxa5x.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.46b1ysswldryyxb.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.4e3f01fox28igrwd.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.4e9imsxiyinfp08x.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.4fdvsv6s7yjfgy6g.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.4itxrucu3etl472e.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.4j7jlutq26n8b89l.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.4jryu1iwa0j2t8r9.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.4mvkjw2fjzfehgr8.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.4n8a5elnbwh0ktbb.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.4xkn8ckyjulx8bds.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.523rtzupxsdg8d54.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.56hrao22h6eux2f7.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.5b6w1bx5ttxo18kz.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.5ecxczoc7p2fv2qq.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.9oe63endkav5e41.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.ay7j6ko52ije6fb.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.iy05wnmkx473440.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.wkvi2cqd3pce0sv.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.z34xp5dqywgslxi.rcgu.o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.ge5v7etyc1jxeve.rcgu.o" "-L" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps" "-L" "C:\\Sources\\windows-rs\\target\\debug\\deps" "-L" "C:\\Users\\Rafael\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-gnullvm\\lib" "-Wl,-Bstatic" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libwindows_metadata-c91907ac2b553472.rlib" "-Wl,--start-group" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libstd-e9f2efaad10a3b98.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libpanic_unwind-5a5bf608ddb8ed39.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libobject-e23b7a7cfbdf5916.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libmemchr-96c6a8deb0ac1412.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libaddr2line-1667495d10f7223f.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libgimli-e31847701079c437.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\librustc_demangle-00c752d0d065974d.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libstd_detect-ad54cec87987c4a2.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libhashbrown-56e9dd1d6fe90939.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libminiz_oxide-2633874641d74771.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libadler-0e1435af86fb862f.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\librustc_std_workspace_alloc-dcaf45f9a093f678.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libunwind-c43da1cf3a899fc0.rlib" "-lunwind" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libcfg_if-e4d4a9cbb956fd9a.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\liblibc-69d6255466bb7ddf.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\liballoc-c5571d2b88345384.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\librustc_std_workspace_core-ad0baf2b5b0e44ce.rlib" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libcore-6a89cba04688d323.rlib" "-Wl,--end-group" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\libcompiler_builtins-94ce661bcd27ab31.rlib" "-Wl,-Bdynamic" "-ladvapi32" "-luserenv" "-lkernel32" "-lws2_32" "-lbcrypt" "-lmingw32" "-lmingwex" "-lmsvcrt" "-lkernel32" "-luser32" "-Wl,--nxcompat" "-L" "C:\\Users\\Rafael\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-gnullvm\\lib" "-o" "C:\\Sources\\windows-rs\\target\\x86_64-pc-windows-gnullvm\\debug\\deps\\tool_gnullvm-e1caceb089630d49.exe" "-Wl,--gc-sections" "-no-pie"
  = note: clang: warning: argument unused during compilation: '-nolibc' [-Wunused-command-line-argument]
          clang: warning: argument unused during compilation: '--unwindlib=none' [-Wunused-command-line-argument]
          clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]
          C:/msys64/mingw64/bin/ld: cannot find -lunwind: No such file or directory
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Is there no 32-bit target for gnullvm?

Is there no 32-bit target for gnullvm?

ARM and i686 might be added in the future, right now I skipped them because Rust breaks their exception handling (the "glue" code is very specific to libgcc and doesn't work with LLVM's libunwind). 64-bit targets use SEH and are free of this issue.

C:/msys64/mingw64/bin/ld

@riverar could you try using CLANG64 subsystem instead of MINGW64?

@mati865 Yep, that works great. I'll add a review comment to the README then.

Ran tool_yml and updated readme with instructions on using gnullvm target on nightly.
I can squash commits manually and force-push once you are satisfied with this PR.

I can squash commits manually and force-push once you are satisfied with this PR.

Not to worry, we always "squash and merge" when completing.

Looking pretty good!
@mati865 Can you update our rudimentary cross-compile CI tests here to test this new target? https://github.com/microsoft/windows-rs/blob/master/.github/workflows/cross-compile.yml
One possible matrix strategy could look like:
matrix:
  image: [macos-latest, ubuntu-latest]
  version: [stable, nightly]
  target: [x86_64-pc-windows-gnu, xxxxxx_gnullvm]
  exclude:
  - target: xxxxxx_gnullvm
    version: stable

If you don't feel comfortable with that, need help, etc. just let us know.

@riverar linking the executable will fail without manually installing mingw-w64+LLVM toolchain like this one: https://github.com/mstorsjo/llvm-mingw
Should I do it?

🎉 Passing the smoke tests, sweet!
I don't think this is specific to your gnullvm target but I'm wondering if the LLVM/mingw-w64 toolchain can be tweaked to leverage Hybrid CRT semantics to eliminate the dynamic CRT external dependency. I don't think this is a blocker for adoption but that's not my call.
Also, can you help me understand the differences between mstorsjo/llvm-mingw and me installing mingw-w64-clang-...-toolchain on Windows? Apologies in advance if that's obvious.

I don't think this is specific to your gnullvm target but I'm wondering if the LLVM/mingw-w64 toolchain can be tweaked to leverage Hybrid CRT semantics to eliminate the dynamic CRT external dependency.

I don't think so, mingw-w64 doesn't support linking static CRT at all because it doesn't have access to Microsoft's source codes nor static libraries. So I'd expect this Hybrid thing to have the same problem.

Also, can you help me understand the differences between mstorsjo/llvm-mingw and me installing mingw-w64-clang-...-toolchain on Windows? Apologies in advance if that's obvious.

MSYS2 (the tool that provides mingw-w64-clang-...-toolchain) works only on Windows and provides package manager with toolchain, tools and libraries so it's similar to developing on Linux.
llvm-mingw is just a compressed toolchain so mingw-w64 + LLVM.
MSYS2's CLANG* subsystems are almost the same as llvm-mingw so both are fully compatible.
MINGW* and UCRT* subsystems however carry few patches making Clang/LLVM more compatible with GCC but incompatible with unpatched Clang/LLVM (like one in CLANG* subsystems or llvm-mingw).
This is especially visible when using TLS or exceptions inside executable.
So TL;DR llvm-mingw supports all major systems as the host but provides toolchain only, MSYS2 supports only Windows as the host but provides more complete Linux-like environment. You can use either of them and cargo b --target x86_64-pc-windows-gnullvm -Z build-std will work.

Looks good to me, just a nit on the caching that should be easy to resolve. Thanks for your patience while I was out!

Thanks, I'm out until Sunday/Morning. I'll address feedback then.

Sorry, was busier than anticipated.
Rebased branch (because of CI errors) and added cache:

Opened https://github.com/microsoft/windows-rs/pull/1949 to address build failures here.

@riverar should be ready.

@mati865 🥳🎉

authors: kennykerr mati865 riverar