Exhaustive matching doesn't work correctly for Coroutines with never_type variants

[henryksloan]

A project of mine uses coroutines that never return, and which therefore have ! as their Complete type. With the exhaustive_patterns feature (and indeed without it, now that min_exhaustive_patterns is stabilized), I expect the following code to compile:

#![feature(coroutine_trait)]
#![feature(never_type, exhaustive_patterns)]

use std::ops::CoroutineState;
fn func() {
    let x = cor();
    match x {
        CoroutineState::Yielded(_) => {}
    }
}

fn cor() -> CoroutineState <i32, !> { CoroutineState::Yielded(1) }

But it raises the following errors, complaining that the CoroutineState::Complete(!) variant isn't covered by the match:

error[E0004]: non-exhaustive patterns: `CoroutineState::Complete(_)` not covered
  --> src/main.rs:7:11
   |
7  |     match x {
   |           ^ pattern `CoroutineState::Complete(_)` not covered
   |
note: `CoroutineState<i32, !>` defined here
  --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/coroutine.rs:11:1
   |
11 | pub enum CoroutineState<Y, R> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
25 |     Complete(R),
   |     -------- not covered
   = note: the matched value is of type `CoroutineState<i32, !>`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
   |
8  ~         CoroutineState::Yielded(_) => {},
9  +         CoroutineState::Complete(_) => todo!()
   |

For more information about this error, try `rustc --explain E0004`.

Folks have suggested that this is due to the special handling of coroutines within Rust's type system.

Meta

rustc --version --verbose:

rustc 1.90.0-nightly (e3843659e 2025-07-04)
binary: rustc
commit-hash: e3843659e9f65f589d184d1221ac6149d5fa07b5
commit-date: 2025-07-04
host: x86_64-pc-windows-msvc
release: 1.90.0-nightly
LLVM version: 20.1.7

(I've reproduced this on Linux, too)

Backtrace

error[E0004]: non-exhaustive patterns: `CoroutineState::Complete(_)` not covered
  --> src/main.rs:7:11
   |
7  |     match x {
   |           ^ pattern `CoroutineState::Complete(_)` not covered
   |
note: `CoroutineState<i32, !>` defined here
  --> /home/henry/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/coroutine.rs:11:1
   |
11 | pub enum CoroutineState<Y, R> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
25 |     Complete(R),
   |     -------- not covered
   = note: the matched value is of type `CoroutineState<i32, !>`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
   |
8  ~         CoroutineState::Yielded(_) => {},
9  +         CoroutineState::Complete(_) => todo!()
   |

For more information about this error, try `rustc --explain E0004`.
error: could not compile `coroutine_exhaustive` (bin "coroutine_exhaustive") due to 1 previous error

[RalfJung]

Uh... yeah that is strange. That enum looks exactly like Result, and yet actually using Result in your example then works as expected.

Cc @Nadrieril

[Nadrieril]

Hmmm, I suspect that's because CoroutineState is unstable. If I copy-paste its definition (without the stability attribute), everything works fine. We have special-cases for unstable variants/fields (because they exist but we should sort of pretend they don't), will investigate.

[Nadrieril]

Yep ok, to avoid Pin<!> being uninhabited we added the heuristic that "unstable field => inhabited" here. Given that Pin's field is now private, possibly we can remove that hack?

[RalfJung]

Alternatively, check whether the feature gate is on and consider the field stable if it is?