fix: Limit depth to 1 when searching for Cargo.toml
#10442
Conversation
|
r? @matklad |
|
As proposed by @heaths in #7268 (comment). This might still be too slow on HDDs and cold caches, but I don't think we can do much more. |
lnicola
changed the title
Cargo.toml
|
I'd say shold only one level deep, to match our auto-discovery logic: https://github.com/matklad/rust-analyzer/blob/15c4b3fa7f9d97029d64a7e13a12aa1ee42316d7/crates/project_model/src/lib.rs#L122 |
|
That makes sense, updated. For some reason, |
|
bors r+ Excellent find by the way! |
10442: fix: Limit depth to 3 when searching for `Cargo.toml` r=matklad a=lnicola ...and add `rust-project.json`. More or less fixes #7268 Co-authored-by: Laurențiu Nicola <[email protected]>
lnicola
changed the title
Cargo.tomlCargo.toml
|
Canceled. |
|
bors r=matklad |
|
How can I get rust-analyzer to discover my workspace if Cargo.toml is deeper than one level? I also have multiple Cargo.toml files in the workspace. |
|
@CalebEverett I suppose it depends. Can you use a Code workspace, or even open separate windows for the Rust and non-Rust parts of your project? |
Hi, thanks. Adding a Cargo.toml to the top level with just the workspace key in it with entries for the other crates worked. [workspace]
members = [
"src/cli-rust",
"src/program-rust",
] |
|
Yeah, if both are Cargo projects then a Cargo workspace is totally the way to go. |
|
So I just hit this, and it's not an option to move Cargo.toml to the top of my directory structure. Is there a setting? I don't understand why this is so rigid. |
|
Elements must be paths pointing to Cargo.toml, rust-project.json, or JSON objects in rust-project.json format. |
…go-toml, r=Veykril Activate on top level `Cargo.toml` and `rust-project.json` files I believe there is an issue with how rust-analyzer is activated from within a VS Code project. IIUC, the intent is that when you open a rust project with a top level `Cargo.toml`, then rust-analyzer should just start right up due to a VS Code activation event. This is not currently the case. i.e. run something like `cargo new ~/Desktop/hithere`, then open that folder in VS Code: https://github.com/rust-lang/rust-analyzer/assets/19150088/1608b985-fd88-4174-a22a-5b3dd0fad84b It is not until you actually open a Rust file that the extension starts up. It looks like this was introduced in #10442. I do agree that recursive searching with `**/` is likely overkill, but I'm not sure `*/Cargo.toml` is working as expected in this comment (#10442 (comment)): > For some reason, */Cargo.toml works for both Cargo.toml in the project root and in a subdirectory (but not two levels deep). That does not seem to be the case for me. I even went into VS Code itself and added some fake tests for `glob.match()` (which is eventually what gets used for this) and `*/Cargo.toml` doesn't seem to match a top level `Cargo.toml` (and I think that makes sense). <img width="1087" alt="Screenshot 2024-02-12 at 6 07 08 PM" src="https://github.com/rust-lang/rust-analyzer/assets/19150088/510b0aaa-ac66-48b1-a9e2-a3bdfc237c48"> Lastly, the VS Code search filtering uses the same glob patterns, and it also doesn't match with `*/Cargo.toml`: https://github.com/rust-lang/rust-analyzer/assets/19150088/4973f5e7-270d-489a-8db4-37469ffe12df --- If you want both top level `Cargo.toml`s and 1-level-deep `Cargo.toml`s to be detected by VS Code's activation events, then I think we need to lay both of those conditions out explicitly, which I've done in this PR. That does fix the problem for me. https://github.com/rust-lang/rust-analyzer/assets/19150088/bfcb1223-c45c-479a-9ea4-4be3f36e6838
...and add
rust-project.json.More or less fixes #7268