In `rust-lang/rust`, `R-A` can't resolve symbols from the stdlib when inside `libtest` (without changing the config to break the same thing in the compiler)

[thomcc]

When developing in rust-lang/rust and using the recommended configuration https://github.com/rust-lang/rust/blob/398fa2187c88de46c13c142f600064483a563c86/src/etc/rust_analyzer_settings.json, libtest (e.g. library/test cannot resolve symbols which come from libstd/libcore/liballoc (here's a totally superfluous screenshot -- that's the color used for symbol which don't resolve in my theme).

Additionally, it seems that crates libtest depends on via Cargo.toml (like getopts), also fail to be resolved. Notably, R-A is able to resolve symbols which come from inside libtest itself (just basically nothing else).

I discovered¹ that it can be fixed by changing "rust-analyzer.cargo.sysrootSrc": "./library" to "rust-analyzer.cargo.sysroot": "./library", however this causes the crates under compiler/* to fail to resolve their stdlib symbols in a similar² manner to libtest without that change.

At the moment, I switch between these configurations depending on what I'm editing (almost always using the default config, unless I need to edit libtest), which is annoying, but not that big of a deal for me. Still, the "fix" for libtest is extremely non-obvious, so it'd be worth fixing (and failing that, documenting this issue).

CC @jyn514 who indicated they have the same issue (but had not noticed).

I'm on nightly rust, latest rust-lang/rust master, nightly rust-analyzer, vscode insider edition, and generally the full suite of bleeding edge nonsense (I can provide precise versions if it would help, but all signs point to this being a current issue).

Footnotes

1. I think this used to be the way we used to configure it? Something like that anyway. Far enough back, I think this configuration worked for both? But maybe not -- I don't do a lot of compiler/* dev. ↩

2. Although unlike libtest, compiler crates in this configuration can resolve symbols which come from dependencies from Cargo.toml -- for example, rustc_log resolves symbols from tracing just fine. I do not know if this is a useful datapoint (it certainly does not make editing this code much easier), but who knows. ↩

[jyn514]

cc @Veykril

[Veykril]

You cannot fathom how much I hate the rustc workspace.

So the cause of this is #14935 which fixes some other issues related to the sysroot having been duplicated (for certain reasons). Now that we no longer do this we get a ton of cycles. How does rustc know when to inject the sysroot and when not to on its own workspace? That is basically the problem here, since the library crates depend on a bunch of other crates that have the sysroot injected by r-a again when it shouldn't I suppose.

At this point it's clear that using cargo metadata for this is not working out, we should just add a bootstrap command that generates a relevant rust-project.json file. Bootstrap should know the relevant crate graph and all the nasty hacks to make things work, no point in trying to shove that into r-a.

[jyn514]

At this point it's clear that using cargo metadata for this is not working out, we should just add a bootstrap command that generates a relevant rust-project.json file. Bootstrap should know the relevant crate graph and all the nasty hacks to make things work, no point in trying to shove that into r-a.

that makes sense - is there documentation for rust-project.json somewhere?

[jyn514]

https://rust-analyzer.github.io/manual.html#non-cargo-based-projects looks right, let me see if I can find an example in the rust-analyzer repo

[Veykril]

Closing this, we aren't putting any more effort into making the rustc workspace behave like a cargo one for rust-analyzer's analysis. There is a PR open that emits a rust-project.json file which should fix that once its finished