Stabilize the Wake trait #74304

yoshuawuyts · 2020-07-13T20:46:45Z

This PR proposes stabilizing the wake_trait feature, tracking issue #69912.

Motivation

The surface area this trait introduces is small, and it has been on nightly for 4 months without any reported issues. Given the surface area of this trait is small and only serves to provide a safe interface around the already stable std::task::RawWakerVTable it seems unlikely this trait will require any further changes. So I'm proposing we stabilize this.

Personally I would love to have this available on stable, since it would enable cleaning up some runtime internals by removing the tedious pointer required to construct a RawWakerVTable. I believe the intent was always to introduce a Wake counterpart to RawWaker in order to safely construct Waker instances. And the Wake trait feels like it does that job as intended.

Implementation notes

This PR itself fixes a link in the docs, and introduces an example of how to use the trait: a minimal block_on example that runs a future to completion on the current thread. It doesn't include fancier features such as support for nesting, but is intended to serve as a teaching device for both task::Wake and futures alike.

rust-highfive · 2020-07-13T20:46:48Z

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

src/liballoc/task.rs

yoshuawuyts · 2020-07-14T09:17:48Z

Updated with @Aaron1011's feedback!

…ark-Simulacrum Remove unnecessary type hints from Wake internals While working on rust-lang#74304 I noticed we were writing out the type signature twice in some internal `Wake` impl methods; this streamlines that. Thanks!

tmandry · 2020-07-16T20:27:16Z

Looks good to me!

r? @dtolnay for libs team FCP

src/liballoc/task.rs

dtolnay · 2020-07-18T19:07:06Z

Reassigning for an opinion on FCP since the tracking issue is quite bare and I haven't been up to speed on the use cases/whether this would be ready to consider stabilizing: r? @withoutboats

src/liballoc/task.rs

yoshuawuyts · 2020-07-19T08:14:45Z

@dtolnay I've posted an overview of use cases on the tracking issue: #69912 (comment).

yoshuawuyts · 2020-07-19T10:49:24Z

Updated with feedback from @jyn514, @tmiasko, and @Aaron1011. Also bumped the version to point to 1.47 since 1.46 is already in beta.

bors · 2020-07-28T03:12:20Z

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

KodrAus · 2021-01-22T03:59:36Z

cc @rust-lang/libs this hasn't made it up to the top of our nominated backlog to discuss yet. Are we happy to proceed with the stabilization of Waker possibly without a blanket implementation for Fn? My personal preference is yes (mostly because I'd rather not add the Fn blanket at all), but it also sounds like we were reasonably confident it wouldn't be a compatibility hazard to introduce a blanket later.

yoshuawuyts · 2021-01-22T17:08:50Z

Rebased on the main branch and tidied up the commits; think that should bring this PR back to a state where it can be merged if the libs team decides it's right to do so.

bors · 2021-02-01T19:48:51Z

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

Co-Authored-By: Ashley Mannix <[email protected]>

yoshuawuyts · 2021-02-03T17:19:40Z

Are we happy to proceed with the stabilization of Waker possibly without a blanket implementation for Fn?

I'd be in favor of this, even if that meant we couldn't later implement the blanket impl for Fn. Using wakers directly is a bit of a niche already, and creating them even more so. Not having a blanket impl of Waker for Fn wouldn't affect end-users of async Rust in any meaningful way, which to me feels that it's okay to move ahead with this even without 100% assurance the blanket impl can be added later.

My worry is that because we currently don't have anyone dedicated to figuring out the type level details, if we defer making any decisions, Wake will sit around for another year without stabilizing. And that doesn't seem worth it, as Wake can remove unsafe from a fair bit of the ecosystem.

KodrAus · 2021-02-03T23:10:07Z

@bors r+

bors · 2021-02-03T23:10:08Z

📌 Commit 2c8bf1d has been approved by KodrAus

bors · 2021-02-04T10:20:49Z

⌛ Testing commit 2c8bf1d with merge efaa305a16a30dc82272f1b5d7d63c7102370167...

bors · 2021-02-04T14:35:49Z

💥 Test timed out

m-ou-se · 2021-02-04T14:44:20Z

@bors retry

Stabilize the Wake trait This PR proposes stabilizing the `wake_trait` feature, tracking issue rust-lang#69912. ## Motivation The surface area this trait introduces is small, and it has been on nightly for 4 months without any reported issues. Given the surface area of this trait is small and only serves to provide a safe interface around the already stable [`std::task::RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWaker.html) it seems unlikely this trait will require any further changes. So I'm proposing we stabilize this. Personally I would love to have this available on stable, since it would enable cleaning up some runtime internals by removing the tedious pointer required to construct a [`RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWakerVTable.html). I believe the intent was always to introduce a `Wake` counterpart to `RawWaker` in order to safely construct `Waker` instances. And the `Wake` trait feels like it does that job as intended. ## Implementation notes This PR itself fixes a link in the docs, and introduces an example of how to use the trait: a minimal `block_on` example that runs a future to completion on the current thread. It doesn't include fancier features such as support for nesting, but is intended to serve as a teaching device for both `task::Wake` and futures alike.

Rollup of 9 pull requests Successful merges: - rust-lang#74304 (Stabilize the Wake trait) - rust-lang#79805 (Rename Iterator::fold_first to reduce and stabilize it) - rust-lang#81556 (introduce future-compatibility warning for forbidden lint groups) - rust-lang#81645 (Add lint for `panic!(123)` which is not accepted in Rust 2021.) - rust-lang#81710 (OsStr eq_ignore_ascii_case takes arg by value) - rust-lang#81711 (add #[inline] to all the public IpAddr functions) - rust-lang#81725 (Move test to be with the others) - rust-lang#81727 (Revert stabilizing integer::BITS.) - rust-lang#81745 (Stabilize poison API of Once, rename poisoned()) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

rust-highfive assigned kennytm Jul 13, 2020

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 13, 2020

yoshuawuyts mentioned this pull request Jul 13, 2020

Tracking Issue for the Wake trait #69912

Closed

3 tasks

yoshuawuyts commented Jul 13, 2020

View reviewed changes

src/liballoc/task.rs Outdated Show resolved Hide resolved

jonas-schievink added A-async-await Area: Async & Await relnotes Marks issues that should be documented in the release notes of the next release. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jul 13, 2020

jonas-schievink added this to the 1.46 milestone Jul 13, 2020

Aaron1011 reviewed Jul 13, 2020

View reviewed changes

src/liballoc/task.rs Outdated Show resolved Hide resolved

yoshuawuyts mentioned this pull request Jul 14, 2020

Remove unnecessary type hints from Wake internals #74316

Merged

rust-highfive assigned dtolnay and unassigned kennytm Jul 16, 2020

tmiasko reviewed Jul 18, 2020

View reviewed changes

src/liballoc/task.rs Outdated Show resolved Hide resolved

Dylan-DPC-zz modified the milestones: 1.46, 1.47 Jul 18, 2020

rust-highfive assigned withoutboats and unassigned dtolnay Jul 18, 2020

jyn514 reviewed Jul 19, 2020

View reviewed changes

src/liballoc/task.rs Outdated Show resolved Hide resolved

Dylan-DPC-zz removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 10, 2020

Stabilize the Wake trait

2c8bf1d

Co-Authored-By: Ashley Mannix <[email protected]>

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 3, 2021

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 4, 2021

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 4, 2021

This comment has been minimized.

Sign in to view

m-ou-se mentioned this pull request Feb 4, 2021

Rollup of 14 pull requests #81754

Closed

m-ou-se mentioned this pull request Feb 4, 2021

Rollup of 9 pull requests #81761

Merged

bors merged commit d20d097 into rust-lang:master Feb 5, 2021

rustbot modified the milestones: 1.48.0, 1.51.0 Feb 5, 2021

yoshuawuyts deleted the stabilize-wake branch February 5, 2021 09:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stabilize the Wake trait #74304

Stabilize the Wake trait #74304

yoshuawuyts commented Jul 13, 2020

rust-highfive commented Jul 13, 2020

yoshuawuyts commented Jul 14, 2020

tmandry commented Jul 16, 2020

dtolnay commented Jul 18, 2020

yoshuawuyts commented Jul 19, 2020 •

edited

Loading

yoshuawuyts commented Jul 19, 2020

bors commented Jul 28, 2020

KodrAus commented Jan 22, 2021

yoshuawuyts commented Jan 22, 2021

bors commented Feb 1, 2021

yoshuawuyts commented Feb 3, 2021

KodrAus commented Feb 3, 2021

bors commented Feb 3, 2021

bors commented Feb 4, 2021

bors commented Feb 4, 2021

m-ou-se commented Feb 4, 2021

This comment has been minimized.

Stabilize the Wake trait #74304

Stabilize the Wake trait #74304

Conversation

yoshuawuyts commented Jul 13, 2020

Motivation

Implementation notes

rust-highfive commented Jul 13, 2020

yoshuawuyts commented Jul 14, 2020

tmandry commented Jul 16, 2020

dtolnay commented Jul 18, 2020

yoshuawuyts commented Jul 19, 2020 • edited Loading

yoshuawuyts commented Jul 19, 2020

bors commented Jul 28, 2020

KodrAus commented Jan 22, 2021

yoshuawuyts commented Jan 22, 2021

bors commented Feb 1, 2021

yoshuawuyts commented Feb 3, 2021

KodrAus commented Feb 3, 2021

bors commented Feb 3, 2021

bors commented Feb 4, 2021

bors commented Feb 4, 2021

m-ou-se commented Feb 4, 2021

This comment has been minimized.

yoshuawuyts commented Jul 19, 2020 •

edited

Loading