Allow exclusion of sourcekit-lsp workspaces.
Is your feature request related to a problem? Please describe. A VSCode workspace may contain multiple sourcekit-lsp workspaces. To be specific, by "VSCode workspace" I mean the folder you are opening in a VSCode window and by "sourcekit-lsp workspace" I mean the workspaces managed by sourcekit-lsp (which effectively tells the LSP server where to search for Package.swift or compile_commands.json). As I understand it, this VSCode extension automatically tries to find a workspace when a Swift file is opened in the VSCode UI, and there is no way to influence this behavior. The one customization option provided is "search subfolders for packages", which tries to identify workspaces when the extension starts up. This is fine for most projects, but there are times when this is problematic. One example is a project with a top-level Package.swift file (the "user-facing package") may have a number of other packages in its directory tree (packages testing the user-facing package, local packages that can be referenced by the user-facing package, or just one-off examples). I've noticed a number of weird issues in such a project, including some failures with package resolution (which can be disabled via an option) and LSP functionality being unavailable for the nested packages.
Describe the solution you'd like For my example above, just deleting the top-level Package.swift fixed all my issues (i.e. LSP began working well in the nested packages). It would be great if there was a setting like the following:
"swift.sourckit-lsp.workspaces.exclude": [
".": true,
"my/other/problematic/package": true,
"test-workspaces/*",
]
Note that in this case a workspace located at "the/workspace/I/care/about" would still be enabled even though it is nested under ".", which is excluded. Support for "*" would be nice for folders of test projects.
Possibly related to this feature request: opening a workspace that contains non-swift compile_commands.json breaks in the presence of this extension. I don't have a small example, but if you download Fuchsia and run fx set you'll have generated a compile_commands.json; if you open that workspace in the presence of this extension you'll see that just about all C++ tooling is broken.
I can take a look a this.
Not currently looking into this, but when someone does look into this: Another use case mentioned in #1545 is that folks may want to use their compile_commands.json file instead of Package.swift. Currently it's possible to use sourceKit settings to do this, but would be nice if we are smarter/provide more options for compile_commands.json files, non-swift compile_commands.json files and Package.swift files.
With this PR https://github.com/swiftlang/vscode-swift/pull/1693 we can exclude folders from being initialized by the extension. This would likely be enough 90% of the time. There would still be an outstanding piece against sourckit-lsp to ignore excluded files opened in an editor https://github.com/swiftlang/sourcekit-lsp/issues/2196
For verification, you'll need to enable the swift.searchSubfoldersForPackages setting, and add certain folder patterns to swift.excludePathsFromActivation setting. This will prevent folder initialization on startup. Check the SourceKit-LSP channel to verify the package manifest was ignored.
When you open a file in one of these excluded folders, this will ignore activating the folder. So the project panel should never focus on that folder. Now the LSP will get notified of file open so you should eventually get language support. There is no way to get VSCode to ignore sending requests about these files: https://github.com/swiftlang/sourcekit-lsp/issues/2196
Confirmed behaviour @award999 mentioned in previous comment with 9f874ecd using a modified version of the assets/tests folder (with just the defaultPackage and Swift-Markdown folders), and the following settings:
"swift.searchSubfoldersForPackages": true,
"swift.excludePathsFromActivation": {
"**/defaultFolder": true,
"**/Swift-Markdown": true,
},
Note the ** is required for glob wildcard matching if the full path to the directory is not specified.