Proposal

Add a new lint that checks for missing patterns in matches and destructuring assignment of non_exhaustive enums and structs.
This was suggested in the original non_exhaustive PR rust-lang/rust#45394 and there is an open issue rust-lang/rust#84332 for this lint as well as a very early PR rust-lang/rust#86809.

If the attribute is put on the wildcard pattern there is this issue with .. rust-lang/rust#81282.

Example

// crate x
#[non_exhaustive]
pub struct Foo {
    a: u8,
    b: usize,
    c: String,
}

#[non_exhaustive]
pub enum Bar {
    A,
    B,
    C,
}

// crate y
match Bar::A {
    Bar::A => {},
    Bar::B => {},
    #[deny(reachable)] // attribute goes here or on the expresion
    _ => {} // triggers lint "missing Bar::C..."
}

let Foo { 
    a
    b,
    #[warn(reachable)]
    .. // triggers lint "missing field `c`..."
} = structure;

Summary and problem statement

Since the non_exhaustive attribute was introduced it allows crate authors to make normally breaking API changes in a non-breaking way. This lint will warn users of non_exhaustive types when the type changes and they are no longer handling all cases, using the _/.. for more than the NonExhaustive variant/field.

Motivation, use-cases, and solution sketches

Implement this as a lint inside of rustc_lint or implement the lint as part of the usefulness checker here

Links and related work

WIP PR: rust-lang/rust#86809
lint in usefulness checker commit: DevinR528/rust@df377ca
compiler-team MCP: rust-lang/compiler-team#445
zulip compiler/major changes: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Non.20exhaustive.20reachable.20patterns.20lint.20compiler-team.23445

Initial people involved

I have started a WIP PR and plan to finish this as part of my GSoC project.

• Owner, if known: ?
• Liaison

What happens now?

This issue is part of the lang-team initiative process. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open proposals in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.