10103: fix: make "find references" multi-token mapping aware r=jonas-schievink a=jonas-schievink
Part of https://github.com/rust-analyzer/rust-analyzer/issues/10070
I was hoping that this would fix "find references" on salsa queries, but salsa emits multiple defs sharing the same span (the trait method, and an impl of that trait).
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9954: feat: Show try operator propogated types on ranged hover r=matklad a=Veykril
Basically this just shows the type of the inner expression of the `?` expression as well as the type of the expression that the `?` returns from:
Unless both of these types are `core::result::Result` in which case we show the error types only.
If both types are `core::option::Option` with different type params we do not show this special hover either as it would be pointless(instead fallback to default type hover)
Very much open to changes to the hover text here(I suppose we also want to show the actual type of the `?` expression, that is its output type?).
Fixes#9931
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
10095: internal: Augment panic context when resolving path r=jonas-schievink a=jonas-schievink
Should help with debugging https://github.com/rust-analyzer/rust-analyzer/issues/10084 and similar issues.
Might have a perf impact since the string is created on every function call.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10097: fix: Allow inherent impls for arrays r=jonas-schievink a=jonas-schievink
Part of https://github.com/rust-analyzer/rust-analyzer/issues/9992 (method resolution of these methods still does not work)
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10091: fix: fix "disjunction in conjunction" panic r=matklad a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10073
The DNF construction code created expressions that were combined in a way that made us "forget" to make their contents valid DNF again. This PR fixes that by flattening nested `any(any())` and `all(all())` predicates. There was also a typo that led to a redundant call to `make_nnf` instead of the correct recursive call to `make_dnf` (but this didn't seem to break/fix anything).
This also adds some light property testing, though I'm not really sure this is the best way to do it.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10092: feat: Improve `extract_struct_from_enum_variant` output r=matklad a=DropDemBits
Improves the struct generated by `extract_struct_from_enum_variant`.
Summary of changes:
- Indent the generated struct and enum to the same indent level
- Preserve comments & attributes from the enum variant (something I missed when doing the same thing for the variant fields)
- Use enum's visibility for fields without any visibility, instead of filling it in with `pub`
Co-authored-by: DropDemBits <r3usrlnd@gmail.com>
10076: Use struct init shorthand when applicable in fill struct fields assist r=matklad a=nathanwhit
This PR tweaks the fill struct fields assist to use the struct init shorthand when a local variable with a matching name and type is in scope.
For example:
```rust
struct Foo {
a: usize,
b: i32,
c: char,
}
fn main() {
let a = 1;
let b = 2;
let c = 3;
let foo = Foo { <|> };
}
```
Before we would insert
```rust
Foo {
a: (),
b: (),
c: (),
}
```
now we would insert
```rust
Foo {
a,
b,
c: ()
}
```
Co-authored-by: nathan.whitaker <nathan.whitaker01@gmail.com>
closes#9922
Turned out to be trivial after preliminary refactor.
The intended behavior is that we schedule cache priming once ws become
quiescent (that is, we fully load cargo project), and we continue to
rschedule it until it completes (priming might get cancelled by user
typing into a file).
Group related stuff together, use only on path for parsing extern blocks
(they actually have modifiers).
Perhaps we should get rid of items_without_modifiers altogether? Better
to handle these kinds on diagnostics in validation layer...
