Stabilize min_exhaustive_patterns

[Nadrieril]

Stabilisation report

I propose we stabilize the min_exhaustive_patterns language feature.

With this feature, patterns of empty types are considered unreachable when matched by-value. This allows:

enum Void {}
fn foo() -> Result<u32, Void>;

fn main() {
  let Ok(x) = foo();
  // also
  match foo() {
    Ok(x) => ...,
  }
}

This is a subset of the long-unstable exhaustive_patterns feature. That feature is blocked because omitting empty patterns is tricky when not matched by-value. This PR stabilizes the by-value case, which is not tricky.

The not-by-value cases (behind references, pointers, and unions) stay as they are today, e.g.

enum Void {}
fn foo() -> Result<u32, &Void>;

fn main() {
  let Ok(x) = foo(); // ERROR: missing `Err(_)`
}

The consequence on existing code is some extra "unreachable pattern" warnings. This is fully backwards-compatible.

Comparison with today's rust

This proposal only affects match checking of empty types (i.e. types with no valid values). Non-empty types behave the same with or without this feature. Note that everything below is phrased in terms of match but applies equallly to if let and other pattern-matching expressions.

To be precise, a visibly empty type is:

• an enum with no variants;
• the never type !;
• a struct with a visible field of a visibly empty type (and no #[non_exhaustive] annotation);
• a tuple where one of the types is visibly empty;
• en enum with all variants visibly empty (and no #[non_exhaustive] annotation);
• a [T; N] with N != 0 and T visibly empty;
• all other types are nonempty.

(An extra change was proposed below: that we ignore #[non_exhaustive] for structs since adding fields cannot turn an empty struct into a non-empty one)

For normal types, exhaustiveness checking requires that we list all variants (or use a wildcard). For empty types it's more subtle: in some cases we require a _ pattern even though there are no valid values that can match it. This is where the difference lies regarding this feature.

Today's rust

Under today's rust, a _ is required for all empty types, except specifically: if the matched expression is of type ! (the never type) or EmptyEnum (where EmptyEnum is an enum with no variants), then the _ is not required.

let foo: Result<u32, !> = ...;
match foo {
    Ok(x) => ...,
    Err(_) => ..., // required
}
let foo: Result<u32, &!> = ...;
match foo {
    Ok(x) => ...,
    Err(_) => ..., // required
}
let foo: &! = ...;
match foo {
    _ => ..., // required
}
fn blah(foo: (u32, !)) {
    match foo {
        _ => ..., // required
    }
}
unsafe {
    let ptr: *const ! = ...;
    match *ptr {} // allowed
    let ptr: *const (u32, !) = ...;
    match *ptr {
        (x, _) => { ... } // required
    }
    let ptr: *const Result<u32, !> = ...;
    match *ptr {
        Ok(x) => { ... }
        Err(_) => { ... } // required
    }
}

After this PR

After this PR, a pattern of an empty type can be omitted if (and only if):

• the match scrutinee expression has type ! or EmptyEnum (like before);
• or the empty type is matched by value (that's the new behavior).

In all other cases, a _ is required to match on an empty type.

let foo: Result<u32, !> = ...;
match foo {
    Ok(x) => ..., // `Err` not required
}
let foo: Result<u32, &!> = ...;
match foo {
    Ok(x) => ...,
    Err(_) => ..., // required because `!` is under a dereference
}
let foo: &! = ...;
match foo {
    _ => ..., // required because `!` is under a dereference
}
fn blah(foo: (u32, !)) {
    match foo {} // allowed
}
unsafe {
    let ptr: *const ! = ...;
    match *ptr {} // allowed
    let ptr: *const (u32, !) = ...;
    match *ptr {
        (x, _) => { ... } // required because the matched place is under a (pointer) dereference
    }
    let ptr: *const Result<u32, !> = ...;
    match *ptr {
        Ok(x) => { ... }
        Err(_) => { ... } // required because the matched place is under a (pointer) dereference
    }
}

Documentation

The reference does not say anything specific about exhaustiveness checking, hence there is nothing to update there. The nomicon does, I opened rust-lang/nomicon#445 to reflect the changes.

Tests

The relevant tests are in tests/ui/pattern/usefulness/empty-types.rs.

Unresolved Questions

None that I know of.

[rustbot]

r? @cjgillot

rustbot has assigned @cjgillot.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Note that this feature *does* consider (some) structs with an uninhabited field as uninhabited, see the PR description. There seems to be a misunderstanding? Also crucially, "by value" excludes the contents of unions.

[scottmcm]

Thank you, @RalfJung, you're right that I misread it. Updated my FCP text to include not-non_exhaustive structs with a visibly-empty field. (I do think that's a good thing to have too, just had thought it wasn't implemented because I misread #122792 (comment) .)

[jplatte]

Quick thought, clippy nowadays takes rust-version into account for many lints. Does the compiler do the same, in particular for the lint for unreachable match arms? Would this be an easy addition, if it's not a thing yet?

[Nadrieril]

I didn't write it explicitly but arrays and tuples can also be empty, in the expected way. I'll add it to the OP.

[RalfJung]

For arrays I hope that [!; 0] is considered non-empty as it should? Please make sure we have a test for that.

[Nadrieril]

To my own shock I did not find a test for that :') There's one now.

[bors]

☔ The latest upstream changes (presumably #122225) made this pull request unmergeable. Please resolve the merge conflicts.

[Nadrieril]

I stumbled upon #108993 which changes how we compute inhabitedness. If I follow correctly, this would mean we don't look into inferred types to determine inhabitedness. So the following, which works today (play), would error instead:

#![feature(min_exhaustive_patterns)]
#![allow(unused)]

fn infer<F: FnOnce() -> R, R>(_: Result<bool, R>) {}

enum Void {}
fn with_void() {
    let mut x = Ok(true);
    match x {
        Ok(_) => {}
    }
    infer::<fn() -> Void, _>(x)
}

Hence #108993 becomes a breaking change. We thus need to decide whether to accept #108993 before we stabilize min_exhaustive_patterns.

[cjgillot]

I'd reason the other way around: stabilize this PR and adapt #108993 on those grounds. #108993 is a bit too eager to declare some code unreachable, which is an issue in itself.

[Nadrieril]

Would it make sense to put #108993 under this feature gate?

[traviscross]

It's interesting that we now have a cycle. #108993 was blocked on the stabilization of exhaustive patterns. But to stabilize exhaustive patterns, we need to land #108993 or decide not to do so (completing the cycle...).

[bors]

☔ The latest upstream changes (presumably #123762) made this pull request unmergeable. Please resolve the merge conflicts.

[Nadrieril]

Alright, having chatted with @cjgillot and @WaffleLapkin I no longer think it would make sense for exhaustiveness to infer less than it does today. Normalization is important to patterns behaving consistently. My concern is resolved and we don't need to wait for #108993.