Non exhaustive reachable patterns lint

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 https://github.com/rust-lang/rust/pull/45394 and there is an open issue https://github.com/rust-lang/rust/issues/84332 for this lint as well as a very early PR https://github.com/rust-lang/rust/pull/86809.

If the attribute is put on the wildcard pattern there is this issue with .. https://github.com/rust-lang/rust/issues/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: https://github.com/rust-lang/rust/pull/86809 lint in usefulness checker commit: https://github.com/DevinR528/rust/commit/df377ca309fd5acf1a3dcdcb90ecdfef9578eafb compiler-team MCP: https://github.com/rust-lang/compiler-team/issues/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.

[jplatte]

The PR has been open for quite a while and was merged a week ago: rust-lang/rust#86809

[scottmcm]

👍 to an opt-in lint for this.

@rustbot second