Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions when a single-field enum variant pattern is needed #94942

Open
kpreid opened this issue Mar 14, 2022 · 0 comments
Open

Suggestions when a single-field enum variant pattern is needed #94942

kpreid opened this issue Mar 14, 2022 · 0 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix`. C-enhancement Category: An issue proposing an enhancement or a PR with one. D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@kpreid
Copy link
Contributor

kpreid commented Mar 14, 2022

Beginners are often confused by the pattern where a set of types are combined using an enum, especially when the name of the enum variant is the same as the name of the variant's field's type. Even knowing how it works, I've myself forgotten to write out enum variant patterns containing struct patterns where they are needed. It would be useful if the compiler could give suggestions that understand this mistake.

Given the following code:

enum Foo {
    Bar(Bar),
}
struct Bar {
    x: i32,
}

fn oops_1(f: Foo) {
    match f {
        Foo::Bar { x } => todo!()
    }
}
fn oops_2(f: Foo) {
    match f {
        Bar { x } => todo!()
    }
}

The current output is:

error[E0769]: tuple variant `Foo::Bar` written as struct variant
  --> src/lib.rs:10:9
   |
10 |         Foo::Bar { x } => todo!()
   |         ^^^^^^^^^^^^^^
   |
help: use the tuple variant pattern syntax instead
   |
10 |         Foo::Bar(x) => todo!()
   |                 ~~~

error[E0308]: mismatched types
  --> src/lib.rs:15:9
   |
14 |     match f {
   |           - this expression has type `Foo`
15 |         Bar { x } => todo!()
   |         ^^^^^^^^^ expected enum `Foo`, found struct `Bar`

The compiler could instead recognize these cases, and produce the suggestion Foo::Bar(Bar { x }) => as well as a message specific to the situation:

  • A variant pattern with fields which do not match the variant, but do match the fields of the variant's sole field.
  • A pattern not of enum type where an enum pattern is expected, but the enum has a variant whose sole field is of the pattern's type.

@rustbot label +A-suggestion-diagnostics +C-enhancement +D-newcomer-roadblock

@kpreid kpreid added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 14, 2022
@rustbot rustbot added A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix`. C-enhancement Category: An issue proposing an enhancement or a PR with one. D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. labels Mar 14, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Mar 29, 2022
…-obk

Suggest wrapping patterns in enum variants

Structured suggestion to wrap a pattern in a single-field enum or struct:

```diff
 struct A;

 enum B {
   A(A),
 }

 fn main(b: B) {
   match b {
-    A => {}
+    B::A(A) => {}
   }
 }
```

Half of rust-lang#94942, the other half I'm not exactly sure how to fix.

Also includes two drive-by changes (that I am open to splitting out into another PR, but thought they could be rolled up into this one):
- 07776c1: Makes sure not to suggest wrapping if it doesn't have tuple field constructor (i.e. has named fields)
- 8f2bbb18fd53e5008bb488302dbd354577698ede: Also suggest wrapping expressions in a tuple struct (not just enum variants)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix`. C-enhancement Category: An issue proposing an enhancement or a PR with one. D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants