Better diagnostics for unlinked projects

[matklad]

Problem: when opening a project with unusual struture (Cargo.toml buried deep in the source tree) rust-analyzer doesn't work, without a clear error message.

At the moment, when opening the project, we to detect rust project structure we either use likedProjects config, or, if that is absent, look for Cargo.tomls in level one subdirs. So, we fail to discover deeply nested projects.

Soln1: travers all folders, and not only the top level. This is a bad idea, as this is an unbounded amount of work.

Soln2: lazily load Cargo.projects. That is, when a user opens an .rs file which does not belong to any known project, traverse the directory upwards looking for Cargo.toml. This seems like a best solution UX wise on the first glance. There's a big problem though -- non-determinism. If there are two projects, A and B, and A uses B, then opening B first and invoking find useages won't find usages in A, because we don't know about A yet!

Soln3, what we should do: start like soln2, but, instead of magically loading the file, show a popup "add this file to a list of linked projects?". That way, discovery results are persistent, and user always gets the same workspace.

[flodiebold]

If there are two projects, A and B, and A uses B, then opening B first and invoking find useages won't find usages in A, because we don't know about A yet!

If A and B aren't in a common Cargo workspace and A just uses B through a path dependency, would we actually find the usages? My guess would be that we see them as completely separate crate graphs?

[matklad]

If we have an entry for A in the linked projects, then yes, we'll find usages (or at least, will be able to find them in theory, depending on how our source2def picks B).

[jonas-schievink]

Soln1: travers all folders, and not only the top level. This is a bad idea, as this is an unbounded amount of work.

It seems like this is a problem for big workspaces, but I've often used projects where just looking into every top-level directory would be enough to discover all Cargo.tomls needed. So perhaps just descending a single level would be another possible solution here.

It would also be interesting to look at how other IDEs do this.

[matklad]

It seems like this is a problem for big workspaces, but I've often used projects where just looking into every top-level directory would be enough to discover all Cargo.tomls needed. So perhaps just descending a single level would be another possible solution here.

That's exactly what we are doing! ;)

It would also be interesting to look at how other IDEs do this.

IntelliJ Rust does 3, with a caveat that the list of liked projects is managed internally and is not exposed via user-editable config file. That is, instead of JSON, there's a GUI for the list of associated projects

[flodiebold]

The problem with changing the configs currently is that it depends on the client, unless we finally introduce rust-analyzer.toml 😬

[matklad]

Yeah, that's true... I wonder if we should add a "change config" LSP extension?

[flodiebold]

See #8631, we might want to lazily load non-toplevel Cargo projects in any case...

[flodiebold]

This is also related to #6388, I think -- if we're able to load Cargo projects when you open a file from them, the next step would be to create a fake crate for free-standing files when you open them...

[flodiebold]

Btw, we also have the "changing configs" use case for cargo features (toggling them on/off)...

[matklad]

Uhh

[bugadani]

If linkedProject points to the workspace root Cargo.toml, but incorrectly through an inline rust-project.json, vscode may not think my source files are linked, but no indication is given that my config is incorrect:

repro: bugadani/rust-esp32-example@3c093a9 (edited to point at the incorrect config)