unneeded_struct_pattern triggers when matching 3rd-party crate's variant with { .. }

[obi1kenobi]

Summary

Turning a unit variant into a struct or tuple variant is a major breaking change.

Sometimes, downstream code that consumes an upstream crate's enum variants might care only about "which variant was chosen" and doesn't care whether the variant might (now or in the future) have associated data. In such a situation, I feel it isn't unreasonable to use MyEnum::MyVariant { .. } syntax regardless of whether MyVariant is a unit or not.

Of course, MyEnum::MyVariant is sufficient syntax if the variant is a unit. But in this case, we don't "own" the MyEnum type, and changes in the variant kind aren't up to us. Adding the { .. } is explicit about wishing to be future-proof to changes in the variant kind, so I think it shouldn't trigger a lint — especially not an on-by-default lint.

Lint Name

unneeded_struct_pattern

Reproducer

I tried this code:

fn example(kind: &cargo_metadata::TargetKind) {
    match kind {
        cargo_metadata::TargetKind::Lib { .. } => todo!(),
        _ => todo!(),
    }
}

I saw this happen:

warning: struct pattern is not needed for a unit variant
   --> src/lib.rs:12:40
    |
 12 |         cargo_metadata::TargetKind::Lib { .. } => todo!(),
    |                                        ^^^^^^^ help: remove the struct pattern
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unneeded_struct_pattern
    = note: `#[warn(clippy::unneeded_struct_pattern)]` on by default

I expected to see this happen:

No lint reported. My code is saying "we don't care if this 3rd-party crate's variant becomes a tuple or struct variant in the future" and attempting to remain resilient to a potential future breaking change.

Version

rustc 1.86.0-nightly (bef3c3b01 2025-02-04)
binary: rustc
commit-hash: bef3c3b01f690de16738b1c9f36470fbfc6ac623
commit-date: 2025-02-04
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.7

Additional Labels

No response