Activate on top level Cargo.toml and rust-project.json files

[DavisVaughan]

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:

Screen.Recording.2024-02-13.at.10.02.21.AM.mov

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).

Lastly, the VS Code search filtering uses the same glob patterns, and it also doesn't match with */Cargo.toml:

Screen.Recording.2024-02-12.at.6.10.45.PM.mov

---

If you want both top level Cargo.tomls and 1-level-deep Cargo.tomls 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.

Screen.Recording.2024-02-13.at.10.10.44.AM.mov

[Veykril]

I definitely observed this behavior before as well, thanks for double checking!
@bors r+

[bors]

📌 Commit 45e05ab has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit 45e05ab with merge 22ca3fd...

[bors]

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 22ca3fd to master...