Implement multi workspace/multiple crate cargo check support

[kiljacken]

While trying to fix #2780 I had some thoughts about how cargo check watching interacts with multi-workspaces and multiple-project-in-single-workspace setups.

Having multiple workspaces is in theory simple: Just launch a watcher for each workspace, and then figure out how to multiplex the result channels. Should be doable, with not too large an amount of work.

The main issue comes with having multiple projects inside a single workspace. Because multiple crates that don't share a cargo workspace could depend on each other, we can't naively run a cargo check instance for each crate.

And here's where i need somebody to check my thoughts: It seems that the thing we need to do, to solve both issues, is to run a check watcher for each crate where:

• The crate lives in an open workspace.
• The crate is a purely a root in the crate graph, that is, not other crate depends on it.

Which doesn't sound too bad. There is one small problem, which is probably a solved problem in graph theory: For the second condition to be checked quickly, we need to be able to invert the crate graph, so that instead of mapping from crate -> dependencies it maps crate -> crates depending on it.

The above seems to make sense in my head, but I'd love hear peoples opinions. These things tend to turn out better and simpler when multiple heads come together.

[kiljacken]

Hmm, we'd still have problems with locking per cargo workspace, but the above would ensure that every crate would eventually get diagnostics.

[DianaNites]

Any progress here? Lack of diagnostics for all but the first VSCode workspace is a frequent pain point for me.

[Ten0]

For the single-workspace, multi-project setup, wouldn't it trigger the cargo check locks (Blocking waiting for file lock on build directory), and thus hurt performance? Also, wouldn't it eat insane amounts of resources if the workspace is large?
If either of these two issues is real, what about adding an option to cargo where it wouldn't stop checking whatever it can check even if one crate failed? This way, even with a single cargo check on the workspace, every crate that can compile or is the cause of non-compilation would still get diagnostics.

[danilaml]

Would be nice to have the support for this like in the IntelliJ plugin. Or at least a way to switch the "current" Cargo project in the workspace.

[jonas-schievink]

Since #6027 we support multiple cargo check processes, and will spawn one per client workspace. I don't think it supports multiple Cargo workspaces (or crates without workspace) in the same client workspace though.

[matklad]

I don't think it supports multiple Cargo workspaces (or crates without workspace) in the same client workspace though.

@jonas-schievink hm, my understanding is that this issue is completely fixed though? We spawn cargo check for each separate linked project, and that's all there's to do, no?

I'd close this issue, but I am confused by your comment, so maybe I am missing something?

If anything, this works too well: #8631 🤣

[jonas-schievink]

Hmm, yeah, I think this might be a case of confusing terminology. Workspace can mean "Cargo workspace", "client workspace", or "whatever rust-analyzer considers a workspace".

[MolotovCherry]

If anyone comes from google, the way to do this is:

In .vscode/settings.json:

{
    "rust-analyzer.linkedProjects": [
        "path/to/Cargo.toml",
        "another/path/to/Cargo.toml"
    ]
}