Tracking Issue for const_waker

[y86-dev]

Feature gate: #![feature(const_waker)]

This is a tracking issue for constifying the following functions:

• Context::from_waker
• Context::waker
• Waker::from_raw

Public API

// core::task
impl<'a> Context<'a> {
    pub const fn from_waker(waker: &'a Waker) -> Self;
    pub const fn waker(&self) -> &'a Waker;
}

impl Waker {
    pub const unsafe fn from_raw(waker: RawWaker) -> Waker;
}

Steps / History

• Implementation: Make from_waker, waker and from_raw unstably const #101798
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[dtolnay]

The const on Context::from_waker and Context::waker require revisiting after #95985, since static CONTEXT: Context<'static> = Context::from_waker(&WAKER) is no longer legal.

Before stabilizing those consts, we should have a real-world use case in mind, and a new test that is representative of that use case.

[traviscross]

@rustbot labels +I-libs-api-nominated

We discussed this in the WG-async call today. We observed there was a request for a use case here. We propose this one:

#![feature(const_waker)]

// ###################################################################
// Supporting code.

pub use nop_waker::*;
mod nop_waker {
    use core::{
        future::Future,
        pin::Pin,
        task::{Context, Poll, RawWaker, RawWakerVTable, Waker},
    };
    pub const NOP_RAWWAKER: RawWaker = {
        fn nop(_: *const ()) {}
        const VTAB: RawWakerVTable =
            RawWakerVTable::new(|_| NOP_RAWWAKER, nop, nop, nop);
        RawWaker::new(&() as *const (), &VTAB)
    };
    pub const NOP_WAKER: &Waker =
        &unsafe { Waker::from_raw(NOP_RAWWAKER) };
    pub const NOP_CONTEXT: Context<'static> =
        Context::from_waker(NOP_WAKER);
    pub fn poll_once<T, F>(f: &mut F) -> Poll<T>
    where
        F: Future<Output = T> + ?Sized + Unpin,
    {
        let mut cx = NOP_CONTEXT;
        Pin::new(f).as_mut().poll(&mut cx)
    }
}

This is code that's been copy-and-pasted into a number of places recently to support tests.

More generally, in any context where one might want a noop Waker or a greater-than-noop but similarly trivial Waker, one probably also wants these methods to be const stable. Even if we were to separately stabilize Waker::noop(), it could still make sense to stabilize const_waker in the spirit of stabilizing primitives where possible.

We agreed that the above is a valid use case for const_waker and that WG-async is in favor of stabilizing const_waker subject to better understanding the concerns @dtolnay raised with regard to #95985.

Nominating as WG-async would like to see this move forward or hear more details about those concerns.

[dtolnay]

Thanks Travis! Looks good.

Prior to #95985, the tests related to this feature involved static Context<'static> and static &'static Waker, which no longer works and those tests were deleted. If putting those types into const instead of static is useful too, this seems fine to move forward. Let's add the code from #102012 (comment) as a test as part of the stabilization PR.

@rust-lang/libs-api:
@rfcbot fcp merge

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[rakshith-ravi]

Curious question: is this a step towards async const fns?