rust-lang / rust-analyzer

A Rust compiler front-end for IDEs
https://rust-analyzer.github.io/
Apache License 2.0
13.62k stars 1.49k forks source link

/home is incorrectly detected as the rust toolchain to use #17159

Open bjorn3 opened 2 weeks ago

bjorn3 commented 2 weeks ago

rust-analyzer version: rust-analyzer version: 0.4.1938-standalone (https://github.com/rust-lang/rust-analyzer/commit/f216be4a0746142c5f30835b254871256a7637b8 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 commented 2 weeks ago

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

bjorn3 commented 2 weeks ago

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 commented 2 weeks ago

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 image

Veykril commented 2 weeks ago

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

Veykril commented 2 weeks ago

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

Veykril commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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