New lint: warn againt matching on all-private struct

[Kixunil]

What it does

Firstly a disclaimer: I think this belongs to the compiler rather than clippy but putting it into clippy first is probably a good first step as it could allow experimentation with minimal annoyance. Feel free to close if you disagree.

When the code matches on a struct with all fields private or an empty struct with #[non_exhaustive] attribute using Foo { .. } syntax clippy warns against this because it breaks future-proofing of the type which library authors may not be aware of.
Disussion: https://internals.rust-lang.org/t/disallow-matching-on-all-private-structs/15993

Lint Name

match_fully_private_struct

Category

suspicious

Advantage

The code will not break if the library changes the type from struct to enum.

Drawbacks

• Can FP on v @ Foo { .. }, but perhaps there's a way to improve the code here too? It could be also whitelisted.
• A crate author might have meant to commit to the type staying a struct. Maybe this could be mitigated by having an attribute on the struct definition to (dis)allow it. (Is such thing possible in clippy?)

Example

mod foo {
    pub struct Foo {
        value: u8,
    }

    pub fn create() -> Foo {
        Foo { value: 42 }
    }
}

fn main() {
    let foo::Foo { .. } = foo::create();
}

Could be written as:

// mod foo omitted for brevity since it's the same as above

fn main() {
    let _: foo::Foo = foo::create();
}

[camsteffen]

I think it is equally lintable if the fields are public. Could call it struct_patterns_without_bindings.

[Kixunil]

Yeah, maybe. The case with all-private fields is more serious and I think the message should explain incompatibility in that case.

[camsteffen]

I see. Yeah we should pursue a rustc change first. I'm wondering if we could "Allow matching with Name { .. } on enums".