Regression: cannot find proc-macro-srv only on Windows

[widlarizer]

rust-analyzer version: Anything since 0.3.1498. 0.3.1489 and earlier are unaffected

rustc version: reproduced with 1.67 and 1.75 on Windows. Could not reproduce with either on Linux

relevant settings: none

When cursor is moved over the sad rust-analyzer thing at the bottom in VS Code, you will see cannot find proc-macro-srv, the workspace C:\whatever is missing a sysroot. Repro should be as simple as

rustup default stable
cargo init

and open VS Code in this directory.

It's possible that installing rust-src fixes this. Our nostd-only Rust toolchain isn't shipped with sources so this isn't an option. Though we're interested in this bug because of our nostd-only toolchain, all behavior described above this paragraph applies to Windows stable as well.

I somewhat suspect that the VS Code and Windows changes by @Veykril may be the culprit based on looking at the output of git log --stat 2023-04-24..2023-05-01 --first-parent

[Veykril]

Does this happen with the latest rust-analyzer version? Also please check your logs for any additional info, it looks like your setup causes r-a to not find your sysroot at all, do you have any relevant configs set?

[widlarizer]

Does this happen with the latest rust-analyzer version?

Yep, latest as offered by VS Code, this is how we discovered it today

logs

Since I don't have a Windows setup personally, I can get logs and check settings on Monday

[widlarizer]

I have checked the settings and it looks like it might not be a bug, at least not in the original description.

We incorrectly believed that to use rust-analyzer at all with a no-std, no-rust-src toolchain, Windows users have to set"rust-analyzer.cargo.sysroot": null,, sorry about that, I didn't know we did that. This is because it suppresses a warning that reports rust-src is missing. Since 1498, sysroot must be present to find the proc macro server. Whether this should lead to all linting silently stopping to work is not something I know the answer to. By silently I mean, some warnings imply the lint stops working, some don't, and as a user, I don't know how to differentiate.

Another thing we just discovered is that to suppress "can't find crate for test" we set "rust-analyzer.check.allTargets": false,, which also breaks linting. By breaking linting here I am using as a test case a let a; with a unused, restarting the server, and expecting the red underlining with mouseover info to be present. Simpler errors like "missing semicolon" seem to work either way.

The warnings about rust-src and test crates missing should be possible to suppress since getting rust-src etc isn't necessary and may not be possible, should I create a separate issue for that? Should I close this issue?

If you want to reproduce this it should be enough to have a toolchain without rust-src and the test crate. I'm no Rust pro so I don't even know what a "test crate" is and searching the internet isn't helping

[Veykril]

Ah, regarding the proc-macro server you can either set the path for it directly via rust-analyzer.procMacro.server with the sysroot set to null, or you keep the default for the sysroot but set rust-analyzer.cargo.sysrootSrc to null (I think that should work).

By breaking linting here I am using as a test case a let a; with a unused, restarting the server, and expecting the red underlining with mouseover info to be present.

In what cases specifically? This should stop giving you cargo diagnostics in unit/integration tests, benches and examples, but otherwise should still yield diagnostics. Disabling allTargets for platforms where no test crate exist is the current recommendation so you are on the right track for that there.

[widlarizer]

Oh, I see. We were testing in example code. We would still like to suppress warnings about "test crate" and still have examples work. When I have a chance I'll try this workaround instead