Miscompilation when awaiting generator containing an enum with niche at least [0, 1]

[tmandry]

Code

This code: (playground)

#[repr(u32)]
pub enum Key {
    // Any number greater than 1 works.
    A = 2,
}

async fn foo() {}
async fn bar(_key: Key) {}

#[tokio::main]
async fn main() {
    let (_, _) = futures::future::join(
        foo(),
        bar(Key::A),
    )
    .await;
}

Panics with the message MaybeDone polled after value taken from inside futures-rs. The code driving this particular object is also in futures-rs inside the Join combinator, but this code couldn't possibly result in the panic that we see. That would require the Join future to get polled after it was completed, but that future is only awaited, so this should never happen.

This is a regression from stable to beta, bisected to PR #87794. It still exists in nightly.

Backtrace

Backtrace

thread 'main' panicked at 'MaybeDone polled after value taken', /playground/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.17/src/future/maybe_done.rs:99:36
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/d4647278cb2948e76b51e8cd7aa7d31ba6478a08/library/std/src/panicking.rs:543:12
   1: <futures_util::future::maybe_done::MaybeDone<Fut> as core::future::future::Future>::poll
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.17/src/future/maybe_done.rs:99:36
   2: <futures_util::future::join::Join<Fut1,Fut2> as core::future::future::Future>::poll
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.17/src/future/join.rs:55:33
   3: playground::main::{{closure}}
             at ./src/main.rs:11:18
   4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/d4647278cb2948e76b51e8cd7aa7d31ba6478a08/library/core/src/future/mod.rs:80:19
   5: tokio::park::thread::CachedParkThread::block_on::{{closure}}
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.11.0/src/park/thread.rs:263:54
   6: tokio::coop::with_budget::{{closure}}
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.11.0/src/coop.rs:106:9
   7: std::thread::local::LocalKey<T>::try_with
             at /rustc/d4647278cb2948e76b51e8cd7aa7d31ba6478a08/library/std/src/thread/local.rs:399:16
   8: std::thread::local::LocalKey<T>::with
             at /rustc/d4647278cb2948e76b51e8cd7aa7d31ba6478a08/library/std/src/thread/local.rs:375:9
   9: tokio::coop::with_budget
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.11.0/src/coop.rs:99:5
  10: tokio::coop::budget
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.11.0/src/coop.rs:76:5
  11: tokio::park::thread::CachedParkThread::block_on
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.11.0/src/park/thread.rs:263:31
  12: tokio::runtime::enter::Enter::block_on
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.11.0/src/runtime/enter.rs:151:13
  13: tokio::runtime::thread_pool::ThreadPool::block_on
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.11.0/src/runtime/thread_pool/mod.rs:72:9
  14: tokio::runtime::Runtime::block_on
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.11.0/src/runtime/mod.rs:459:43
  15: playground::main
             at ./src/main.rs:11:5
  16: core::ops::function::FnOnce::call_once
             at /rustc/d4647278cb2948e76b51e8cd7aa7d31ba6478a08/library/core/src/ops/function.rs:227:5

@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged

[tmandry]

Note that this regression is in the newly-promoted-to-beta 1.57, not 1.56 which is being released as stable this week.

[nbdd0121]

Minimized:

#[repr(u32)]
pub enum Foo {
    A = 2,
}

pub enum Bar {
	A(Foo),
	B,
    C,
}

fn main() {
    match Bar::A(Foo::A) {
        Bar::A(_) => (),
        _ => unreachable!(),
    }
}

[nbdd0121]

@rustbot claim

[nbdd0121]

@rustbot label: -A-async-await

[JohnTitor]

Assigning P-critical as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[eddyb]

(Posted in the fix PR as well for redundancy)

For the record, while I may have seen #87794 (comment) I do not recall ever reviewing the change it links to (52f4be9), which is where the bug was introduced (I was tipped off by the closures which did not exist in the version of that PR I reviewed).

[oli-obk]

the fix still needs a backport

[m-ou-se]

This was backported in #90151.