11201: fix: Fix completions not considering ancestor items for attribute search r=Veykril a=Veykril
Turns out we never filled the `CompletionContext` with the attribute expansion of attributed impls and traits when typing in the assoc items, as we were only considering the assoc item to have an attribute to expand.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11190: fix(completions): improve fn_param r=dbofmmbt a=dbofmmbt
- insert commas around when necessary
- only suggest `self` completions when param list is empty
- stop suggesting completions for identifiers which are already on the param list
Closes#11085
Co-authored-by: Eduardo Canellas <eduardocanellas98@gmail.com>
- insert commas around when necessary
- only suggest `self` completions when param list is empty
- stop suggesting completions for identifiers which are already on the param list
11187: Rename and use the 1.55 ABI for 1.54 r=lnicola a=lnicola
It seems that what we used to call the 1.55 ABI was actually introduced in 1.54.
CC #10799
Thanks to `@danielframpton` for finding it.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
11184: Correctly pass through mutable parameter references when extracting a function r=Veykril a=Vannevelj
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10277
I have based this investigation based on my understanding of [the Borrowing chapter](https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html) but I wasn't able to debug the test runs or see it in action in an IDE. I'll try to figure out how to do that for future PRs but for now, the tests seem to confirm my understanding. I'll lay out my hypothesis below.
Here we define the parameters for the to-be-generated function:
7409880a07/crates/ide_assists/src/handlers/extract_function.rs (L882)
Three values in particular are important here: `requires_mut`, `is_copy` and `move_local`. These will in turn be used here to determine the kind of parameter:
7409880a07/crates/ide_assists/src/handlers/extract_function.rs (L374-L381)
and then here to determine what transformation is needed for the calling argument:
7409880a07/crates/ide_assists/src/handlers/extract_function.rs (L383-L390)
which then gets transformed here:
7409880a07/crates/syntax/src/ast/make.rs (L381-L383)
What I believe is happening is that
* `requires_mut` is `false` (it already is marked as mutable),
* `is_copy` is `false` (`Foo` does not implement `Copy`), and
* `move_local` is `false` (it has further usages)
According to the pattern matching in `fn kind()`, that would lead to `ParamKind::SharedRef` which in turn applies a transformation that prepends `&`.
However if I look at the chapter on borrowing then we only need to mark an argument as a reference if we actually own it. In this case the value is passed through as a reference parameter into the current function which means we never had ownership in the first place. By including the additional check for a reference parameter, `move_local` now becomes `true` and the resulting parameter is now `ParamKind::Value` which will avoid applying any transformations. This was further obscured by the fact that you need further usages of the variable or `move_local` would be considered `true` after all.
I didn't follow it in depth but it appears this idea applies for both the generated argument and the generated parameter.
There are existing tests that account for `&mut` values but they refer to local variables for which we do have ownership and as such they didn't expose this issue.
Co-authored-by: Jeroen Vannevel <jer_vannevel@outlook.com>
11061: Support "move if to guard" for if else chains r=weirane a=weirane
The idea is to first parse the if else chain into a vector of `(Condition, BlockExpr)`s until we reach an iflet branch, an else branch, or the end (the tail). Then add the match arms with guard for the vector, and add the tail with no if guard.
Because the whole original match arm is replaced and the generated code doesn't have redundent commas, I removed redundent commas in some test cases.
Closes#11033.
Co-authored-by: Wang Ruochen <wrc@ruo-chen.wang>
11178: Fix replace_match_with_if_let removing unsafe blocks r=bugadani a=bugadani
If the assist encounters an unsafe block in one of the match arms, the assist generated intermediate code like the following:
```rust
if let Foo(_) = foo {
<then branch>
} else unsafe { ... }
```
Which was then parsed back and the unsafe branch got completely removed, removing in invalid code output:
```rust
if let Foo(_) = foo {
<then branch>
} else
```
This PR fixes this issue.
However, I'm sure there is a better, more general solution here, but I lack familiarity with rust-analyzer. `make::expr_if` looks like it expects a `BlockExpr` that, when printed, is wrapped in braces correctly, but I'm sure changing the display impl for an `unsafe` `BlockExpr` would have caused problems. I could have changed `make::expr_if` instead to special case unsafe blocks, but that would have meant some expressions getting wrapped by the caller (as previously), and some others by the function.
Co-authored-by: Dániel Buga <bugadani@gmail.com>
