Set documentation field in SCIP from doc comment
Previously, the documentation field was the same as the text shown to users when they hover over that symbol. The documentation should really just be the doc comment, and as of #16179 the signature is already stored in the signatureDocumentation field.
Previously, the documentation field was the same as the text shown to
users when they hover over that symbol. The documentation should
really just be the doc comment, and as of #16179 the signature is
already stored in the signatureDocumentation field.
feature: Add basic support for `become` expr/tail calls
This follows https://github.com/rust-lang/rfcs/pull/3407 and my WIP implementation in the compiler.
Notice that I haven't even *opened* a compiler PR (although I plan to soon), so this feature doesn't really exist outside of my WIP branches. I've used this to help me test my implementation; opening a PR before I forget.
(feel free to ignore this for now, given all of the above)
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`
