Tracking issue for RFC 1872: exhaustive_patterns feature

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

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?

@varkor

@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.)

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.

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

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.

It is now the case that "references never are uninhabited", at least as far as is_ty_uninhabited_from is concerned. Is the performance issue still there?
Otherwise, I expect that making is_ty_uninhabited_from into a query or something would significantly improve perf, because match checking repeatedly calls it on the same type and its subcomponents.

Is the performance issue still there?

I suspect this requires some investigation. (Perhaps it would be sufficient to open a PR enabling the feature and do a perf run.)

Rollup merge of rust-lang#122792 - Nadrieril:stabilize-min-exh-pats2,…

Auto merge of rust-lang#122792 - Nadrieril:stabilize-min-exh-pats2, r…

min_exhaustive_patterns is now stabilized! This allows omitting empty arms when matching by-value. The other cases (behind a reference, a pointer, or inside an union) still require exhaustive_patterns.

Auto merge of #122792 - Nadrieril:stabilize-min-exh-pats2, r=fee1-dead

Is this code supposed to work in the future?

struct A(Box<A>);
fn f(x: A) -> ! {
  match x {}

// Or this:
  match x {
    !,
  }
}

A is uninhibited in safe code, so theoretically the code above should compile. Is this planned? (Note: I don't need this feature, this is not feature request, it is just pure curiosity.)

No, I am not aware of any plans trying to reason about cyclic types.

Rollup merge of rust-lang#143414 - dianne:box-usefulness-cleanup, r=N…

Unrolled build for #143414

Auto merge of #122792 - Nadrieril:stabilize-min-exh-pats2, r=fee1-dead

Navigation Menu

Repository navigation

Tracking issue for RFC 1872: `exhaustive_patterns` feature #51085

49 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for RFC 1872: exhaustive_patterns feature #51085

Description

Activity

varkor commented on Oct 16, 2018

nikomatsakis commented on Oct 16, 2018

nikic commented on Oct 26, 2018

jonas-schievink commented on May 13, 2019

Nadrieril commented on Nov 17, 2020

varkor commented on Nov 19, 2020

49 remaining items

Nadrieril commented on Aug 10, 2024

safinaskar commented on Oct 16, 2024

RalfJung commented on Oct 16, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for RFC 1872: `exhaustive_patterns` feature #51085