WIP: Improve rust project detection #1779
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rust analyser workspaces are very heavyweight and our detection can lead to lots of them spawning. this is an attempt to rationalise that and simplify it to minimise the number of such servers.
Rust projects don't just have a single Cargo.toml. They can have a deep folder structure with multiple crates within. Cargo.lock is a better indicator of the root of the project.
Bit even then we probably want to find the furthest away Cargo.foo not the nearest, as that's more likely to be the real project root. Implement that somewhat generically so that other completers can use it. Java already has a similar codepath but it's more complicated so not touching it.
Finally, even with the above 2 changes, we still have a problem because there might jjust be gaps. Taking wasmtime project for example there are:
./Cargo.toml
./Cargo.lock
./src/foo.rs
./crates/bar/Cargo.toml
./crates/bar/src/bar.rs
./crates/baz/Cargo.toml
./crates/baz/src/baz.rs
So, we allow for the top-level 'project_directory' setting to take precedence if the file opened is in a subdirectory of it.
Fixes #1778
This change is