Attributes are silently ignored on .. (rest) in struct pattern (StructPatternEtCetera)

[Aaron1011]

The following code compiles successfully:

struct Foo {
    val: bool
}

fn main() {
    let data = Foo { val: true };
    match data {
        Foo { #[missing_attr] #[cfg(FALSE)] .. } => {}
    }
}

However, placing attributes on a normal field pattern:

struct Foo {
    val: bool
}

fn main() {
    let data = Foo { val: true };
    match data {
        Foo { #[missing_attr] #[cfg(FALSE)] val } => {}
    }
}

produces the following error:

error[E0027]: pattern does not mention field `val`
 --> src/main.rs:8:9
  |
8 |         Foo { #[missing_attr] #[cfg(FALSE)] val } => {}
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing field `val`
  |
help: include the missing field in the pattern
  |
8 |         Foo { val } => {}
  |             ^^^^^^^
help: if you don't care about this missing field, you can explicitly ignore it
  |
8 |         Foo { .. } => {}
  |             ^^^^^^

error: aborting due to previous error

We should either handle attributes consistently across field patterns and .. patterns, or emit an error when any attributes are present on .. patterns. This is technically a breaking change, but there's precedent here (we've made misplaced #[inline] attributes into hard errors).

[petrochenkov]

either handle attributes consistently across field patterns and .. patterns

Technically .. is not a pattern in this context (unlike .. in other contexts), it's a part of the struct pattern syntax, so attributes are supposed to be syntactically rejected on it.

[Aaron1011]

The reference states that .. (StructPatternEtCetera) supports outer attributes: https://doc.rust-lang.org/reference/patterns.html#struct-patterns. Should it be updated?

[petrochenkov]

Actually disregard my comment, it's true that .. is not a pattern in this context, but it doesn't matter - attributes on regular patterns are not supported at all.
So whether attributes should be supported on .. in struct patterns is a standalone question.

I'd say they should not despite what the reference says.
The equivalent syntax is not supported in expressions

struct S {}

fn main() {
    let s = S {};
    let z = S { #[nonexistent] ..s }; // error: expected identifier, found `..`
}

and we should be able to remove it from patterns too because it's not implemented correctly (the attributes on .. are not resolved/expanded).

If someone provides good motivation, then it can always be added in the future.

[jplatte]

I have a use case for this: Allowing exhaustive matching of conceptually non-exhaustive structs, like what syn does for enums:

let Foo {
    field_a,
    field_b,
    field_c,
    #[cfg(test)]
    __test_exhaustive: _,
    #[cfg(not(test))]
    ..
} = foo;

or alternatively with the lint suggested in #44109 (comment):

let Foo {
    field_a,
    field_b,
    field_c,
    // could also be warn(reachable) + `-D warnings` in CI
    #[cfg_attr(test, deny(reachable))]
    ..
} = foo;

With that, you have an automated way of being notified (through test failure) when a struct got additional fields without failing compilation entirely, in the second case for anything that's #[non_exhaustive], without help from the library defining the type.

[Nadrieril]

@jplatte I believe the non_exhaustive_omitted_patterns lint handles your case without attributes.

[jplatte]

Heh yes, I'm well aware of it ^^
I still would have found that a #[warn(reachable)] lint would have been more obvious when reading, but given how things turned out instead, that use case is not really valid anymore, so just forbidding attributes on .. in struct patterns might be the better way forward.

[Nadrieril]

Yeahh, I opted against deny(reachable) for consistency in nested cases; I did not give much thought to readability