Using a tuple-like data type with a record-like pattern (or vice versa) produces an opaque diagnostic

[whitequark]

One of the ways to reproduce:

enum X {
    Y(u32)
}

fn main() {
    match X::Y(0) {
        X::Y { data } => ()
    }
}

This results in:

error[E0026]: variant `X::Y` does not have a field named `data`
 --> <anon>:7:16
  |
7 |         X::Y { data } => ()
  |                ^^^^ variant `X::Y` does not have field `data`

error[E0027]: pattern does not mention field `0`
 --> <anon>:7:9
  |
7 |         X::Y { data } => ()
  |         ^^^^^^^^^^^^^ missing field `0`

I think the error message would have been much better if it just said outright that variant X::Y requires a tuple pattern or something like that (I'm not sure what the proper terminology is...)

This happens fairly often during refactoring.

[whitequark]

Here's a much better error message, from a similar case:

error[E0532]: expected unit struct/variant or constant, found tuple variant `kern::DmaRecordStart`
   --> /home/whitequark/Work/artiq-dev/artiq/artiq/firmware/runtime/session.rs:397:14
    |
397 |             &kern::DmaRecordStart => {
    |              ^^^^^^^^^^^^^^^^^^^^ not a unit struct/variant or constant

[petrochenkov]

@whitequark

I think the error message would have been much better if it just said outright that variant X::Y requires a tuple pattern or something like that

The problem is that X::Y doesn't require a tuple pattern, fields of tuple-like things can be accessed by their number.

match X::Y(0) {
    X::Y { 0: data } => ()
}

is legal, as well as

match X::Y(0) {
    X::Y { .. } => ()
}

[whitequark]

The problem is that X::Y doesn't require a tuple pattern, fields of tuple-like things can be accessed by their number.

Then a note could be added.

[petrochenkov]

@whitequark

Then a note could be added.

Could you give a concrete example? (How the note looks and when it is triggered.)

[whitequark]

Something like this...

error[E0026]: variant `X::Y` does not have a field named `data`
 --> <anon>:7:16
  |
7 |         X::Y { data } => ()
  |                ^^^^ variant `X::Y` does not have field `data`

error[E0027]: pattern does not mention field `0`
 --> <anon>:7:9
  |
7 |         X::Y { data } => ()
  |         ^^^^^^^^^^^^^ missing field `0`
note[E????]: trying to match a tuple variant with a struct variant pattern

triggered when the syntactic form of the variant does not match the syntactic form of the pattern

[estebank]

check_struct_pat_fields should check the variant::ctor_kind and provide different output depending on wether it is CtorKind::Fn (Enum::A(1)), CtorKind::Const (Enum::B) or CtorKind::Fictive (Enum::C { a: 1 }). Both errors are emitted from that same method, so specializing the output should be straightforward.

[thombles]

Hi, I'm going to try to fix this now. First time working on the rust code but it makes sense so far!

[estebank]

@thombles, feel free to reach out with any questions you might have!

[thombles]

I've made the change and it looks like this. thombles@8a66362

error[E0026]: variant `X::Y` does not have a field named `data`
  --> src/main.rs:18:16
   |
18 |         X::Y { data } => println!("The data is {}", data)
   |                ^^^^ variant `X::Y` does not have field `data`

error[E0027]: pattern does not mention field `0`
  --> src/main.rs:18:9
   |
18 |         X::Y { data } => println!("The data is {}", data)
   |         ^^^^^^^^^^^^^ missing field `0`
   |
   = note: trying to match a tuple variant with a struct variant pattern

I just have a couple of questions before I put up a PR...

1. Does this cover all the cases that we're worried about?

I see that we already have E0532 for the opposite direction:

error[E0532]: expected tuple struct/variant, found struct variant `A::B`
  --> src/main.rs:23:9
   |
23 |         A::B(n) => println!("The data is {}", n)
   |         ^^^^ did you mean `A::B { /* fields */ }`?

2. Whitequark's mockup had a [E????] suffix on the note. I think this note is associated with the existing error and has no number of its own - is that right?

3. Is this something that should be unit tested? I searched for diagnostic unit tests but couldn't find much.

4. I am getting huge amounts of compilation running ./x.py build src/rustc --stage 1. I've tried playing with optimize true, setting codegen-units to 0 and also --keep-stage 0. The best build time I got after a tiny change in _match.rs was 13 minutes on a ~6yo i7 CPU. Is that normal?

Thanks!

[petrochenkov]

@thombles

Does this cover all the cases that we're worried about?

It should cover this issue.

I think this note is associated with the existing error and has no number of its own - is that right

Correct.

The best build time I got after a tiny change in _match.rs was 13 minutes on a ~6yo i7 CPU. Is that normal?

Yes :(

Is this something that should be unit tested? I searched for diagnostic unit tests but couldn't find much.

I recommend to find a test reporting this error in compile-fail tests and move it into ui test directory (user-interface tests).
The sequence for adding an UI test is

• add an my_test.rs file
• run ./x.py test --stage 1 src/test/ui
• run ./src/test/ui/update-all-references.sh 'build/x86_64-pc-windows-gnu/test/ui/' (using your platform of course, if you are not on windows-gnu), this will generate my_test.stderr files with expected output.

I am getting huge amounts of compilation running ./x.py build src/rustc --stage 1.

./x.py build src/rustc --stage 1 builds more than necessary, ./x.py test --stage 1 src/test/<test-directory> should do the job a bit more quickly.

[thombles]

Thanks @petrochenkov! The existing compile-fail test covered matching a struct so I made a new UI test to exercise this scenario. I've made a PR now.