Closed MabezDev closed 6 months ago
It looks like much of the toolchain discovery happens here: https://github.com/rust-lang/rust-analyzer/blob/4a8d0f7f565b6df45da5522dd7366a4df3460cd7/crates/toolchain/src/lib.rs#L62-L90.
I created a small demo depending on the unreleased toolchain
crate:
fn main() {
println!("Path to rustc => {}", toolchain::rustc().display());
println!("Path to cargo => {}", toolchain::cargo().display());
}
Which outputs:
Path to rustc => rustc
Path to cargo => /home/mabez/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo
Is this output expected? Wouldn't it better to output the absolute path here if we find it in the path? When it comes to executing rustc
, do you know if r-a will take into account $PATH
ordering? My $PATH has $HOME/.cargo/bin
before /usr/bin
.
I added some logging to the toolchain crate, and it looks like it is finding the correct rustc
at /home/mabez/.cargo/bin/rustc
in my path.
The interesting part to look at should be here https://github.com/rust-lang/rust-analyzer/blob/4a8d0f7f565b6df45da5522dd7366a4df3460cd7/crates/project-model/src/workspace.rs#L231-L235
Basically what r-a does is it asks rustc
where the sysroot is https://github.com/rust-lang/rust-analyzer/blob/4a8d0f7f565b6df45da5522dd7366a4df3460cd7/crates/project-model/src/sysroot.rs#L397-L407
from that point on, when we run any rust tool we set the RUST_TOOLCHAIN
env var to the given sysroot and rely on the cargo home proxies to do the resolution through said env var. Obviously that fails should get_path_for_executable
not resolve to a cargo proxy, but to your system rust install for some reason. This part of r-a is written with a rustup install in mind, so your setup here wasn't really considered (not to say that we wouldn't wanna support it)
Is this output expected?
Maybe? It entirely depends on your environment, given the function you've linked
Thanks for the pointers. I've built r-a locally and added some prints:
2024-02-24T20:43:00.499821Z WARN project_model::sysroot: Discovering sysroot by cd "/home/mabez/development/rust/embedded/util/embedded-fatfs" && "rustc" "--print" "sysroot" with envs: {}
2024-02-24T20:43:00.508967Z WARN project_model::sysroot: Found sysroot: /opt/rust-bin-1.74.1
and we can see it's found the wrong sysroot. However I can't for the life of me figure out why. In the test project from above, If I use Command
to replicate the exact call r-a makes I still find the correct sysroot!
Any ideas?
I know it is not recommended to have both rustup and system Rust installed. I would remove it if I could, but Gentoo requires it for building firefox etc. I still think r-a should be smart enough to use rustup's rustc (and tbh I'm really struggling to know how its finding it.).
Logs from r-a with log level set to "warn".
I'm using zsh, but all of my shells report the rustup rustc when running
which rustc
, e.g :Any ideas?
rust-analyzer version: (eg. output of "rust-analyzer: Show RA Version" command, accessible in VSCode via Ctrl/⌘+Shift+P)
rust-analyzer version: 0.3.1850-standalone
rustc version: (eg. output of
rustc -V
)From rustup:
rustc 1.76.0 (07dca489a 2024-02-04)
From system:rustc 1.74.1 (a28077b28 2023-12-04)
relevant settings: (eg. client settings, or environment variables like
CARGO
,RUSTC
,RUSTUP_HOME
orCARGO_HOME
)No other environment variables are set/modified from the default installation.