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,
Substitute $saved_file in custom check commands
If the custom command has a $saved_file placeholder, and we know the file being saved, replace the placeholder and run a check command.
If there's a placeholder and we don't know the saved file, do nothing.
This is a simplified version of #15381, which I hope is easier to review.
feat: Introduce term search to rust-analyzer
# Introduce term search to `rust-analyzer`
_I've marked this as draft as there might be some shortcomings, please point them out so I can fix them. Otherwise I think it is kind of ready as I think I'll rather introduce extra functionality in follow up PRs._
Term search (or I guess expression search for rust) is a technique to generate code by basically making the types match.
Consider the following program
```rust
fn wrap(arg: i32) -> Option<i32> {
todo!();
}
```
From the types of values in scope and constructors of `Option`, we can produce the expected result of wrapping the argument in `Option`
Dependently typed languages such as `Idris2` and `Agda` have similar tools to help with proofs, but this can be also used in everyday development as a "auto-complete".
# Demo videos
https://github.com/rust-lang/rust-analyzer/assets/19900308/7b68a1b7-7dba-4e31-9221-6c7485e77d88https://github.com/rust-lang/rust-analyzer/assets/19900308/0fae530a-aabb-4b28-af71-e19f8d3d64b2
# What does it currently do
- It works well with locals, free functions, type constructors and non-static impl methods that take items by value.
- Works with functions/methods that take shared references, but not with unique references (very conservative).
- Can handle projections to struct fields (eg. `foo.bar.baz`) but this might me more conservative than it has to be to avoid conflicting with borrow checker
- Should create only valid programs (no type / borrow checking errors). Tested with `rust-analyzer analysis-stats /path/to/ripgrep/Cargo.toml --run-term-search --validate-term-search` (basically running `cargo check` on all of the generated programs and only error seems to be due to type inference which is more of issue of testing method.
# Performace / fitness
```txt
ripgrep (latest)
Tail Expr syntactic hits: 130/1692 (7%)
Tail Exprs found: 523/1692 (30%)
Term search avg time: 9ms
Term search: 15.64s, 97ginstr, 8mb
rust-analyzer (on this branch)
Tail Expr syntactic hits: 804/13860 (5%)
Tail Exprs found: 6757/13860 (48%)
Term search avg time: 78ms
Term search: 1088.23s, 6765ginstr, 98mb
```
Highly generic code seems to blow up the search space so currently the amount of generics allowed is functions/methods is limited down to 0 (1 didn't give much improvement and 2 is already like 0.5+s search time)
# Plans for the future (not in this PR)
- ``~~Add impl methods that do not take `self` type (should be quite straight forward)~~ Done
- Be smarter (aka less restrictive) about borrow checking - this seems quite hard but since the current approach is rather naive I think some easy improvement is available.
- ``~~See if it works as a autocomplete while typing~~ Done
_Feel free to ask questions / point of shortcoming either here or on Zulip, I'll be happy to address them. I'm doing this as part of my MSc thesis so I'll be working on it till summer anyway 😄_
If the custom command has a $saved_file placeholder, and we know the
file being saved, replace the placeholder and then run a check command.
If there's a placeholder and we don't know the saved file, do nothing.
feat: ignored and disabled macro expansion
Supersedes #15117, I was having some conflicts after a rebase and since I didn't remember much of it I started clean instead.
The end result is pretty much the same as the linked PR, but instead of proc macro lookups, I marked the expanders that explicitly cannot be expanded and we shouldn't even attempt to do so.
## Unresolved questions
- [ ] I introduced a `DISABLED_ID` next to `DUMMY_ID` in `hir-expand`'s `ProcMacroExpander`, that is effectively exactly the same thing with slightly different semantics, dummy macros are not (yet) expanded probably due to errors, while not expanding disabled macros is part of the usual flow. I'm not sure if it's the right way to handle this, I also thought of just adding a flag instead of replacing the macro ID, so that the disabled macro can still be expanded for any reason if needed.
internal: tool discovery prefers sysroot tools
Fixes https://github.com/rust-lang/rust-analyzer/issues/15927, Fixes https://github.com/rust-lang/rust-analyzer/issues/16523
After this PR we will look for `cargo` and `rustc` in the sysroot if it was succesfully loaded instead of using the current lookup scheme. This should be more correct than the current approach as that relies on the working directory of the server binary or loade workspace, meaning it can behave a bit odd wrt overrides.
Additionally, rust-project.json projects now get the target data layout set so there should be better const eval support now.
Update to latest `rustc_pattern_analysis`
Here I go again. Two improvements this time.
1. I've removed the need for an arena for patterns. Turns out this wasn't gaining any performance on the rustc side so may as well allocate normally.
2. I've added a clean error path when types don't match, so rustc_pattern_analysis should never panic except internal logic errors. For now `cx.bug()` calls `never!()` but I'm not sure what `never!()` does. Does it display anything to the user? Otherwise a `debug!()` should be sufficient.
Point 2 should fix https://github.com/rust-lang/rust-analyzer/issues/15883 but I haven't tested it because I'm not sure how to reproduce. Could someone give me pointers as to how to write a test for the pattern code?
