"rust-analyzer failed to discover workspace" could be so much more helpful

[matklad]

Today I've got to help a new Rust user to start their Rust project, and our logic to discovering Cargo.tomls was a huge roadblock. Comically gigantic I would say even :)

Basically, the project was in the subdir of the subdir, so nothing worked. But I wasn't able to diagnose on the spot! I had to do the "ok, let's create a new hello-world project and see if it works there" dance to debug this (and it was actually the person whom I was trying to help who said "huh, maybe the problem is that Cargo.toml is in a subdirectory?")

Here's a bunch of ways we can improve this:

• if there are no projects, we should show red/yellow status.
• in the status, and in the "rust-analyzer failed to discover workspace" error notification, we should say HOW TO ACTUALLY FIX THE PROBLEM (it's ridiculous that we don't do this, seeing this message from the newbie eyes really is painful)
• at minimum, we should point at the linked projects settings
• ideally, as suggested to me, there should be an "open Cargo.toml" link which opens open file dialog
• and, yeah, it would be cool to suggesting adding Cargo.toml to linked projects if we notice it some time after opening a project (eg, opening a Rust file).

[DrChat]

On this line of thought - I had some prototype work that added logic to search for all Cargo.toml manifests in the workspace folder tree and then filter them out using cargo metadata so that ProjectManifest::discover returned all workspace root manifests.
Would something like that be useful for including upstream? Is it too costly to call cargo manifest when scanning for projects?

Also related to #9661

[plwalsh]

@matklad Did something in the extension change recently that now prevents it from auto-discovering projects that aren't at the root of the vscode workspace? I could've sworn it was working fine before the last week or two. But now I see the "failed to discover workspace" message every time I open vscode (with my Rust project is two levels down). I'm on the latest insiders release, with the extension set to the pre-release channel.

[matklad]

We only auto-discover Rust projects one-level deep.

[plwalsh]

@matklad Interesting -- thanks!

[zirconium-n]

We only auto-discover Rust projects one-level deep.

Could we change this to a configurable depth?

[plwalsh]

Could we change this to a configurable depth?

Yes, please. Something like the recently implemented git.repositoryScanMaxDepth would be great (microsoft/vscode#37947).

Most often, my vscode workspace is a collection of clones, with several of the nested clones being Rust projects. Previously with RLS (before switching to rust-analyzer), all the nested Rust projects would automatically be "discovered", and I'd have access to all the RLS tools any time a Rust file was opened. Now with RA, I have no features available in my opened Rust files. Unfortunately, all my workspaces are different/dynamic, so keeping track of them all as rust-analyzer.linkedProjects isn't really tenable.

[bjorn3]

For activating the extension, I don't think so. It isn't possible to change the activationEvents of an extension:

rust-analyzer/editors/code/package.json

Line 63 in 61504c8

"workspaceContains:*/Cargo.toml",

When you open a rust file it should still activate though. For once the extension is activated, possibly:

rust-analyzer/crates/project-model/src/lib.rs

Lines 122 to 131 in 61504c8

	fn find_cargo_toml_in_child_dir(entities: ReadDir) -> Vec<ManifestPath> {
	// Only one level down to avoid cycles the easy way and stop a runaway scan with large projects
	entities
	.filter_map(Result::ok)
	.map(|it| it.path().join("Cargo.toml"))
	.filter(|it| it.exists())
	.map(AbsPathBuf::assert)
	.filter_map(|it| it.try_into().ok())
	.collect()
	}

[samgqroberts]

Is there a way to manually resolve this? I have my workspace Cargo.toml a few directories deep in my project. I've scanned the extension settings and can't find a place to manually point rust-analyzer to a Cargo.toml. It seems my only option is to open the subfolder as the root of my VSCode project when I'm working in the Rust portion of it, and switch back to a VSCode window that's at the actual root of my repository for the rest. I've confirmed this works, but it's certainly not ideal.

[matklad]

https://rust-analyzer.github.io/manual.html#rust-analyzer.linkedProjects

[samgqroberts]

That was it! Thank you @matklad

[Astlaan]

I was struggling with strange behaviours from rust-analyzer (sometimes working, others not) for some days, and only now found out this issue of rust projects only being automatically detected on one-level-deep directories.

I think this should be more clear, at least with an error message when no projects are being discovered. But ideally it would probably be useful to allow automatically detecting projects more levels deep by defaulf. If the workspace of the user is too cluttered, he can always exclude folders (such as target etc) from the workspace, or set the depth-level of automatic discovery manually, or set the linkedProjects variable, for example.

[ltfschoen]

I had a similar situation where I had multiple projects in subdirectories that each had their own Cargo.toml file. I got overcame the error rust-analyzer failed to discover workspace by following the steps that i published here:
https://stackoverflow.com/a/75649115/3208553, so now rust-analyser works even though the root directory I have open in VSCode is parent directory two levels above the Cargo.toml file of each of the multiple projects

[shepazon]

Being able co configure the depth of auto-discovery would be so very helpful. Having to configure my VS Code to include specific directories for all my projects sounds like tedium. That would be a lot of unnecessary manual setting maintenance.

[alfredotasty]

For anyone who still can't solve this problem or new joiner of rust that facing this problem when you working on sub directory like this.

for example

/project
├── backEnd
│ └── src
│ └── Cargo.toml
├── frontEnd
│ └── src/app

you can solve this issue by going to setting.json in VS code or click setting in VS code then search rust then click Edit in setting.json

you need to specific path to you Catgo.toml of the project that you working on by adding

 "rust-analyzer.linkedProjects": [
    "/home/user/project/backEnd/Cargo.toml"
  ],

then it should be work.

I hope this one can help rust-analyzer problem and enjoy of develop thing in rust.

[Na3aga]

Just wanted to thank you, alfredotasty !!!!
👍

[prasannavl]

I think this needs a better solution unfortunately. vscode, zed, nvim all needs it's own solutions due to the lack of a rust analyzer becoming able to pick this up in a IDE agnostic way.

Would be great if rust analyzer is able to add a section into one of .cargo/config.toml or rust-toolchain.toml.

Unfortunately, there is no good way to work with large repos, esp. on mono-repos since each editor will require it's own way to tell the LSP about it's projects.

Eg:
zed-industries/zed#9354

[davidbarsky]

I think this needs a better solution unfortunately. vscode, zed, nvim all needs it's own solutions due to the lack of a rust analyzer becoming able to pick this up in a IDE agnostic way.

Would be great if rust analyzer is able to add a section into one of .cargo/config.toml or rust-toolchain.toml.

Unfortunately, there is no good way to work with large repos, esp. on mono-repos since each editor will require it's own way to tell the LSP about it's projects.

Eg: zed-industries/zed#9354

#17537 will help a bit, even if it doesn't solve all issues.