Tracking issue for RFC 1872: `exhaustive_patterns` feature

[kennytm]

This tracks the exhaustive_patterns feature which allows uninhabited variant to be omitted
(bug report: #12609; relevant RFC: rust-lang/rfcs#1872).

fn safe_unwrap<T>(x: Result<T, !>) -> T {
    match x {
        Ok(y) => y,
    }
}

• Implementation (separated out from never_type in Stabilise feature(never_type). Introduce feature(exhaustive_patterns) #47630)
• blocking issue: Incorrect "unreachable match arm" warning  #117119
• Stabilization

[varkor]

The lack of this feature has unintuitive consequences (e.g. #55123). I haven't seen any problems arising from it either.

cc @rust-lang/lang: could this be put forward for stabilisation?

[nikomatsakis]

@varkor I am mildly reluctant until we have agreed upon the story around "never patterns" -- but I suppose given a sufficiently conservative definition of "uninhabited pattern" I'd be all right with it. Do you think you could write-up a "stabilization report" that includes examples of the tests we have and also documents the limits of what sorts of things would be considered uninhabited in stable code?

(That said, I think "never patterns" gives us a path forward that addresses my concerns around aggressive uninhabited definitions, by just turning the "ambiguous" cases into lints in the presence of unsafe code. I'd be happier though if we had an RFC on the topic.)

[nikic]

The exhaustive_patterns feature currently seems to have a pretty big performance issue. Having perf top running while compiling librustc, I noticed that it spends an unreasonable amount of time inside ty::inhabitedness. Disabling exhaustive_patterns (it's not actually used in librustc/librustc_mir) shaved off ~30s (of 12min total) from stage1 compiler artifact compile time (in a totally unscientific benchmark, so take with a grain of salt).

I would expect that this issue will resolve itself if there is a consensus to go with references never being uninhabited (ref #54125 (comment)), as the reference handling is what I believe makes this expensive (not looking through references both reduces the amount of types we need to look at, and allows us to drop the expensive hashmap and nested hashsets used to avoid unbounded recursion). If the consensus goes in the other direction, then this code should probably be optimized a bit prior to stabilization of the feature.

[jonas-schievink]

cc #51221, using this feature in let-bindings seems to ICE unless the never_type feature is also enabled