Waker::will_wake() broken on nightly

[jkarneges]

I would expect this to run to completion:

use std::sync::Arc;
use std::task::{Wake, Waker};

struct NoopWaker;

impl Wake for NoopWaker {
    fn wake(self: Arc<Self>) {}
}

fn main() {
    let waker: Waker = Arc::new(NoopWaker).into();
    let other = waker.clone();

    assert!(waker.will_wake(&other));
}

On stable, it does:

$ rustup default stable
info: using existing install for 'stable-x86_64-apple-darwin'
info: default toolchain set to 'stable-x86_64-apple-darwin'

  stable-x86_64-apple-darwin unchanged - rustc 1.76.0 (07dca489a 2024-02-04)

$ cargo run
   Compiling will_wake v0.1.0 (/Users/justin/dev/will_wake)
    Finished dev [unoptimized + debuginfo] target(s) in 0.38s
     Running `target/debug/will_wake`

But not on current nightly:

$ rustup default nightly
info: using existing install for 'nightly-x86_64-apple-darwin'
info: default toolchain set to 'nightly-x86_64-apple-darwin'

  nightly-x86_64-apple-darwin unchanged - rustc 1.78.0-nightly (381d69953 2024-02-24)

$ cargo run
   Compiling will_wake v0.1.0 (/Users/justin/dev/will_wake)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.29s
     Running `target/debug/will_wake`
thread 'main' panicked at src/main.rs:14:5:
assertion failed: waker.will_wake(&other)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Interestingly, it works ok without cargo:

$ rustc --edition 2021 src/main.rs
$ ./main

The cargo project isn't special though:

$ cat Cargo.toml 
[package]
name = "will_wake"
version = "0.1.0"
edition = "2021"

[dependencies]

OS: macOS 13.6.3

[matthiaskrgr]

cc @tmiasko #119863 I guess?

[jkarneges]

The internal raw_waker function uses const promotion for the vtable in two places, once at initial construction and another when cloning. Maybe that results in two differently-addressed vtables.

[dtolnay]

I gave this a shot in #121622. But without a language feature for statics with type parameters, we are not seeing a reliable way to restore will_wake's functionality.

Let's consider reverting #119863. Having will_wake be a handful of CPU instructions faster but way more often wrong is not useful.