fix: Fix build scripts not being rebuilt in some occasions
Also makes proc-macro changed flag setting async, we don't wanna block `process_changes` on the database as that is on the main thread!
internal: Set channel override when querying the sysroot metadata
This is pretty hard to discover, and makes the setting useless, we should probably enable it for now.
CC #16486
Add completions to show only traits in trait `impl` statement
This is prerequisite PR for adding the assist mentioned in #12500
P.S: If wanted, I will add the implementation of the assist in this PR as well.
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 https://github.com/rust-lang/rust-analyzer/pull/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 (https://github.com/rust-lang/rust-analyzer/pull/10442#issuecomment-932967421):
> 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
fix: Validate literals in proc-macro-srv FreeFunctions::literal_from_str
cc https://github.com/rust-lang/rust-analyzer/pull/16446
meant to only get rid of some string allocs but then I noticed we can just implement this with the bare lexer.
Implement `literal_from_str` for proc macro server
Closes#16233
Todos and unanswered questions:
- [x] Is this the correct approach? Can both the legacy and `rust_analyzer_span` servers depend on the `syntax` crate?
- [ ] How should we handle suffixes for string literals? It doesn't seem like `rust-analyzer` preservers suffix information after parsing.
- [x] Why are the `expect` tests failing? Specifically `test_fn_like_macro_clone_literals`
fix: Fix target layout fetching
https://github.com/rust-lang/rust-analyzer/pull/16537 broke this, as `cargo rustc` cannot run against a virtual workspace, so it will always fail in such projects (like rust-analyzer itself). This brings back the plain rustc fallback,
