Emitting these overwrites any syntax based highlighting that is being done in the file, causing a lot of noise if the user gave them a specific color.
bors r+
- don't return the receiver type from method resolution; instead just
return the autorefs/autoderefs that happened and repeat them. This
ensures all the effects like trait obligations and whatever we learned
about type variables from derefing them are actually applied. Also, it
allows us to get rid of `decanonicalize_ty`, which was just wrong in
principle.
- Autoderef itself now directly works with an inference table. Sadly
this has the effect of making it harder to use as an iterator, often
requiring manual `while let` loops. (rustc works around this by using
inner mutability in the inference context, so that things like unifying
types don't require a unique reference.)
- We now record the adjustments (autoref/deref) for method receivers
and index expressions, which we didn't before.
- Removed the redundant crate parameter from method resolution, since
the trait_env contains the crate as well.
- in the HIR API, the methods now take a scope to determine the trait env.
`Type` carries a trait env, but I think that's probably a bad decision
because it's easy to create it with the wrong env, e.g. by using
`Adt::ty`. This mostly didn't matter so far because
`iterate_method_candidates` took a crate parameter and ignored
`self.krate`, but the trait env would still have been wrong in those
cases, which I think would give some wrong results in some edge cases.
Florian Diebold [Wed, 16 Feb 2022 16:44:03 +0000 (17:44 +0100)]
Refactor autoderef and method resolution
- don't return the receiver type from method resolution; instead just
return the autorefs/autoderefs that happened and repeat them. This
ensures all the effects like trait obligations and whatever we learned
about type variables from derefing them are actually applied. Also, it
allows us to get rid of `decanonicalize_ty`, which was just wrong in
principle.
- Autoderef itself now directly works with an inference table. Sadly
this has the effect of making it harder to use as an iterator, often
requiring manual `while let` loops. (rustc works around this by using
inner mutability in the inference context, so that things like unifying
types don't require a unique reference.)
- We now record the adjustments (autoref/deref) for method receivers
and index expressions, which we didn't before.
- Removed the redundant crate parameter from method resolution, since
the trait_env contains the crate as well.
- in the HIR API, the methods now take a scope to determine the trait env.
`Type` carries a trait env, but I think that's probably a bad decision
because it's easy to create it with the wrong env, e.g. by using
`Adt::ty`. This mostly didn't matter so far because
`iterate_method_candidates` took a crate parameter and ignored
`self.krate`, but the trait env would still have been wrong in those
cases, which I think would give some wrong results in some edge cases.
bors[bot] [Thu, 24 Feb 2022 12:57:51 +0000 (12:57 +0000)]
Merge #11531
11531: fix: Make fill_match_arms assist handle doc(hidden) and non_exhaustive r=Veykril a=OleStrohm
Fixes #11499
Fixes #11500
This keeps track of the relevant attributes and adds in a wildcard pat at the end of the match when necessary.
I decided to do them in the same PR since they both needed the ability to add a wildcard arm, and so their changes would overlap if done separately, but I'll split them up if that seems better.
This is my first PR to rust-analyzer, so all feedback is greatly appreciated!
bors[bot] [Thu, 24 Feb 2022 11:25:18 +0000 (11:25 +0000)]
Merge #11540
11540: fix: Resolve private fields in type inference r=flodiebold a=Veykril
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10253#issuecomment-920962927
(the same issue probably exists for method calls, but I think fixing that might be trickier)
Visibility checks were introduced in https://github.com/rust-analyzer/rust-analyzer/issues/7841 for autoderef to work properly, so now we just record the first field we find unconditionally, and then overwrite it if autoderef manages to find another field in a later cycle.
bors[bot] [Tue, 22 Feb 2022 18:46:12 +0000 (18:46 +0000)]
Merge #11461
11461: Extract struct from enum variant filters generics r=jo-goro a=jo-goro
Fixes #11452.
This PR updates extract_struct_from_enum_variant. Extracting a struct `A` form an enum like
```rust
enum X<'a, 'b> {
A { a: &'a () },
B { b: &'b () },
}
```
will now be correctly generated as
```rust
struct A<'a> { a: &'a () }
enum X<'a, 'b> {
A(A<'a>),
B { b: &'b () },
}
```
instead of the previous
```rust
struct A<'a, 'b>{ a: &'a () } // <- should not have 'b
This also works for generic type parameters and const generics.
Bounds are also copied, however I have not yet implemented a filter for unneeded bounds. Extracting `B` from the following enum
```rust
enum X<'a, 'b: 'a> {
A { a: &'a () },
B { b: &'b () },
}
```
will be generated as
```rust
struct B<'b: 'a> { b: &'b () } // <- should be `struct B<'b> { b: &'b () }`
bors[bot] [Tue, 22 Feb 2022 10:12:30 +0000 (10:12 +0000)]
Merge #11513
11513: internal: Expand the derive attribute into a pseudo expansion r=Veykril a=Veykril
Quoting my comment:
> We generate a very specific expansion here, as we do not actually expand the `#[derive]` attribute
> itself in name res, but we do want to expand it to something for the IDE layer, so that the input
> derive attributes can be downmapped, and resolved as proper paths.
> This is basically a hack, that simplifies the hacks we need in a lot of ide layer places to
> somewhat inconsistently resolve derive attributes.
>
> As such, we expand `#[derive(Foo, bar::Bar)]` into
> ```
> #[Foo]
> #[bar::Bar]
> ();
> ```
> which allows fallback path resolution in hir::Semantics to properly identify our derives.
> Since we do not expand the attribute in nameres though, we keep the original item.
>
> The ideal expansion here would be for the `#[derive]` to re-emit the annotated item and somehow
> use the input paths in its output as well.
> But that would bring two problems with it, for one every derive would duplicate the item token tree
> wasting a lot of memory, and it would also require some way to use a path in a way that makes it
> always resolve as a derive without nameres recollecting them.
> So this hacky approach is a lot more friendly for us, though it does require a bit of support in
> [`hir::Semantics`] to make this work.
bors[bot] [Mon, 21 Feb 2022 21:57:44 +0000 (21:57 +0000)]
Merge #11490
11490: Correctly fix formatting doc tests with generics r=Veykril a=KarlWithK
Before the doc_test would be outputted like this:
```zsh
"Foo<T, U>::t"
```
However, this would cause problems with shell redirection. I've changed it
so when generics are involved we simply wrap the expression under quotes as so:
```zsh
"\"Foo<T, U>::t\""
```
Note:
At the cost of adding this, I had to allocate a new string via
`format!{}`. However, I argue this is alright as this for just for
outputting the name of the doc test.
The following tests have been changed:
```
runnables::tests::doc_test_type_params
runnables::tests::test_doc_runnables_impl_mod
runnables::tests::test_runnables_doc_test_in_impl
```
bors[bot] [Mon, 21 Feb 2022 13:08:31 +0000 (13:08 +0000)]
Merge #11481
11481: Display parameter names when hovering over a function pointer r=Veykril a=Vannevelj
Implements #11474
The idea is pretty straightforward: previously we constructed the hover based on just the parameter types, now we pass in the parameter names as well. I went for a quick-hit approach here but I expect someone will be able to point me to a better way of resolving the identifier.
I haven't figured out yet how to actually run my rust-analyzer locally so I can see it in action but the unit test indicates it should work.
projects / rust.git / log