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.
bors[bot] [Mon, 21 Feb 2022 10:21:39 +0000 (10:21 +0000)]
Merge #11424
11424: Pass required features to cargo when using run action r=Veykril a=WaffleLapkin
When using `F1`->`Rust Analyzer: Run` action on an `example`, pass its `required-features` to `cargo run`. This allows to run examples that were otherwise impossible to run with RA.
KarlWithK [Fri, 18 Feb 2022 02:27:37 +0000 (20:27 -0600)]
Correctly fix formatting doc tests with generics
Before the doc_test would be outputted like this:
"Foo<T, U>::t"
However, this would cause shells with shell redirection. I've changed it
so when generics are involved we simply wrap the expression under escape
chanters as so:
"\"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
projects / rust.git / log