-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-suggestion-diagnosticsArea: Suggestions generated by the compiler applied by `cargo fix`Area: Suggestions generated by the compiler applied by `cargo fix`C-bugCategory: This is a bug.Category: This is a bug.D-incorrectDiagnostics: A diagnostic that is giving misleading or incorrect information.Diagnostics: A diagnostic that is giving misleading or incorrect information.D-invalid-suggestionDiagnostics: A structured suggestion resulting in incorrect code.Diagnostics: A structured suggestion resulting in incorrect code.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
I tried this code:
enum Foo {
Bar(i32),
}
fn main() {
let f = Foo::Bar(3);
// compiler error that could be clearer:
if let Foo::Bar{} = f {
println!("hello");
}
// better suggestion for the compiler error:
if let Foo::Bar(_) = f {
println!("goodbye");
}
}
playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4984d4711270142a41aa9a0e77eb82d8
I expected to see this happen:
A suggestion to use a match pattern such as:
if let Foo::Bar(val) = f {
or
if let Foo::Bar(_) = f {
Instead, this happened:
error[E0027]: pattern does not mention field `0`
--> src/main.rs:9:11
|
9 | if let Foo::Bar{} = f {
| ^^^^^^^^^^ missing field `0`
|
help: include the missing field in the pattern
|
9 | if let Foo::Bar { 0 } = f {
| ^^^^^
help: if you don't care about this missing field, you can explicitely ignore it
|
9 | if let Foo::Bar { .. } = f {
| ^^^^^^
gbbosak and LeSeulArtichaut
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-suggestion-diagnosticsArea: Suggestions generated by the compiler applied by `cargo fix`Area: Suggestions generated by the compiler applied by `cargo fix`C-bugCategory: This is a bug.Category: This is a bug.D-incorrectDiagnostics: A diagnostic that is giving misleading or incorrect information.Diagnostics: A diagnostic that is giving misleading or incorrect information.D-invalid-suggestionDiagnostics: A structured suggestion resulting in incorrect code.Diagnostics: A structured suggestion resulting in incorrect code.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
GuillaumeGomez commentedon Dec 3, 2020
Well, you can in fact do:
PatchMixolydic commentedon Dec 4, 2020
Incidentally, placing just an identifier in the braces (without the field name) produces a clearer diagnostic, which may also be useful in the case presented in the report:
Using
0
directly as the suggestion in the report suggests (without binding the field to a valid identifier like in the above comment) causes an error, as one might expect:I'd posit that using the struct syntax to bind values from a tuple variant would be rather strange/unexpected, so the diagnostics should probably push towards the use of the tuple syntax instead. I'm only one person, though, and I'm far from an expert on these matters.
LeSeulArtichaut commentedon Dec 7, 2020
Also note that this diagnostic gets emitted for any tuple struct, not just enum variants:
LeSeulArtichaut commentedon May 22, 2021
This seems to be fixed now:
Dylan-DPC commentedon Apr 15, 2023
Closing this as fixed