rust-analyzer: rust-analyzer failed to load workspace

@aodhneine I would advise against leaving comments like “no one cares about this issue anymore”. Most people who work on rust-analyzer care a lot about it working great, but at the same time the amount of effort one needs to put in to make this happen far outweighs the available resources.

This in general applies to all open source and closed source projects: inferring that the issue does not get “enough” attention due to the lack of care is not really right (most time the issue is available time) and not really helpful (as it, to put it bluntly, makes the maintainers feel bad).

Thank you for the response! I was really tired and frustrated after three days of no one responding, but I think that letting my frustration out here was inappropiate, and I’m sorry for that.

Nevertheless, I hope that this bug report will help to improve such an awesome project (I used to use it few months ago without issues) and that it’ll be resolved quickly. Feel free to ask if there’s something I can help with.

I still didn’t have resolved the problem, but it seems like no one cares about this issue anymore.

I encountered the same issue, but I managed to resolve it. Here’s how I tackled it:

The directory structure of my worktree is as follows:

.vscode
└── settings.json
src
└── challenges
    └── some modules...
    lib.rs
    main.rs
Cargo.lock
Cargo.toml

Within the .vscode folder, there is a settings.json file that contains the following data:

{
  "rust-analyzer.linkedProjects": [
    "./challenges/Cargo.toml"
  ]
}

As you can observe, I don’t have a ./challenges/Cargo.toml file because I initially created that folder as a library using cargo new --lib and later deleted it. This is why the incorrect path exists.

To resolve the issue, I simply modified the configuration to make rust-analyzer work again:

{
  "rust-analyzer.linkedProjects": [
    "./Cargo.toml"
  ]
}

Thanks DrSensor! Didn’t try your solution but I did reproduce this issue by opening VSCode from Windows OS instead of from WSL2.

Opening Code from WSL2 terminal “code .” avoids the issue. Bottom left corner of VSCode will show if you’re connected.

I have a similar error:

[ERROR rust_analyzer::reload] failed to switch workspaces: rust-analyzer failed to load workspace: "cargo" "--version" failed: No such file or directory (os error 2)

I am working inside a dev container, and cargo is installed under “$HOME/.cargo” also present in $PATH.+ I attached the Output of Rust Analyzer Client as well. Rust Analyzer Client Output.txt

Okay, thanks everyone for spending your time trying to fix this. ❤️

Still got the same error:

[ERROR rust_analyzer::reload] failed to switch workspaces: rust-analyzer failed to load workspace: "cargo" "--version" failed: No such file or directory (os error 2)

I also have Windows 10 as host, and Fedora Linux as remote (for develop machine). Using vscode remote feature. And I’m using asdf-vm as rust’s version control. which cargo will show ~/.asdf/shims/cargo as binary path.

cargo can be ran in the zsh shell by cargo --version, and it shows cargo 1.54.0 (5ae8d74b3 2021-06-22)

Trace log: rust-analyzer_cargo-not-exists.txt

Is rust-analyzer running inside or outside the container? Can you get the environment variables of rust-analyzer to check if ~/.cargo/bin is indeed in PATH. (eg cat /proc/$pid/environ | tr '\0' '\n' where pid is the pid of rust-analyzer as seen inside the container if you run it inside the container or as seen outside the container if you run it outside. In the latter case you may need to run it as root.)

@sanket1729 I recommend you to open Output > Rust Analyzer Client and if present Output > Rust Analyzer Language Server (without Trace) and send these logs to us next time you see something weird. And turning this on should also help us:

{
    "rust-analyzer.trace.extension": true
}

I think I resolved the issue. But I have no idea what happened or how I solved it. I cannot reproduce the bug anymore on my computer.

I just reinstalled the rust one more time using rustup-init.sh and for some reason everything worked correctly.

Regardless of this, thank you for the bug report ❤️ ! It is helpful.