rust-analyzer: rust-analyzer failed to load workspace
I installed rust with brew on MacOS, and I’m noticing this error on a hello world project with VS Code:
rust-analyzer failed to load workspace:
Failed to find sysroot for Cargo.toml file ./rust_new/Cargo.toml.
Is rust-src installed?: rustup component add rust-src failed
I didn’t install with rustup, and I figured I wouldn’t need to. This suggests I must, but why? Does this suggest I need the complier source to use your package in my editor?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 18
- Comments: 66 (17 by maintainers)
I got same problem on Arch Linux.
Here is the error log in Emacs buffer
*rust-analyzer::stderr*:I create a test project using command
cargo new hello-world.Did uninstall & reinstall nightly toolchain, and here is the output of command:
And I execute command:
I have following setting in
~/.zshrc:rust-srcis the standard library, not compiler source code.rust-analyzerneeds it to know what the standard library types are.I had this problem on Arch Linux too, and solved it with
sudo pacman -R rust. So, for some reason unknown to me,rustwas installed by the systems package manager andrustup, so deleting the version installed bypacmanhas solved my problems.Hey, I just upgraded to the newest rust-analyzer version, and I’ve just started having the same issue.
rustup updaterustup comonent add rust-srcthe only thing left that I can think of doing is settingRUST_SRC_PATHbut I’m not sure what to set that to/why I only now have to set it.rust-srcchanged the path layout, which is the source of the problem.September:
August:
I have the same issue with nightly-x86_64-unknown-linux-gnu (1.48.0-nightly) on ubintu linux and vs code. I have completely uninstalled rust and reinstalled, but I get
running
rustup component add rust-srcyieldsinfo: component 'rust-src' is up to date.it looks like I am missing the
srcfolder:ls /home/woelper/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rustshows justCargo.lock library.$(rustc --print sysroot)points to/home/woelper/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu, which does exist.I should add that this is a VS code remote session, maybe this complicates things?
Yes its work like a charm.
I ran into this problem installing rust_analyser. I installed rustup, used that to install stable toolchain. Ran rustup which rustc which showed a different version to what rustc -V showed. Ran apt-get remove rustc to remove invalid install. Checked with running rustc -V again, which now matched rustup.
After that, the rust_analyser error disappeared and clippy kicked into action.
I finally figured out why. I forgot to exit tmux session… How stupid I am. Sorry for wasted you much time.
After restarted terminal, the problem is gone. Thanks so so much!!
@LU15W1R7H the path changed only once (recently), and while
rust-analyzersupports both locations, for that to work you must unsetRUST_SRC_PATH. See the discussion in #6178.Closing the issue, as it seems to be the problem with local toolchain installation. it would be awesome if we could diagnose and warn about this on our side, but I doubt we can provide info more useful then the existing error message.
This is a bit off-topic but in case you’re using offline installer where
rustupis not available, you can downloadrust-srcdirectly using this URL format:https://static.rust-lang.org/dist/YYYY-MM-DD/rust-src-X.X.X.tar.gz.Check release date and version from this page (latest release only). Example link for v1.71.0:
https://static.rust-lang.org/dist/2023-07-13/rust-src-1.71.0.tar.gz.I have sloved this problem after I copy the folder “.\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library” to the “.\nightly-2020-05-10-x86_64-pc-windows-msvc\lib\rustlib\src\rust”
(nightly-x86_64-pc-windows-msvc and nightly-2020-05-10-x86_64-pc-windows-msvc both are in the sysroot folder).
The reason of the problem is the version error of rustup, as above, it can’t identified the old version toolchains’ folder path layout.
it works after running
rustup component add rust-srcFor anyone jumping to the end of this thread, the solution for me (mentioned here) was:
In Windows system I try to install below and resolved:
@soraiemame the sysroot (
rust-src) structure changed in 1.47 and we only support that and newer versions.Try
rustup component add rust-src --toolchain nightly.Quick update, I uninstalled all of the rust toolchain, and then reinstalled and the issue has gone away
Thank you for responding. I did not know that. I will use the stable toolchain for now then.
I encountered this problem when using rust in a custom alpine docker image. The following solved it.
If you’re using Spacemacs, it has this thing where it saves the environment in a file and reproduces it from there (see ~/.spacemacs.env). Or if you’re not, maybe there’s something similar going on. We’re ignoring RUST_SRC_PATH now if it doesn’t contain core though, so it shouldn’t matter much anymore.
Please post the exact error message you’re getting, and the output from
rustc --print sysrootin your project directory.BTW this seems to have been fixed for me today by 2c408c68a4a27e9a85ce85ec1342e3af58c1571f - thank you!
Oh, sorry, that’s the old path. Look at
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library. The path changed recently andrust-analyzertries both but ends up printing the old one in case of an error, IIRC.Just running
rustup component add rust-srcworked fine for me with latest macOS catalina.Lastly, this should be fixed if you take recent version from master: https://github.com/rust-analyzer/rust-analyzer/commit/6b8bc132dc6dee538964fffa0720480beb5b25dd#diff-30888fefce138d15c65ceb40b37b7ad2R146
Thanks for your reply, this produces the following result:
rust-srcis the source code of the standard library.rust-stdis the compiled version of the standard library.