9334: feat: Allow to disable import insertion on single path glob imports r=Veykril a=Veykril
On by default as I feel like this is something the majority would prefer.
Closes#8490
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9108: Don't show extract into variable assist for unit expressions r=jonas-schievink a=brandondong
**Reproduction:**
```rust
fn main() {
let mut i = 3;
$0if i >= 0 {
i += 1;
} else {
i -= 1;
}$0
}
```
1. Select the snippet of code between the $0's.
2. The extract into variable assist shows up, pushing down the more useful extract into function assist.
3. The resulting output of selecting the extract into variable assist is valid but with the extracted variable having the unit type:
```rust
fn main() {
let mut i = 3;
let var_name = if i >= 0 {
i += 1;
} else {
i -= 1;
};
var_name
}
```
**Fix:**
- Don't show the extract into variable assist for unit expressions. I could not think of any scenarios where such a variable extraction would be desired.
Co-authored-by: Brandon <brandondong604@hotmail.com>
9112: Fix some bugs in `extract_struct_from_enum_variant` assist r=Veykril a=Veykril
bors r+
Fixes#9100Fixes#9099
Kind of fixes #9109, it now copies all the generics might be incorrect if the variant doesn't use all of them)
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8901: fix: `fill_match_arms` hangs on a tuple of large enums r=matklad a=iDawer
+ Lazy computation of missing arms.
+ Convenience function to test lazy computation: `ide_assists::tests::check_assist_unresolved`.
Fixes#8835
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
8813: Get some more array lengths! r=lf- a=lf-
This is built on #8799 and thus contains its changes. I'll rebase it onto master when that one gets merged. It adds support for r-a understanding the length of:
* `let a: [u8; 2] = ...`
* `let a = b"aaa"`
* `let a = [0u8; 4]`
I have added support for getting the values of byte strings, which was not previously there. I am least confident in the correctness of this part and it probably needs some more tests, as we currently have only one test that exercised that part (!).
Fixes#2922.
Co-authored-by: Jade <software@lfcode.ca>
Fix#2922: add unknown length as a condition for a type having unknown.
Incorporate reviews:
* Extract some of the const evaluation workings into functions
* Add fixmes on the hacks
* Add tests for impls on specific array lengths (these work!!! 😁)
* Add tests for const generics (indeed we don't support it yet)
8802: Keep comments and attrs when extracting struct from enum variant r=Veykril a=DropDemBits
Fixes#6730
Still unsure if existing visibilities of fields should be forced to pub (which is what was previously done), or if it's okay to keep it in the extracted struct.
Co-authored-by: DropDemBits <r3usrlnd@gmail.com>
8800: feat: Make "pull assignments up" assist work in more cases r=Jesse-Bakker a=Jesse-Bakker
Fixes#8771
Co-authored-by: Jesse Bakker <github@jessebakker.com>
There's a tension between keeping a well-architectured minimal
orthogonal set of constructs, and providing convenience functions.
Relieve this pressure by introducing an dedicated module for
non-orthogonal shortcuts.
This is inspired by the django.shortcuts module which serves a similar
purpose architecturally.
8591: Remove SyntaxRewriter usage in insert_use in favor of mutable syntax trees r=matklad a=Veykril
Unfortunately changing `insert_use` to not use `SyntaxRewriter` creates a lot of changes since so much relies on that. But on the other hand this should be the biggest usage of `SyntaxRewriter` I believe.
8638: Remove SyntaxRewriter::from_fn r=Veykril a=Veykril
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8620: Remove unnecessary braces for extracted block expression r=Veykril a=brandondong
This change addresses the first bullet point of https://github.com/rust-analyzer/rust-analyzer/issues/7839.
Specifically, when extracting block expressions, remove the unneeded extra braces inside the generated function.
Co-authored-by: Brandon <brandondong604@hotmail.com>
8524: Fix extract function with partial block selection r=matklad a=brandondong
**Reproduction:**
```rust
fn foo() {
let n = 1;
let mut v = $0n * n;$0
v += 1;
}
```
1. Select the snippet ($0) and use the "Extract into function" assist.
2. Extracted function is incorrect and does not compile:
```rust
fn foo() {
let n = 1;
let mut v = fun_name(n);
v += 1;
}
fn fun_name(n: i32) {}
```
3. Omitting the ending semicolon from the selection fixes the extracted function:
```rust
fn fun_name(n: i32) -> i32 {
n * n
}
```
**Cause:**
- When `extraction_target` uses a block extraction (semicolon case) instead of an expression extraction (no semicolon case), the user selection is directly used as the TextRange.
- However, the existing function extraction logic for blocks requires that the TextRange spans from start to end of complete statements to work correctly.
- For example:
```rust
fn foo() {
let m = 2;
let n = 1;
let mut v = m $0* n;
let mut w = 3;$0
v += 1;
w += 1;
}
```
produces
```rust
fn foo() {
let m = 2;
let n = 1;
let mut v = m let mut w = fun_name(n);
v += 1;
w += 1;
}
fn fun_name(n: i32) -> i32 {
let mut w = 3;
w
}
```
- The user selected TextRange is directly replaced by the function call which is now in the middle of another statement. The extracted function body only contains statements that were fully covered by the TextRange and so the `* n` code is deleted. The logic for calculating variable usage and outlived variables for the function parameters and return type respectively search within the TextRange and so do not include `m` or `v`.
**Fix:**
- Only extract full statements when using block extraction. If a user selected part of a statement, extract that full statement.
8527: Switch introduce_named_lifetime assist to use mutable syntax tree r=matklad a=iDawer
This extends `GenericParamsOwnerEdit` trait with `get_or_create_generic_param_list` method
Co-authored-by: Brandon <brandondong604@hotmail.com>
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
8565: Fill match arms assist: add remaining arms for tuple of enums r=iDawer a=iDawer
Fix for #8493
However, the assist is still flaky and does not use `hir_ty::diagnostics::match_check`
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
8467: Adds impl Deref assist r=jhgg a=jhgg
This PR adds a new `generate_deref` assist that automatically generates a deref impl for a given struct field.
Check out this gif:
--
I have a few Q's:
- [x] Should I write more tests, if so, what precisely should I test for?
- [x] I have an inline question on line 65, can someone provide guidance? :)
- [x] I can implement this for `ast::TupleField` too. But should it be a separate assist fn, or should I try and jam both into the `generate_deref`?
- [x] I want to follow this up with an assist on `impl $0Deref for T {` which would automatically generate a `DerefMut` impl that mirrors the Deref as well, however, I could probably use some pointers on how to do that, since I'll have to reach into the ast of `fn deref` to grab the field that it's referencing for the `DerefMut` impl.
Co-authored-by: jake <jh@discordapp.com>
8415: Fix faulty assertion when extracting function with macro call r=matklad a=brandondong
**Reproduction:**
```rust
fn main() {
let n = 1;
let k = n * n;
dbg!(n);
}
```
1. Select the second and third lines of the main function. Use the "Extract into function" code assist.
2. Panic occurs in debug, error is logged in release: "[ERROR ide_assists::handlers::extract_function] assertion failed: matches!(path, ast :: Expr :: PathExpr(_))".
3. Function generates successfully on release where the panic was bypassed.
```rust
fn fun_name(n: i32) {
let k = n * n;
dbg!(n);
}
```
**Cause:**
- The generated function will take `n` as a parameter. The extraction logic needs to search the usages of `n` to determine whether it is used mutably or not. The helper `path_element_of_reference` is called for each usage but the second usage is a macro call and fails the `Expr::PathExpr(_)` match assertion.
- The caller of `path_element_of_reference` does implicitly assume it to be a `Expr::PathExpr(_)` in how it looks at its parent node for determining whether it is used mutably. This logic will not work for macros.
- I'm not sure if there are any other cases besides macros where it could be something other than a `Expr::PathExpr(_)`. I tried various examples and could not find any.
**Fix:**
- Update assertion to include the macro case.
- Add a FIXME to properly handle checking if a macro usage requires mutable access. For now, return false instead of running the existing logic that is tailored for `Expr::PathExpr(_)`'s.
Co-authored-by: Brandon <brandondong604@hotmail.com>
8436: Fix extract function's mutability of variables outliving the body r=matklad a=brandondong
**Reproduction:**
```rust
fn main() {
let mut k = 1;
let mut j = 2;
j += 1;
k += j;
}
```
1. Select the first to third lines of the main function. Use the "Extract into function" code assist.
2. The output is the following which does not compile because the outlived variable `k` is declared as immutable:
```rust
fn main() {
let (k, j) = fun_name();
k += j;
}
fn fun_name() -> (i32, i32) {
let mut k = 1;
let mut j = 2;
j += 1;
(k, j)
}
```
3. We would instead expect the output to be:
```rust
fn main() {
let (mut k, j) = fun_name();
k += j;
}
```
**Fix:**
- Instead of declaring outlived variables as immutable unconditionally, check for any mutable usages outside of the extracted function.
Co-authored-by: Brandon <brandondong604@hotmail.com>
