VSCode should honor toolchain overrides that contain a rust-analyzer component for server spawning

[Veykril]

We tend to drop support for stable releases somewhat frequently as its difficult to really support more than a handful of rust versions with a rolling release model. This means it becomes the job of the user to pin their rust-analyzer somehow to some version that fits their current roolchain install, that's not ideal. We should offer a setting that when enabled checks for a toolchain override in the workspace and attempts to use its rust-analyzer component if installed when spawning the server.

Addtionally we should probably attempt to let the server know its MSRV and inform the user if their toolchain looks too old.

[huntc]

Thanks for raising this.

Addtionally we should probably attempt to let the server know its MSRV and inform the user if their toolchain looks too old

Just on the subject of "old toolchains", it is of course quite common for projects to pin their toolchains, particularly once deployed to production. My point is that past toolchain usage is a fact of life and so pointing out to the developer that their toolchain is old is probably not useful. :-)

[Veykril]

Too old for the current rust-analyzer server that is running, it is useful to point that out, because otherwise we just get issue reports for issues caused by us not supporting something wrt to that old toolchain. If we have a way to let people pin their version to an older compatible toolchain then we can just point them to that and everything is fine.

[huntc]

I don't see that this issue is resolved. I've updated by VSC environment to use the nightly RA. Here's its version info:

rust-analyzer version: 0.4.2048-standalone (eeb192b79 2024-07-24) [/Users/huntc/.vscode/extensions/rust-lang.rust-analyzer-0.4.2048-darwin-arm64/server/rust-analyzer]

So the PR commit is part of this. Yet, if I now add RA to my toolchain files e.g.:

[toolchain]
channel = "nightly-2022-11-22"
components = [ "rustfmt", "clippy", "rust-analyzer" ]
targets = [ "thumbv7em-none-eabihf" ]

...then I'm still seeing errors in the RA output:

2024-07-25T01:38:27.294031Z ERROR Flycheck failed to run the following command: CommandHandle { program: "/Users/huntc/.cargo/bin/cargo", arguments: ["check", "--workspace", "--message-format=json-diagnostic-rendered-ansi", "--manifest-path", "/Users/huntc/Projects/titanclass/matte-ev-charger/firmware/nrf-monitor/Cargo.toml", "--keep-going", "--all-targets"], current_dir: Some("/Users/huntc/Projects/titanclass/matte-ev-charger/firmware/nrf-monitor") }, error=Cargo watcher failed, the command produced no valid metadata (exit code: ExitStatus(unix_wait_status(25856))):
error: the `--keep-going` flag is unstable, pass `-Z unstable-options` to enable it
See https://github.com/rust-lang/cargo/issues/10496 for more information about the `--keep-going` flag.

As a consequence, I continue to get:

proc macro `task` not expanded: No proc-macros present for crate

I've also tried cleaning project folders and restarting RA.

Additional info: My project has a VSC workspace file and each project within is relatively independent of the other. Some of the projects have a toolchain file, some do not. There's a blend of embedded and non-embedded Rust projects here.

[huntc]

Is it that the VSC integration design only facilitates one RA per workspace? If I open a specific project i.e. avoid opening up my workspace, then I think the changes in the associated PR are working.

This is the code that leads me to think that there's a restriction on the RA in that it is just one per workspace: https://github.com/rust-lang/rust-analyzer/pull/17667/files#diff-4023aad9450babbfcc30b89d5bf1fe604d569d67ff8c3232b783e8666c41eb0dR55

Perhaps an improvement on that would be to iterate through the workspaces and use the oldest RA found. WDYT? The way it stands now is that opening up my workspace is no longer viable.

[Veykril]

Additional info: My project has a VSC workspace file and each project within is relatively independent of the other. Some of the projects have a toolchain file, some do not. There's a blend of embedded and non-embedded Rust projects here.

This is the reason. The toolchain pickup only works when there is a single folder opened within a VSCode workspace. The reason for that is that extensions are loaded per VSCode workspace and the toolchain override happens per cargo workspace/folder within a VSCode workspace.

Perhaps an improvement on that would be to iterate through the workspaces and use the oldest RA found. WDYT? The way it stands now is that opening up my workspace is no longer viable.

Ye I suppose this would work?

[Veykril]

Would also be good to attach a "reason" to why we chose the current running server version when telling the user about the running server then.

[huntc]

Ye I suppose this would work?

Well, it’s better than the current situation. ;-)

Do you want me to have a go?

Would also be good to attach a "reason" to why we chose the current running server version when telling the user about the running server then.

Sure. Where would that be displayed? In the RA output?