feat: Add incorrect case diagnostics for enum variant fields and all variables/params
Updates the incorrect case diagnostic to check:
1. Fields of enum variants. Example:
```rust
enum Foo {
Variant { nonSnake: u8 }
}
```
2. All variable bindings, instead of just let bindings and certain match arm patters. Examples:
```rust
match 1 { nonSnake => () }
match 1 { nonSnake @ 1 => () }
match 1 { nonSnake1 @ nonSnake2 => () } // slightly cursed, but these both introduce new
// bindings that are bound to the same value.
const ONE: i32 = 1;
match 1 { nonSnake @ ONE } // ONE is ignored since it is not a binding
match Some(1) { Some(nonSnake) => () }
struct Foo { field: u8 }
match (Foo { field: 1 } ) {
Foo { field: nonSnake } => ();
}
struct Foo { nonSnake: u8 } // diagnostic here, at definition
match (Foo { nonSnake: 1 } ) { // no diagnostic here...
Foo { nonSnake } => (); // ...or here, since these are not where the name is introduced
}
for nonSnake in [] {}
struct Foo(u8);
for Foo(nonSnake) in [] {}
```
3. All parameter bindings, instead of just top-level binding identifiers. Examples:
```rust
fn func(nonSnake: u8) {} // worked before
struct Foo { field: u8 }
fn func(Foo { field: nonSnake }: Foo) {} // now get diagnostic for nonSnake
```
This is accomplished by changing the way binding identifier patterns are filtered:
- Previously, all binding idents were skipped, except a few classes of "good" binding locations that were checked.
- Now, all binding idents are checked, except field shorthands which are skipped.
Moving from a whitelist to a blacklist potentially makes the analysis more brittle:
If new pattern types are added in the future where ident pats don't introduce new names, then they may incorrectly create diagnostics.
But the benefit of the blacklist approach is simplicity: I think a whitelist approach would need to recursively visit patterns to collect renaming candidates?
Trigger VSCode to rename after extract variable assist is applied
When the user applies the "Extract Variable" assist, the cursor is
positioned at the newly inserted variable. This commit adds a command
to the assist that triggers the rename action in VSCode. This way, the
user can quickly rename the variable after applying the assist.
Fixes part of: #17579https://github.com/user-attachments/assets/4cf38740-ab22-4b94-b0f1-eddd51c26c29
I haven't yet looked at the module or function extraction assists yet.
When the user applies the "Extract Variable" assist, the cursor is
positioned at the newly inserted variable. This commit adds a command
to the assist that triggers the rename action in VSCode. This way, the
user can quickly rename the variable after applying the assist.
Fixes part of: #17579
feat: do not add new enum if it already exists
## Summary
This PR introduces a check for the existence of another enum within the current scope, and if it exist, we skip `add_enum_def`.
## Why?
Currently, when using the `bool_to_enum` assist more than once, it is possible to add multiple enum definitions. For example, the following snippet,
```rs
#[derive(PartialEq, Eq)]
enum Bool {
True,
False,
}
fn main() {
let a = Bool::True;
let b = true;
println!("Hello, world!");
}
```
will be transformed into,
```rs
#[derive(PartialEq, Eq)]
enum Bool {
True,
False,
}
#[derive(PartialEq, Eq)]
enum Bool {
True,
False,
}
fn main() {
let a = Bool::True;
let b = Bool::True;
println!("Hello, world!");
}
```
This can be annoying for users to clean up.
Add `f16` and `f128` support
Adds `f16` and `f128` support, using the `rustc_apfloat` library (also used by `rustc`) for parsing/arithmetic/displaying since the types aren't stable yet so can't be used by rust-analyzer itself.
Issue: #17451
feat: add inlay hints for generic parameters
fixes#11091
By default, only hints for const generic parameters are shown, and this can be configured through `rust-analyzer.inlayHints.genericParameterHints.enable`.
Probably needs more testing.
Make casts of pointers to trait objects stricter
This is an attempt to `fix` https://github.com/rust-lang/rust/issues/120222 and https://github.com/rust-lang/rust/issues/120217.
This is done by adding restrictions on casting pointers to trait objects.
Before this PR the rules were as follows:
> When casting `*const X<dyn A>` -> `*const Y<dyn B>`, principal traits in `A` and `B` must refer to the same trait definition (or no trait).
With this PR the rules are changed to
> When casting `*const X<dyn Src>` -> `*const Y<dyn Dst>`
> - if `Dst` has a principal trait `DstP`,
> - `Src` must have a principal trait `SrcP`
> - `dyn SrcP` and `dyn DstP` must be the same type (modulo the trait object lifetime, `dyn T+'a` -> `dyn T+'b` is allowed)
> - Auto traits in `Dst` must be a subset of auto traits in `Src`
> - Not adhering to this is currently a FCW (warn-by-default + `FutureReleaseErrorReportInDeps`), instead of an error
> - if `Src` has a principal trait `Dst` must as well
> - this restriction will be removed in a follow up PR
This ensures that
1. Principal trait's generic arguments match (no `*const dyn Tr<A>` -> `*const dyn Tr<B>` casts, which are a problem for [#120222](https://github.com/rust-lang/rust/issues/120222))
2. Principal trait's lifetime arguments match (no `*const dyn Tr<'a>` -> `*const dyn Tr<'b>` casts, which are a problem for [#120217](https://github.com/rust-lang/rust/issues/120217))
3. No auto traits can be _added_ (this is a problem for arbitrary self types, see [this comment](https://github.com/rust-lang/rust/pull/120248#discussion_r1463835350))
Some notes:
- We only care about the metadata/last field, so you can still cast `*const dyn T` to `*const WithHeader<dyn T>`, etc
- The lifetime of the trait object itself (`dyn A + 'lt`) is not checked, so you can still cast `*mut FnOnce() + '_` to `*mut FnOnce() + 'static`, etc
- This feels fishy, but I couldn't come up with a reason it must be checked
The diagnostics are currently not great, to say the least, but as far as I can tell this correctly fixes the issues.
cc `@oli-obk` `@compiler-errors` `@lcnr`
Add an option to use "::" for the external crate prefix.
Fixes#11823 .
Hi I'm very new to rust-analyzer and not sure how the review process are. Can somebody take a look at this PR? thanks!
