Subtree update of rust-analyzer
#121255
Merged
Subtree update of rust-analyzer
#121255
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ulacrum Add LocalWaker and ContextBuilder types to core, and LocalWake trait to alloc. Implementation for rust-lang#118959.
internal: sync from downstream
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 rust-lang/rust-analyzer#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?
internal: tool discovery prefers sysroot tools Fixes rust-lang/rust-analyzer#15927, Fixes rust-lang/rust-analyzer#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.
fix: Fix macro transcriber emitting incorrect lifetime tokens Fixes rust-lang/rust-analyzer#16529
…r=Veykril feat: ignored and disabled macro expansion Supersedes rust-lang#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.
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: 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-6c7485e77d88
https://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 😄_
fix: Respect textual length of paths in find-path Fixes rust-lang/rust-analyzer#16572
fix: Don't show type mismatches for `{unknown}` to non-`{unknown}` mismatches
Fixes rust-lang/rust-analyzer#15704
Basically we zip the two types, inspecting their substitutions if the constructors are the same, if we encounter a zip step with an `{unknown}` on one side and a non-`{unknown}` on the other we error out and discard the diagnostic. Otherwise we keep it.
internal: bump `actions/checkout` to v4 Silences more Node version warnings.
Use newer versions of actions, Node 16 -> 18 Fixes several warnings in the actions tab regarding usage of Node 16
ci: Update GitHub Actions and Node version Use newer versions of actions; Node 16 -> 18 Fix several warnings in the actions tab regarding usage of the EOL Node 16
…kril fix: Remove cargo knowledge from `CrateData` Fixes rust-lang/rust-analyzer#16170, Fixes rust-lang/rust-analyzer#15656
Bounds are CONSTNESS ASYNCNESS POLARITY
…s, r=Veykril internal: Parse (nightly) `const` and `async` trait bounds Both of these bound modifiers were added recently: * `const` trait bounds: rust-lang#119099 * `async` trait bounds: rust-lang#120392 The latter will certainly will not do the right thing; namely, `async Fn` needs to be mapped to the `AsyncFn` trait. IDK how to do that, so advice would be appreciated, though perhaps we could land this first so the parser isn't complaining about these bounds?
…th-escaped-bits-and-cr, r=Veykril fix: Fix snippets being placed leftwards of where they should be Snippet bits were being escaped before placing snippets, shifting snippets leftwards. Snippets were also being shifted leftwards on files with CRLF line endings since they were placed done after the Unix -> DOS line ending conversion. Hoping this fixes all of the little bugs related to snippet rendering 😅
|
rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead. cc @rust-lang/rust-analyzer |
rustbot
added
the
S-waiting-on-review
|
@bors r+ p=1 subtree sync |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (6f72620): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 639.843s -> 640.535s (0.11%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r? ghost