Non exhaustive reachable patterns lint

[DevinR528]

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.

[rustbot]

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.

[scottmcm]

👍 to an opt-in lint for this.

@rustbot second

[nikomatsakis]

I approve.

[DevinR528]

Is it important that the initial comment reflect the merged state of this lint? It was renamed to non_exhaustive_omitted_patterns and the attribute can go either on the wildcard for enum matches or on the expression which works for structs and enums in pattern position.

[nikomatsakis]

Discussed in meeting today: We are on board with this lint but don't feel there is a need for an initiative. The implementation work has been ongoing. Please cc @rust-lang/lang on the PR itself (we look forward to it). Thanks!

[jplatte]

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