/home is incorrectly detected as the rust toolchain to use

[bjorn3]

rust-analyzer version: rust-analyzer version: 0.4.1938-standalone (f216be4 2024-04-27)

rustc version: rustc 1.79.0-nightly (aed2187d5 2024-04-27)

editor or extension: VSCode

relevant settings: Unknown

repository link (if public, optional): https://github.com/rust-lang/rustc_codegen_cranelift/

reproducer: Happens when working on cg_clif, no clue why it thinks /home should be used as toolchain.

2024-04-28T18:14:13.374483Z ERROR project_model::workspace: Failed to query rust toolchain version at /home/gh-bjorn3/cg_clif, is your toolchain setup correctly?
2024-04-28T18:14:13.378308Z ERROR project_model::rustc_cfg: failed to get rustc cfgs e=unable to fetch cfgs via `rustc --print cfg -O`

Caused by:
    RUSTUP_TOOLCHAIN="/home" "/home/gh-bjorn3/.cargo/bin/rustc" "--print" "cfg" "-O" failed, exit status: 1
    stderr:
    error: invalid toolchain: the path '/home' has no bin/ directory
    

Stack backtrace:
   0: std::backtrace_rs::backtrace::libunwind::trace
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/../../backtrace/src/backtrace/libunwind.rs:104:5
   1: std::backtrace_rs::backtrace::trace_unsynchronized
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2: std::backtrace::Backtrace::create
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/backtrace.rs:331:13
   3: anyhow::error::<impl anyhow::Error>::msg
   4: project_model::utf8_stdout
   5: project_model::rustc_cfg::get
   6: project_model::workspace::ProjectWorkspace::load_inline
   7: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
   8: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   9: core::ops::function::FnOnce::call_once{{vtable.shim}}
  10: std::sys_common::backtrace::__rust_begin_short_backtrace
  11: core::ops::function::FnOnce::call_once{{vtable.shim}}
  12: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/alloc/src/boxed.rs:2015:9
  13: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/alloc/src/boxed.rs:2015:9
  14: std::sys::pal::unix::thread::Thread::new::thread_start
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/sys/pal/unix/thread.rs:108:17
  15: start_thread
             at ./nptl/pthread_create.c:442:8
  16: thread_start
             at ./misc/../sysdeps/unix/sysv/linux/aarch64/clone.S:79
thread 'main' panicked at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jod-thread-0.1.2/src/lib.rs:33:22:
called `Result::unwrap()` on an `Err` value: Any { .. }
stack backtrace:
   0: rust_begin_unwind
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:647:5
   1: core::panicking::panic_fmt
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/panicking.rs:72:14
   2: core::result::unwrap_failed
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/result.rs:1649:5
   3: jod_thread::JoinHandle<T>::join
   4: stdx::thread::JoinHandle<T>::join
   5: rust_analyzer::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[Veykril]

Assuming you don't have any sysroot settings set, we are just invoking rustc --print sysroot to find it

[bjorn3]

Is it possible that rust-analyzer is detecting a workspace somewhere nested in the rust repo checkout I have inside my cg_clif checkout with an intentionally wrong toolchain? And if so how do I stop it from detecting this?

[Veykril]

It might. The only way to get around this right now is by specifying linkedProjects via your editor config and point that to the main Cargo.toml (we'll have rust-analyzer.toml support very soon sidestepping the client config for this). In the latest r-a you should be able to hover the status bar icon in vscode to tell you more aobut the loaded workspaces

[Veykril]

Hmm, the error message is stating /home/gh-bjorn3/cg_clif though so that doesn't seem to be it

[Veykril]

I can repro this it seems, will investigate (it seems to default to the parent dir for some reason)

[Veykril]

Ah the cause is the inline rust-project specification in the linked projects, The problem is the "sysroot_src": "./build/stdlib/library",, we currently assume the sysroot to exist when a sysroot_src is supplied, and we there assume its 5 directories up hence the weird path being used as a sysroot

[bjorn3]

I tried using "./example/std_example.rs" in the place of the inline rust-project that uses sysroot_src, but when I do that, rust-analyzer spams the following in the logs:

2024-04-29T10:40:18.397992Z ERROR project_model::workspace: cyclic deps: rustc_codegen_cranelift(Idx::<CrateData>(11)) -> rustc_codegen_cranelift(Idx::<CrateData>(11)), alternative path: rustc_codegen_cranelift(Idx::<CrateData>(11))

And alternates between the following status messages: "Roots scanned: 275/277: rust", "Roots scanned: 275/277: download", and no status message at all.

[bjorn3]

Also if the "Loaded workspaces" list is too big, I can't scroll down, thus making the buttons beneath it inaccessible.