10491: Support nested type on replace if let with match r=k-nasa a=k-nasa
## Why
close: https://github.com/rust-analyzer/rust-analyzer/issues/8690
Now, Replacing if-let with match cant't output exhaustive patterns code.
This was because the `else` conversion used specific types (ex. Option, Result) instead of wildcards.
I thought it was more of a problem to generate non-exhaustive patterns than the benefits of using the concrete one.
How about using wildcards in `else`?
Is this change policy acceptable?
## What
- using wildcards on `make_else_arm`
- Change test cases
Co-authored-by: k-nasa <htilcs1115@gmail.com>
10546: feat: Implement promote_local_to_const assist r=Veykril a=Veykril
Fixes#7692, that is now one can invoke the `extract_variable` assist on something and then follow that up with this assist to turn it into a const.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10539: Add "generate delegate methods" assist r=Veykril a=yoshuawuyts
_Co-authored with `@rylev_.`
This patch adds a new assist: "generate delegate method" which creates a method that calls to a method defined on an inner field. Delegation is common when authoring newtypes, and having IDE support for this is the best way we can make this easier to author in Rust, bar adding language-level support for it. Thanks!
Closes#5944.
## Example
__before__
```rust
struct Age(u8);
impl Age {
fn age(&self) -> u8 {
self.0
}
}
struct Person {
ag$0e: Age,
}
```
__after__
```rust
struct Age(u8);
impl Age {
fn age(&self) -> u8 {
self.0
}
}
struct Person {
age: Age,
}
impl Person {
$0fn age(&self) -> u8 {
self.age.age()
}
}
```
Co-authored-by: Ryan Levick <me@ryanlevick.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
10529: Generate `PartialOrd` implementations r=Veykril a=yoshuawuyts
_co-authored with `@rylev_`
This closes#5946 (which should've been closed already, lol). This PR makes it so we generate `PartialOrd` code implementations where possible. This is the last of Rust's built-in traits that was missing codegen.
After this has been merged we should look at moving the tests to a better spot, and maybe cleaning up the implementation somewhat (it's rather copy-pasty at the moment).
Either way, this finishes up the functionality. Thanks heaps!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
10532: Rename `descend_into_macros` Function per FIXME comment r=Veykril a=mirkoRainer
This renames `descend_into_macros` to `descend_into_macros_single` and `descend_into_macros_many` into `descend_into_macros`.
However, this does not touch a function in `SemanticsImpl` of same name.
I was prompted to do this per a FIXME comment, which is removed in this PR.
Co-authored-by: Mirko Rainer <mirkorainer@outlook.com>
This renames `descend_into_macros` to `descend_into_macros_single` and `descend_into_macros_many` into `descend_into_macros`.
However, this does not touch a function in `SemanticsImpl` of same name.
10440: Fix Clippy warnings and replace some `if let`s with `match` r=Veykril a=arzg
I decided to try fixing a bunch of Clippy warnings. I am aware of this project’s opinion of Clippy (I have read both [rust-lang/clippy#5537](https://github.com/rust-lang/rust-clippy/issues/5537) and [rust-analyzer/rowan#57 (comment)](https://github.com/rust-analyzer/rowan/pull/57#discussion_r415676159)), so I totally understand if part of or the entirety of this PR is rejected. In particular, I can see how the semicolons and `if let` vs `match` commits provide comparatively little benefit when compared to the ensuing churn.
I tried to separate each kind of change into its own commit to make it easier to discard certain changes. I also only applied Clippy suggestions where I thought they provided a definite improvement to the code (apart from semicolons, which is IMO more of a formatting/consistency question than a linting question). In the end I accumulated a list of 28 Clippy lints I ignored entirely.
Sidenote: I should really have asked about this on Zulip before going through all 1,555 `if let`s in the codebase to decide which ones definitely look better as `match` :P
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
Consider these expples
{ 92 }
async { 92 }
'a: { 92 }
#[a] { 92 }
Previously the tree for them were
BLOCK_EXPR
{ ... }
EFFECT_EXPR
async
BLOCK_EXPR
{ ... }
EFFECT_EXPR
'a:
BLOCK_EXPR
{ ... }
BLOCK_EXPR
#[a]
{ ... }
As you see, it gets progressively worse :) The last two items are
especially odd. The last one even violates the balanced curleys
invariant we have (#10357) The new approach is to say that the stuff in
`{}` is stmt_list, and the block is stmt_list + optional modifiers
BLOCK_EXPR
STMT_LIST
{ ... }
BLOCK_EXPR
async
STMT_LIST
{ ... }
BLOCK_EXPR
'a:
STMT_LIST
{ ... }
BLOCK_EXPR
#[a]
STMT_LIST
{ ... }
