Enum struct field names with leading underscore cause compiler errors

[DavidAntliff]

Please consider this example:

pub struct Data {}

#[subenum(Bar)]
pub enum Foo {
    #[subenum(Bar)]
    Baz { data: Data },
}

This compiles, as expected.

Consider if the data field of the Baz struct variant is renamed to _data, with a leading underscore:

pub struct Data {}

#[subenum(Bar)]
pub enum Foo {
    #[subenum(Bar)]
    Baz { _data: Data },
}

The compiler now issues a set of errors:

error[E0026]: variant `Bar::Baz` does not have a field named `data`
  --> src/model/mod.rs:57:11
   |
57 |     Baz { _data: Data },
   |           ^^^^^ variant `Bar::Baz` does not have this field

error: pattern requires `..` due to inaccessible fields
  --> src/model/mod.rs:53:1
   |
53 | #[subenum(Bar)]
   | ^^^^^^^^^^^^^^^
   |
   = note: this error originates in the attribute macro `subenum` (in Nightly builds, run with -Z macro-backtrace for more info)
help: ignore the inaccessible and unused fields
   |
57 |     Baz { _data, ..: Data },
   |                ++++

error[E0559]: variant `Foo::Baz` has no field named `data`
  --> src/model/mod.rs:57:11
   |
57 |     Baz { _data: Data },
   |           ^^^^^ `Foo::Baz` does not have this field
   |
   = note: all struct fields are already assigned

error[E0026]: variant `Foo::Baz` does not have a field named `data`
  --> src/model/mod.rs:57:11
   |
57 |     Baz { _data: Data },
   |           ^^^^^ variant `Foo::Baz` does not have this field

error[E0559]: variant `Bar::Baz` has no field named `data`
  --> src/model/mod.rs:57:11
   |
57 |     Baz { _data: Data },
   |           ^^^^^ `Bar::Baz` does not have this field
   |
   = note: all struct fields are already assigned

Something isn't quite right here.

What are the use-cases for naming a field like this? One is when creating "uninstantiable" enum variants, for example:

pub struct Private {
    _private: (),
}

#[subenum(Bar)]
pub enum Foo {
    #[subenum(Bar)]
    Baz { _private: Private },
}

The convention is to use a leading underscore for such private fields, but in this case it is not possible. The workaround is trivial though - just use private rather than _private as the field name.

So this is a minor issue, but perhaps surprising when encountered for the first time.

subenum = "1.1.2"