11598: feat: Parse destructuring assignment r=Veykril a=ChayimFriedman2
Part of #11532.
Lowering is not as easy and may not even be feasible right now as it requires generating identifiers: `(a, b) = (b, a)` is desugared into
```rust
{
let (<gensym_a>, <gensym_b>) = (b, a);
a = <gensym_a>;
b = <gensym_b>;
}
```
rustc uses hygiene to implement that, but we don't support hygiene yet.
However, I think parsing was the main problem as lowering will just affect type inference, and while `{unknown}` is not nice it's much better than a syntax error.
I'm still looking for the best way to do lowering, though.
Fixes#11454.
Co-authored-by: Chayim Refael Friedman <chayimfr@gmail.com>
11574: Small refactor text edit 2nd r=Veykril a=HansAuger
Some more changes to text_edit. Basic idea is to make `Indel` implement `PartialOrd` to take advantage of some sweet sweet iteration, most notably itertool's `merge`.
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
11623: fix: Add type variable table to InferenceTableSnapshot r=flodiebold a=tysg
Fixes#11601.
I observed that removing the `rollback` line in 6fc3d3aa4c fixes the issue.
Looking at the stacktrace, I believe not restoring `type_variable_table` causes `type_variable_table` and `var_unification_table` to go out of sync, then when `hir_ty::infer::unify::InferenceTable::new_var` tries to extend `type_variable_table` to be the same length as `var_unification_table`, problems will arise.
However, I cannot pinpoint exactly how or where the vector capacity overflow happens, so my understanding might not be correct after all.
Co-authored-by: Tianyi Song <42670338+tysg@users.noreply.github.com>
11595: fix: lower string literals with actual value instead of default r=lnicola a=tysg
Fixes#11582. Some questions below in the code review section.
Co-authored-by: Tianyi Song <42670338+tysg@users.noreply.github.com>
11573: refactorings and FIXME fixes in text edit r=lnicola a=HansAuger
This is mainly me learning some rust, and only anecdotally about addressing some `fixme`s. Feel free to nope :)
There is a follow up PR in the pipeline which tackles the other two `fixme`s but it's a bit more invasive. So I wanted to get this out of the way
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
11550: Refactor autoderef/method resolution r=flodiebold a=flodiebold
- 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.
Fixes#10058.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
- 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.
Fixes#10058.
11531: fix: Make fill_match_arms assist handle doc(hidden) and non_exhaustive r=Veykril a=OleStrohm
Fixes#11499Fixes#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!
Co-authored-by: Ole Strohm <strohm99@gmail.com>
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.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
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
enum X<'a, 'b> {
A(A<'a, 'b>),
B { b: &'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 () }`
enum X<'a, 'b: 'a> {
A { a: &'a () },
B(B<'b>),
}
```
Extracting bounds with where clauses is also still not implemented.
Co-authored-by: Jonas Goronczy <goronczy.jonas@gmail.com>
11472: fix: visibility in impl items and pub(crate) to pub in extract_module r=feniljain a=feniljain
Should fix#11007 and #11443
Makes following changes:
- Removes visiblity modifiers from trait items
- Respect user given visibility
- Updated tests for the same
Co-authored-by: vi_mi <fkjainco@gmail.com>
Co-authored-by: vi_mi <49019259+feniljain@users.noreply.github.com>
