Rust Analyzer not working on any project


I don't know what's wrong with my setup, but rust-analyzer on VS Code fails with this error on every project I have, even on a newly created project.

[ERROR rust_analyzer::main_loop] FetchWorkspaceError:
rust-analyzer failed to load workspace: Failed to load the project at /path/to/project/Cargo.toml: Failed to read Cargo metadata from Cargo.toml file /path/to/project/Cargo.toml, Some(Version { major: 1, minor: 73, patch: 0 }): Failed to run `cd "/path/to/project" && "cargo" "metadata" "--format-version" "1" "--features" "unstable" "--manifest-path" "/path/to/project/Cargo.toml" "--filter-platform" "x86_64-apple-darwin"`: `cargo metadata` exited with an error: error: none of the selected packages contains these features: unstable

I'm not sure why it's looking for that unstable feature.

What is your vscode config?

Turns out I had added this feature to my config a few months ago

@bjorn3 how do you even know the vscode config? microsoft is so atrocious, this thing has many different sources of with global mutable state, im glad someone found a "solution" but AFAIK rust-analyzer in vs code is a nightmare right now on par with some kind of webpack babel stuff, every time i change to a different crate it's the same issue, the thing just keeps looking for the same old crate and doesn't do anything on the one i'm actually looking at.

ctrl-shift-p and then something like user preferences (json).

Ah, you’re right, and I knew that existed, but I’m concerned this doesn’t show all of the config for VSCode, because the settings UI version has 3 separate sections for normal, WSL remote, and workspace.

Furthermore, it seems like rust-analyzer tends to dwell on some crate, and when I go visit a new crate cloned from GitHub in another directory path, rust-analyzer doesn’t find it, just keeps looking for the old stuff.

A chain of fd + rg finds a lot of hidden state for VSCode and this is just the stuff on the WSL2 Ubuntu side and not even including the hidden state on the Windows side.

I just feel like rust analyzer is really cool and probably works great but I’m constantly struggling with getting it pointed in the right direction and the vs code extension is super hard to debug because it’s really unclear about what folders it’s looking at for Cargo.toml files and why. You can stop, start, restart, etc, in the clicky context menu, but that doesn’t solve issues like “please analyze this crate at path X” or “I changed the path to crate Y” … and the docs for RA seem to indicate you have to set an env var to get info level logs, which seems odd, isn’t info the standard debug level? Even if the RA log level is set higher than info, it seems like “here’s where we analyze” and “here’s where you’re telling us what to analyze” are critical level logs (aka, always print this stuff to stdout, no need to change log levels, the key input configuration is higher priority than info or debug level logs)

Really, I wish the rust analyzer VSCode extension would be more clear about how to tell it what paths to analyze and where exactly it finds that configuration declaration file(s). Right now it seems like you need to set some environment variable just to get any info on this aspect (silly) and then the info you get is an unreadable wall of json, really, rust is such a cool language and this just sucks the fun out of it, it feels like dealing with some random JavaScript module esm webpack babel crap, not the level of reliability and correctness I expect from a Rust project, especially one as valuable and critical to the whole community as Rust Analyzer.

If any devs of the VSCode experience for RA read this, then I hope you’ll take some time to make sure it’s really easy to click on the rust analyzer button and see where exactly rust analyzer is analyzing and how to reconfigure the paths under analysis!

All the settings files listed in the image are per-project settings. These don't apply unless you actually open the directory that contains .vscode/settings.json.

How are you looking at the new crate? Are you using "Open File" or "Open Folder"? The former doesn't open the crate as workspace.

Rust-analyzer by default only looks at the root of the workspace and one level deep for Cargo.toml files representing cargo packages or cargo workspaces. It then works on all source files directly or indirectly used by those packages/workspaces. You can override the set of Cargo.toml files it loads using the rust-analyzer.linkedProjects config.

If you are opening a rust source file outside of an analyzed crate, you will get a notification at the bottom right corner of vscode with a message telling you about this. If the source file is within the directory of an analyzer crate, but not included through mod foo;, you will get a "hint" diagnostic on the first character of the file like so:


If you hover over this it will say: "file not included in crate hierarchy" and if possible it will have a quick fix behind the lighbulb icon to add mod foo; or pub mod foo; to the parent module.

Rust-analyzer itself doesn't read the config files. It is vscode or whichever editor you are using rust-analyzer with which parses the configuration and passes it to the rust-analyzer language server.

Rust-analyzer could definitively use some work to better show which files are and aren't analyzer and how though IMO.

Thank you so much for the thoughtful and helpful reply! I had no idea about the one-level-deep issue and that might be exactly the problem because I basically keep two vs code windows open,

one is on the ~ path with the bashrc / bash_profile so I can quickly mess with environment variables, bash functions, path, etc;

The second is ~/hax which I use for a bunch of projects in subtrees, and hax/externals/ has subtrees for cloned repos for other folks’ projects. I suppose that’s my user error issue then, I’m expecting somehow the system will know which Cargo.toml files to look at, but it’s built more for opening the crate or workspace directly.

Maybe it’s a pipe dream to expect Rust Analyzer to track what files I have open and find the nearest Cargo.toml file and use that. It would be cool. Anyway, I’ll make sure to respect the one level rule when I work with Rust.

So, thank you for the tip, I didn’t know that, and it’s probably exactly my problem!

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.