RA ignores vscode settings in multiroot workspace

[devjgm]

rust-analyzer version: rust-analyzer version: 0.3.2062-standalone (c9109f2 2024-08-04)

rustc version: rustc 1.80.0 (051478957 2024-07-21)

editor or extension: VSCode on macOS

Version: 1.92.0
Commit: b1c0a14de1414fcdaa400695b4db1c0799bc3124
Date: 2024-07-31T23:26:45.634Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: 12.4.254.20-electron.0
OS: Darwin arm64 23.6.0

relevant settings: Nothing special. All defaults.

repository link (if public, optional): Here's a small repro repository: https://github.com/devjgm/multiroot

code snippet to reproduce:

The problem is that I have a repo with two areas (directories) where rust-analyzer needs to be configured differently. For example, each directory needs to use a different "rust-analyzer.check.overrideCommand". Since these rust-analyzer settings are specified in the .vscode/settings.json file in the root of each workspace (vscode workspace, not cargo workspace), I'm trying to use vscode's "multiroot workspaces" to make this work.

I define the vscode multiroot workspace like this:

{
    "folders": [
        {
            "path": "."
        },
        {
            "path": "sub"
        }
    ],
}

but when I do this vscode says:

This setting cannot be applied in this workspace. It will be applied when you open the containing workspace folder directly.

for all of rust-analyzer's settings in my .vscode/settings.json files. See the screenshot below. The observed behavior also seems to suggest that rust-analyzer's settings are not being applied.

Questions

• Is this a bug that should work today?
• Am I simply configuring something wrong?
• Is this a new feature that you're considering adding?

Related

This seems related to #1104, but the final command and resolution on that issue suggests something about linkedProjects, which doesn't really help. Again, the goal is to use different rust-analyzer settings in each of vscode's "multiroot" workspaces.

[lnicola]

This setting cannot be applied in this workspace. It will be applied when you open the containing workspace folder directly.

That's a VS Code warning, and not something that we display. We probably don't even see the settings.

rust-analyzer.toml might solve this in the future, but I don't know if think it's ready yet.

[Veykril]

Note that we run a single rust-analyzer instance per VSCode window, so configs set by the client will always apply globally so this technically works as expected.

[devjgm]

Note that we run a single rust-analyzer instance per VSCode window, so configs set by the client will always apply globally so this technically works as expected.

OK. So it sounds like currently rust-analyzer doesn't support vscode multiroot workspaces then? If that's the case, could we turn this issue into a feature request to add support for multiroot workspaces in vscode?

[lnicola]

It does support Code workspaces, it doesn't support project-specific settings, especially not those that Code doesn't even read.

[devjgm]

It looks like rust-analyzer doesn't see "rust-analyzer.check.overrideCommand" from any of the .vscode/settings.json files when in a multiroot vscode. So I'm not sure how to configure rust-analyzer when in a multiroot vscode.

[Veykril]

I would expect the client config of the workspace folder itself to work (that is where you have the workspace defined)

[devjgm]

Thanks. You are correct. I can add settings to the multiroot.code-workspace file, and RA does pick that up. For example, RA sees the following settings:

multiroot.code-workspace

{
    "folders": [
        {
            "path": "."
        },
        {
            "path": "sub"
        }
    ],
    "settings": {
        "rust-analyzer.check.overrideCommand": [
            "blah I am in the code-workspace file"
        ]
    }
}

The downside, of course, is this uses the same rust-analyzer settings for both workspace roots, which defeats the purpose of using a multiroot workspace in the first place.

---

My goal is:

• Have separate RA settings for different directories (defined in /.vscode/settings.json and sub/.vscode/settings.json in my example repo)
• I think this is what vscode's multiroot workspaces were designed to support

However, I cannot get RA to use different settings in this configuration.

Maybe this is just a new feature request I'm asking for. Can RA be made to support vscode multiroot workspaces so that RA in separate vscode workspace roots sees different settings?

[Veykril]

It is unlikely we'll be able to support this. It would require us to spawn a rust-analyzer per vscode workspace folder which is more resource heavy (as we can't share state between the multiple processes) and I am also not even sure whether VSCode allows us to do this nicely (I feel like I looked into this before where trying to spawn multiple clients caused a bunch of issues). Generally speaking I'd prefer for us to not do that.

[lnicola]

Could we support different configs for the Code workspace members within a single server instead?

[Veykril]

Maybe? That would probably require an lsp extension and a bunch of extra stuff on the vscode extension side though

[lnicola]

For reading the settings? We could read them only from rust-analyzer.toml. But it does seem like a bit of a pain.

[Veykril]

Well for feeding settings.json from a workspace folder to the server I meant. The client config is pushed to the server via specific LSP notifications iirc, though I'd also rather point people to use rust-analyzer toml then.

[devjgm]

It would require us to spawn a rust-analyzer per vscode workspace folder which is more resource heavy

Today the only workaround I've found is to open two separate vscode windows, one in the main root "." and another vscode window for "sub" (see the example in the OP). I believe this would result in two separate rust-analyzers running as well.

I'd be happy to try using rust-analyzer.toml instead if that would help. Is that ready for public use? And will it allow me to have different rust-analyer.toml files for different folders in the same repo? I.e., will rust-analyzer.toml address the issue described above?

[davidbarsky]

Is that ready for public use?

Maybe, maybe not. What is your definition of "ready" here, I guess?

And will it allow me to have different rust-analyer.toml files for different folders in the same repo? I.e., will rust-analyzer.toml address the issue described above?

I don't recall if it does right now, but the design intention of rust-analyzer.toml is to support this use-case, yes.