bors[bot] [Thu, 3 Feb 2022 16:30:01 +0000 (16:30 +0000)]
Merge #11403
11403: internal: Shrink `mbe::ExpandError` and `mbe::ParseError` r=Veykril a=Veykril
Also fixes https://github.com/rust-analyzer/rust-analyzer/issues/10051, as we no longer emit an empty diagnostic in some expansion cases which seems to trip up vscode for some reason. Using `compile_error!("")` will still trigger the vscode bug.
bors r+
Currently our completion infra is split into several modules, each trying to do completions for something specific. This "something" is rather unstructured as it stands now, we have a module for `flyimporting path` completions, `unqualified` and `qualified path` completions, modules for `pattern position` completions that only try to complete extra things for patterns that aren't done in the path modules, `attribute` completions that again only try to add builtin attribute completions without adding the normal path completions and a bunch of other special "entity" completions like lifetimes, method call/field access, function param cloning, ... which serve a more specific purpose than the previous listed ones.
As is evident, the former mentioned ones have some decent overlap which requires extra filtering in them so that they don't collide with each other duplicating a bunch of completions(which we had happen in the past at times).
Now this overlap mostly happens with path completions(and keyword completions as well in some sense) which gives me the feeling that having `qualified` and `unqualified` path completions be separate from the rest gives us more troubles than benefits in the long run.
So this is an attempt at changing this structure to instead still go by rough entity for special cases, but when it comes to paths we instead do the module split on the "path kinds"/"locations"(think pattern, type, expr position etc) that exist. This goes hand in hand with the test refactoring I have done that moved tests to "location oriented" modules as well as the `CompletionContext` refactoring that actually already started splitting the context up for path kinds.
This PR moves some path completions out of the `qualified` and `unqualified` path modules namely attribute, visibility, use and pattern paths.
bors[bot] [Thu, 3 Feb 2022 12:21:18 +0000 (12:21 +0000)]
Merge #11399
11399: Fix assoc type shorthand from method bounds r=flodiebold a=flodiebold
In code like this:
```rust
impl<T> Option<T> {
fn as_deref(&self) -> T::Target where T: Deref {}
}
```
when trying to resolve the associated type `T::Target`, we were only
looking at the bounds on the impl (where the type parameter is defined),
but the method can add additional bounds that can also be used to refer
to associated types. Hence, when resolving such an associated type, it's
not enough to just know the type parameter T, we also need to know
exactly where we are currently.
This fixes #11364 (beta apparently switched some bounds around).
Florian Diebold [Thu, 3 Feb 2022 11:43:15 +0000 (12:43 +0100)]
Fix assoc type shorthand from method bounds
In code like this:
```rust
impl<T> Option<T> {
fn as_deref(&self) -> T::Target where T: Deref {}
}
```
when trying to resolve the associated type `T::Target`, we were only
looking at the bounds on the impl (where the type parameter is defined),
but the method can add additional bounds that can also be used to refer
to associated types. Hence, when resolving such an associated type, it's
not enough to just know the type parameter T, we also need to know
exactly where we are currently.
This fixes #11364 (beta apparently switched some bounds around).
bors[bot] [Tue, 1 Feb 2022 23:05:28 +0000 (23:05 +0000)]
Merge #11322
11322: Extract function also extracts comments r=Vannevelj a=Vannevelj
Fixes #9011
The difficulty I came across is that the original assist works from the concept of a `ast::StmtList`, a node, but that does not allow me to (easily) represent comments, which are tokens. To combat this, I do a whole bunch of roundtrips: from the `ast::StmtList` I retrieve the `NodeOrToken`s it encompasses.
I then cast all `Node` ones back to a `Stmt` so I can apply indentation to it, after which it is again parsed as a `NodeOrToken`.
Lastly, I add a new `make::` api that accepts `NodeOrToken` rather than `StmtList` so we can write the comment tokens.
bors[bot] [Mon, 31 Jan 2022 16:03:23 +0000 (16:03 +0000)]
Merge #11388
11388: fix: Fix proc-macro server not using the supplied span in Ident::new r=Veykril a=Veykril
This makes the hack introduced by https://github.com/rust-analyzer/rust-analyzer/pull/10899 obsolete.
For async-trait specifically, (unfortunately, but technically correct) due to how async-trait works, the self local now renders white, as it now resolves to the `__self` local introduced by the attribute.
bors[bot] [Mon, 31 Jan 2022 11:16:22 +0000 (11:16 +0000)]
Merge #11182
11182: fix: don't panic on seeing an unexpected offset r=Veykril a=dimbleby
Intended as a fix, or at least a sticking plaster, for #11081.
I have arranged that [offset()](https://github.com/rust-analyzer/rust-analyzer/blob/1ba9a924d7b161c52e605e157ee16d582e4a8684/crates/ide_db/src/line_index.rs#L105-L107) returns `Option<TextSize>` instead of going out of bounds; other changes are the result of following the compiler after doing this.
Perhaps there's still an issue here - I suppose the server and client have gotten out of sync and that probably shouldn't happen in the first place? I see that https://github.com/rust-analyzer/rust-analyzer/issues/10138#issuecomment-913727554 suggests what sounds like a more substantial fix which I think might be aimed in this direction. So perhaps that one should be left open to cover such things?
Meanwhile, I hope that not-crashing is a good improvement: and I can confirm that it works out just fine in the repro I have at #11081.
Co-authored-by: David Hotham <david.hotham@metaswitch.com>
bors[bot] [Fri, 28 Jan 2022 13:21:24 +0000 (13:21 +0000)]
Merge #11365
11365: Add a way to disable dll copying for users of proc_macro_srv library r=lnicola a=vlad20012
We use `ra_ap_proc_macro_srv` library in IntelliJ Rust in order to expand proc macros. We need a way to disable [DLL copying to a temp dir on Windows](https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/proc_macro_srv/src/dylib.rs#L166) behavior because it causes issues like https://github.com/intellij-rust/intellij-rust/issues/7709. Unlike RA, file locking is not an issue for IntelliJ Rust because we copy DLLs to a temp dir before calling the expander.
git 2.35 introduces a [change in behavior](https://github.com/git/git/blob/89bece5c8c96f0b962cfc89e63f82d603fd60bed/Documentation/RelNotes/2.35.0.txt#L330-L333) that breaks this check.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
bors[bot] [Wed, 26 Jan 2022 17:35:51 +0000 (17:35 +0000)]
Merge #11347
11347: fix: Fix resolution of eager macro contents r=jonas-schievink a=jonas-schievink
Eager macros resolve and expand any contained macro invocations before they are expanded. The logic for this was previously pretty broken: any nameres failure would be reported as a generic macro expansion error, so this didn't work correctly with the fixed-point resolution loop. This manifested as spurious errors whenever a non-legacy macro was used in an eager macro (that means *any* path with more than one segment).
After an intense staring contest with the abyss, this PR fixes the basic logic, but some bugs still remain (particularly around `$crate`). As a side-effect, this PR moves `ModPath` into `hir_expand`.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
bors[bot] [Tue, 25 Jan 2022 16:03:35 +0000 (16:03 +0000)]
Merge #11281
11281: ide: parallel prime caches r=jonas-schievink a=jhgg
cache priming goes brrrr... the successor to #10149
---
this PR implements a parallel cache priming strategy that uses a topological work queue to feed a pool of worker threads the crates to index in parallel.
## todo
- [x] should we keep the old prime caches?
- [x] we should use num_cpus to detect how many cpus to use to prime caches. should we also expose a config for # of worker CPU threads to use?
- [x] something is wonky with cancellation, need to figure it out before this can merge.
bors[bot] [Sun, 23 Jan 2022 16:43:22 +0000 (16:43 +0000)]
Merge #11334
11334: fix: don't panic in semantics due to `cfg_attr` disrupting offsets r=Veykril a=Veykril
Reduces the panic in https://github.com/rust-analyzer/rust-analyzer/issues/11298 to an early return, that means we won't resolve these cases again for now, but this is better than constantly panicking in highlighting and hovering.
bors r+
projects / rust.git / log