Fix autoimport does nothing when importing trait that is as _ imports
Potentially fixes#15128
There are two cases of imports:
1. With simple path
2. With use tree list (or say complex path).
On deeper inspection, the [`recursive_merge`](994df3d6a3/crates/ide-db/src/imports/merge_imports.rs (L87)) function (called by [`try_merge_trees_mut`)](994df3d6a3/crates/ide-db/src/imports/merge_imports.rs (L69)) is meaningful only in the case of complex path (i.e when the UseTree contains a UseTreeList).
The [`recursive_merge`](994df3d6a3/crates/ide-db/src/imports/merge_imports.rs (L87)) function has [match with `Ok` arm](994df3d6a3/crates/ide-db/src/imports/merge_imports.rs (L106)), that is only executed when both LHS and RHS has `PathSegment` with same `NameRef`. The removal of underscore is implemented in this arm in the case of complex path.
For simple paths, the underscore is removed by checking if both LHS and RHS are simple paths and if their `Path` is same (the check is done [here](994df3d6a3/crates/ide-db/src/imports/merge_imports.rs (L74))) and remove the underscore if one is found (I made an assumption here that RHS will always be what rust-analyzer suggests to import, because at this point I'm not sure how to remove underscore with help of `ted::replace`).
feat: Bool to enum assist
This adds the `bool_to_enum` assist, which converts the type of boolean local variables, fields, constants and statics to a new `enum` type, making it easier to distinguish the meaning of `true` and `false` by renaming the variants.
Closes#14779
Fix inlining closures from local variables and functions
Previously, closures were not properly wrapped in parentheses for the `inline_local_variable` and `inline_call` assists, leading to the usages being incorrectly called:
```rust
fn main() {
let $0f = || 2;
let _ = f();
}
```
Now produces:
```rust
fn main() {
let _ = (|| 2)();
}
```
Instead of:
```rust
fn main() {
let _ = || 2();
}
```
Closes#15639
Give `unmerge_use` a label explaining what it will affect.
When I'm trying to clean up `use`s, I often feel uncertain about what exactly the effects of choosing an assist will be. This PR makes a small improvement to that by giving “Unmerge use” a label which names the root of the tree that it's going to move, when one exists.
There is no test because I didn't see, among the test helpers, a way to assert on the assist label (as opposed to filtering on it). However, I did test the change manually.
I looked into making a similar change to “Merge imports”, but that is considerably trickier.
VSCode behaves strangely, allowing to navigate into label location, but
not allowing to apply hint's text edit, after hint is resolved.
See https://github.com/microsoft/vscode/issues/193124 for details.
For now, stub hint resolution for VSCode specifically.
Switch to in-tree rustc dependencies with a cfg flag
We can use this flag to detect and prevent breakages in rustc CI. (see #14846 and #15569)
~The `IN_RUSTC_REPOSITORY` is just a placeholder. Is there any existing cfg flag that rustc CI sets?~
fix: Don't skip closure captures after let-else
As I understand that `return` was left there by accident. It caused capture analysis to skip the rest of the block after a let-else, and then missed captures caused incorrect results in borrowck, closure hints, layout calculation, etc.
Fixes#15623
I didn't understand why I using the example from #15623 as-is doesn't work - I don't get the warnings unless I remove the `call_me()` call, even on the same commit as my own RA version which does show those warnings.
Field shorthand overwritten in promote local to const assist
Currently, running `promote_local_to_const` on the following:
```rust
struct Foo {
bar: usize,
}
fn main() {
let $0bar = 0;
let foo = Foo { bar };
}
```
Results in:
```rust
struct Foo {
bar: usize,
}
fn main() {
const BAR: usize = 0;
let foo = Foo { BAR };
}
```
But instead should be something like:
```rust
struct Foo {
bar: usize,
}
fn main() {
const BAR: usize = 0;
let foo = Foo { bar: BAR };
}
```
ide : Disallow renaming of non-local items
fixes#14850 . This makes me wonder , why stop at structs and not do the same for other ADTs? Would be happy to add them too if nothing speaks against it.
