Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add core::task::ready! macro #70817

Merged
merged 1 commit into from
Jul 19, 2020
Merged

Add core::task::ready! macro #70817

merged 1 commit into from
Jul 19, 2020

Conversation

yoshuawuyts
Copy link
Member

@yoshuawuyts yoshuawuyts commented Apr 5, 2020

This PR adds ready! as a top-level macro to libcore following the implementation of futures_core::ready, tracking issue #70922. This macro is commonly used when implementing Future, AsyncRead, AsyncWrite and Stream. And being only 5 lines, it seems like a useful and straight forward addition to std.

Example

use core::task::{Context, Poll};
use core::future::Future;
use core::pin::Pin;

async fn get_num() -> usize {
    42
}

pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
    let mut f = get_num();
    let f = unsafe { Pin::new_unchecked(&mut f) };
    
    let num = ready!(f.poll(cx));
    // ... use num

    Poll::Ready(())
}

Naming

In async-std we chose to nest the macro under the task module instead of having the macro at the top-level. This is a pattern that currently does not occur in std, mostly due to this not being possible prior to Rust 2018.

This PR proposes to add the ready macro as core::ready. But another option would be to introduce it as core::task::ready since it's really only useful when used in conjunction with task::{Context, Poll}.

Implementation questions

I tried rendering the documentation locally but the macro didn't show up under core. I'm not sure if I quite got this right. I used the todo! macro PR as a reference, and our approaches look similar.

References

@rust-highfive
Copy link
Collaborator

r? @joshtriplett

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 5, 2020
@rust-highfive
Copy link
Collaborator

The job mingw-check of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2020-04-05T16:48:34.2669605Z ========================== Starting Command Output ===========================
2020-04-05T16:48:34.2673755Z [command]/bin/bash --noprofile --norc /home/vsts/work/_temp/88112c51-70b0-437b-b765-9c3144babf82.sh
2020-04-05T16:48:34.2674065Z 
2020-04-05T16:48:34.2677837Z ##[section]Finishing: Disable git automatic line ending conversion
2020-04-05T16:48:34.2698996Z ##[section]Starting: Checkout rust-lang/rust@refs/pull/70817/merge to s
2020-04-05T16:48:34.2702810Z Task         : Get sources
2020-04-05T16:48:34.2703134Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.
2020-04-05T16:48:34.2703471Z Version      : 1.0.0
2020-04-05T16:48:34.2703688Z Author       : Microsoft
---
2020-04-05T16:48:35.2690965Z ##[command]git remote add origin https://github.com/rust-lang/rust
2020-04-05T16:48:35.2696716Z ##[command]git config gc.auto 0
2020-04-05T16:48:35.2701150Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2020-04-05T16:48:35.2704952Z ##[command]git config --get-all http.proxy
2020-04-05T16:48:35.2712487Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/70817/merge:refs/remotes/pull/70817/merge
---
2020-04-05T16:51:45.3205556Z  ---> 3fc1b512c57b
2020-04-05T16:51:45.3205937Z Step 6/7 : ENV RUN_CHECK_WITH_PARALLEL_QUERIES 1
2020-04-05T16:51:45.3206491Z  ---> Using cache
2020-04-05T16:51:45.3207001Z  ---> 5ee4295733f4
2020-04-05T16:51:45.3208546Z Step 7/7 : ENV SCRIPT python2.7 ../x.py test src/tools/expand-yaml-anchors &&            python2.7 ../x.py check --target=i686-pc-windows-gnu --host=i686-pc-windows-gnu &&            python2.7 ../x.py build --stage 0 src/tools/build-manifest &&            python2.7 ../x.py test --stage 0 src/tools/compiletest &&            python2.7 ../x.py test src/tools/tidy &&            /scripts/validate-toolstate.sh
2020-04-05T16:51:45.3210332Z  ---> 3d07a0fa42fe
2020-04-05T16:51:45.3211331Z Successfully built 3d07a0fa42fe
2020-04-05T16:51:45.3212891Z Successfully tagged rust-ci:latest
2020-04-05T16:51:45.3213276Z Built container sha256:3d07a0fa42feb5754fc13bb2f7010ebe13e4b8b8cdbebed0c75d8da320c8c8ad
2020-04-05T16:51:45.3213276Z Built container sha256:3d07a0fa42feb5754fc13bb2f7010ebe13e4b8b8cdbebed0c75d8da320c8c8ad
2020-04-05T16:51:45.3213687Z Looks like docker image is the same as before, not uploading
2020-04-05T16:51:54.0952534Z [CI_JOB_NAME=mingw-check]
2020-04-05T16:51:54.1270719Z [CI_JOB_NAME=mingw-check]
2020-04-05T16:51:54.1306359Z == clock drift check ==
2020-04-05T16:51:54.1318354Z   local time: Sun Apr  5 16:51:54 UTC 2020
2020-04-05T16:51:54.2296372Z   network time: Sun, 05 Apr 2020 16:51:54 GMT
2020-04-05T16:51:54.2321858Z Starting sccache server...
2020-04-05T16:51:54.3212977Z configure: processing command line
2020-04-05T16:51:54.3213508Z configure: 
2020-04-05T16:51:54.3214516Z configure: rust.parallel-compiler := True
---
2020-04-05T16:55:54.5284961Z     Checking rustc_feature v0.0.0 (/checkout/src/librustc_feature)
2020-04-05T16:55:54.5490756Z     Checking fmt_macros v0.0.0 (/checkout/src/libfmt_macros)
2020-04-05T16:55:54.7633837Z     Checking rustc_ast_pretty v0.0.0 (/checkout/src/librustc_ast_pretty)
2020-04-05T16:55:54.9669964Z     Checking rustc_hir v0.0.0 (/checkout/src/librustc_hir)
2020-04-05T16:55:55.4892544Z     Checking rustc_query_system v0.0.0 (/checkout/src/librustc_query_system)
2020-04-05T16:55:58.1470152Z     Checking rustc_attr v0.0.0 (/checkout/src/librustc_attr)
2020-04-05T16:55:58.7666974Z     Checking rustc_parse v0.0.0 (/checkout/src/librustc_parse)
2020-04-05T16:56:01.0816472Z     Checking rustc_hir_pretty v0.0.0 (/checkout/src/librustc_hir_pretty)
2020-04-05T16:56:01.5810980Z     Checking rustc_ast_lowering v0.0.0 (/checkout/src/librustc_ast_lowering)
---
2020-04-05T16:57:59.8054061Z configure: build.locked-deps    := True
2020-04-05T16:57:59.8055097Z configure: llvm.ccache          := sccache
2020-04-05T16:57:59.8055757Z configure: build.cargo-native-static := True
2020-04-05T16:57:59.8056290Z configure: dist.missing-tools   := True
2020-04-05T16:57:59.8056964Z configure: build.configure-args := ['--enable-sccache', '--disable-manage-submodu ...
2020-04-05T16:57:59.8057781Z configure: writing `config.toml` in current directory
2020-04-05T16:57:59.8058060Z configure: 
2020-04-05T16:57:59.8058563Z configure: run `python /checkout/x.py --help`
2020-04-05T16:57:59.8058816Z configure: 
---
2020-04-05T16:59:31.2930543Z Hugepagesize:       2048 kB
2020-04-05T16:59:31.2930809Z DirectMap4k:      141248 kB
2020-04-05T16:59:31.2931053Z DirectMap2M:     4052992 kB
2020-04-05T16:59:31.2931297Z DirectMap1G:     5242880 kB
2020-04-05T16:59:31.2947362Z + python2.7 ../x.py test src/tools/expand-yaml-anchors
2020-04-05T16:59:32.7735964Z Ensuring the YAML anchors in the GitHub Actions config were expanded
2020-04-05T16:59:32.7735964Z Ensuring the YAML anchors in the GitHub Actions config were expanded
2020-04-05T16:59:32.7743186Z Building stage0 tool expand-yaml-anchors (x86_64-unknown-linux-gnu)
2020-04-05T16:59:33.0341293Z    Compiling unicode-xid v0.2.0
2020-04-05T16:59:33.1839445Z    Compiling syn v1.0.11
2020-04-05T16:59:34.1290675Z    Compiling linked-hash-map v0.5.2
2020-04-05T16:59:34.1731099Z    Compiling lazy_static v1.4.0
2020-04-05T16:59:34.1731099Z    Compiling lazy_static v1.4.0
2020-04-05T16:59:34.3782207Z    Compiling yaml-rust v0.4.3
2020-04-05T16:59:39.2532639Z    Compiling quote v1.0.2
2020-04-05T16:59:55.9196304Z    Compiling thiserror-impl v1.0.5
2020-04-05T17:00:01.3400637Z    Compiling thiserror v1.0.5
2020-04-05T17:00:01.4107101Z    Compiling yaml-merge-keys v0.4.0
2020-04-05T17:00:02.7553518Z    Compiling expand-yaml-anchors v0.1.0 (/checkout/src/tools/expand-yaml-anchors)
2020-04-05T17:00:04.5723209Z Build completed successfully in 0:00:33
2020-04-05T17:00:04.5734250Z + python2.7 ../x.py check --target=i686-pc-windows-gnu --host=i686-pc-windows-gnu
2020-04-05T17:00:04.8365250Z     Finished dev [unoptimized] target(s) in 0.19s
2020-04-05T17:00:06.0547399Z Checking rustdoc artifacts (x86_64-unknown-linux-gnu -> i686-pc-windows-gnu)
---
2020-04-05T17:02:28.8410494Z     Checking rustc_feature v0.0.0 (/checkout/src/librustc_feature)
2020-04-05T17:02:28.8432771Z     Checking fmt_macros v0.0.0 (/checkout/src/libfmt_macros)
2020-04-05T17:02:29.0736855Z     Checking rustc_ast_pretty v0.0.0 (/checkout/src/librustc_ast_pretty)
2020-04-05T17:02:29.3442237Z     Checking rustc_hir v0.0.0 (/checkout/src/librustc_hir)
2020-04-05T17:02:29.7716141Z     Checking rustc_query_system v0.0.0 (/checkout/src/librustc_query_system)
2020-04-05T17:02:32.5379639Z     Checking rustc_attr v0.0.0 (/checkout/src/librustc_attr)
2020-04-05T17:02:33.1285849Z     Checking rustc_parse v0.0.0 (/checkout/src/librustc_parse)
2020-04-05T17:02:35.4867688Z     Checking rustc_hir_pretty v0.0.0 (/checkout/src/librustc_hir_pretty)
2020-04-05T17:02:35.9702557Z     Checking rustc_ast_lowering v0.0.0 (/checkout/src/librustc_ast_lowering)
---
2020-04-05T17:07:06.5585832Z Found 0 error codes with no tests
2020-04-05T17:07:06.5586013Z Done!
2020-04-05T17:07:06.5590959Z 
2020-04-05T17:07:06.5591143Z 
2020-04-05T17:07:06.5592566Z command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo"
2020-04-05T17:07:06.5593212Z 
2020-04-05T17:07:06.5593294Z 
2020-04-05T17:07:06.5604528Z failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
2020-04-05T17:07:06.5604845Z Build completed unsuccessfully in 0:00:38
2020-04-05T17:07:06.5604845Z Build completed unsuccessfully in 0:00:38
2020-04-05T17:07:06.5653387Z == clock drift check ==
2020-04-05T17:07:06.5667237Z   local time: Sun Apr  5 17:07:06 UTC 2020
2020-04-05T17:07:06.6618501Z   network time: Sun, 05 Apr 2020 17:07:06 GMT
2020-04-05T17:07:08.2391600Z 
2020-04-05T17:07:08.2391600Z 
2020-04-05T17:07:08.2468577Z ##[error]Bash exited with code '1'.
2020-04-05T17:07:08.2485790Z ##[section]Finishing: Run build
2020-04-05T17:07:08.2542344Z ##[section]Starting: Checkout rust-lang/rust@refs/pull/70817/merge to s
2020-04-05T17:07:08.2547647Z Task         : Get sources
2020-04-05T17:07:08.2548056Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.
2020-04-05T17:07:08.2548432Z Version      : 1.0.0
2020-04-05T17:07:08.2548682Z Author       : Microsoft
2020-04-05T17:07:08.2548682Z Author       : Microsoft
2020-04-05T17:07:08.2549075Z Help         : [More Information](https://go.microsoft.com/fwlink/?LinkId=798199)
2020-04-05T17:07:08.2549552Z ==============================================================================
2020-04-05T17:07:08.6061580Z Cleaning any cached credential from repository: rust-lang/rust (GitHub)
2020-04-05T17:07:08.6104686Z ##[section]Finishing: Checkout rust-lang/rust@refs/pull/70817/merge to s
2020-04-05T17:07:08.6216338Z Cleaning up task key
2020-04-05T17:07:08.6217888Z Start cleaning up orphan processes.
2020-04-05T17:07:08.6463005Z Terminate orphan process: pid (3576) (python)
2020-04-05T17:07:08.6693985Z ##[section]Finishing: Finalize Job

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @rust-lang/infra. (Feature Requests)

@bors
Copy link
Contributor

bors commented Apr 6, 2020

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

@eddyb
Copy link
Member

eddyb commented Apr 12, 2020

This is a pattern that currently does not occur in std, mostly due to this not being possible prior to Rust 2018.

cc @petrochenkov I think this is actually possible, but maybe it requires macro not macro_rules!.

src/libcore/macros/mod.rs Outdated Show resolved Hide resolved
@petrochenkov
Copy link
Contributor

I think this is actually possible, but maybe it requires macro not macro_rules!.

Yes, either macro (preferable), or #[macro_export] macro_rules! in a separate helper crate.

@nikomatsakis nikomatsakis added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Apr 13, 2020
@nikomatsakis
Copy link
Contributor

I'm tagging this for @rust-lang/libs, since that seems like the most appropriate team to make decisions here, but I think we should also have some discussion about the best way to manage "async-related conveniences" (not on this PR, I'll fire up a discussion on Zulip under #wg-async-foundations perhaps).

In any case, this seems like a pretty logical addition to me. I imagine that it would come up a lot when implementing futures by hand.

I personally would prefer to see task::ready!, and to begin the process of putting macros at logical points within the tree. This is particularly true since async fn is only available on Rust 2018. But I wonder, @petrochenkov, whether there are stability-related reasons not to use macro in publicly visible APIs? e.g., I guess it maybe uses a distinct kind of hygiene that would not otherwise be exposed?

@SimonSapin
Copy link
Contributor

The implementation of this macro is eerily similar to that of try!. Could this be an impl of the Try trait instead, so the ? operator could be used?

This is a pattern that currently does not occur in std, mostly due to this not being possible prior to Rust 2018.

Even in Rust 2018, it’s surprisingly involved to export a macro_rules! macro at a path that is not at the crate top-level. You’d need a separate crate that uses #[macro_export] (which always exports at the top level), then have libcore use pub use. See for example f69293a from #65479, where we then decided not to do that and instead have the macro at the top-level and in the prelude.

@eddyb
Copy link
Member

eddyb commented Apr 13, 2020

@SimonSapin Was macro attempted in that case, and were issues found?
(I'm assuming it should work now given #70817 (comment), but maybe there are still some edge cases)

@petrochenkov
Copy link
Contributor

But I wonder, @petrochenkov, whether there are stability-related reasons not to use macro in publicly visible APIs? e.g., I guess it maybe uses a distinct kind of hygiene that would not otherwise be exposed?

We already use macro in libcore for user-facing stuff.
Same things can be done with stable tools, it's just more annoying and would require a separate macro crate.

Macros 2.0 can use macro_rules hygiene if necessary:

#[rustc_macro_transparency = "semitransparent"]
pub macro ready() {}

@SimonSapin
Copy link
Contributor

@eddyb I did not attempt to use macro for #65479 because I don’t know how. https://doc.rust-lang.org/unstable-book/language-features/decl-macro.html only links to the tracking issue, which doesn’t seem to discuss docs about this feature.

@eddyb
Copy link
Member

eddyb commented Apr 13, 2020

@SimonSapin Oh, that's probably because most of the differences are semantic.
The syntax differences are trivial (, between the arms instead of ;, plus a shorthand syntax).

Using the shorthand syntax (otherwise it's just macro_rules! -> macro):

pub macro matches($expression:expr, $( $pattern:pat )|+ $( if $guard: expr )?) {
    match $expression {
        $( $pattern )|+ $( if $guard )? => true,
        _ => false
    }
}

@nikomatsakis
Copy link
Contributor

@SimonSapin Hmm -- so, we did deliberate for quite some time whether the Try trait should be used for futures, and I remember us concluding that it was too tricky by half, but that was back when Future had a "built-in result" (in which case, the ? was sometimes propagating errors, sometimes propagating ready results, etc).

Now that Poll is just ready/not-ready, it could in principle be used with ?, yes, although I think this is a good example where the existing design of the Try trait is not particularly well-suited. This is because it tries to make the "source type" irrelevant and instead maps to ok/error types (and reverse). So we would have to make a singleton type like PollNotReady and have the "error" type for Poll map to that. But that could be left unstable, and we've been talking about different designs for Try (@scottmcm is following that most closely, afaik).

@taiki-e
Copy link
Member

taiki-e commented Apr 14, 2020

@SimonSapin

The implementation of this macro is eerily similar to that of try!. Could this be an impl of the Try trait instead, so the ? operator could be used?

Poll already implements Try trait for another purpose: https://doc.rust-lang.org/nightly/core/task/enum.Poll.html#impl-Try

@nikomatsakis
Copy link
Contributor

Ah, ok, that is indeed the 'multiple possible uses of Try' I was referring to, just applied to the composed Poll<Result<..>> type.

@SimonSapin
Copy link
Contributor

Thanks for the explanations! I was not aware this had been discussed before.

@crlf0710 crlf0710 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 24, 2020
@crlf0710 crlf0710 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 2, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 9, 2020
…=sfackler

Add core::future::{pending,ready}

Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve, or never resolve which is an incredible useful tool when writing documentation.

These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate.

## Examples

In rust-lang#70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin`, which leads to the use of `unsafe`. Instead had we had `future::ready` available, we could've written the same example without using `unsafe`:

```rust
use core::task::{Context, Poll};
use core::future::{self, Future};
use core::pin::Pin;

pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
    let mut fut = future::ready(42_u8);
    let num = ready!(Pin::new(fut).poll(cx));
    // ... use num

    Poll::Ready(())
}
```

## Why future::ready?

Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin`, and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)).

The final, minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future`, and can be used as a useful teaching device.

## References
- [`futures::future::ready`](https://docs.rs/futures/0.3.4/futures/future/fn.ready.html)
- [`futures::future::pending`](https://docs.rs/futures/0.3.4/futures/future/fn.pending.html)
- [`async_std::future::pending`](https://docs.rs/async-std/1.5.0/async_std/future/fn.pending.html)
- [`async_std::future::ready`](https://docs.rs/async-std/1.5.0/async_std/future/fn.ready.html)
@joelpalmer joelpalmer added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 12, 2020
@Elinvynia Elinvynia added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 20, 2020
@Dylan-DPC-zz
Copy link

@yoshuawuyts once you rebase this, i'll get it reviewed

@yoshuawuyts
Copy link
Member Author

@Dylan-DPC rebased!

@Dylan-DPC-zz
Copy link

r? @dtolnay

Copy link
Member

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, seems good to me.

I think I would prefer an import path for this macro as core::task::ready since it is only applicable when used in conjunction with core::task::Context and core::task::Poll. Take a look at #72279 for an existing example of a macro not at the crate root; that one is exposed as core::ptr::raw_ref.

src/libcore/macros/mod.rs Outdated Show resolved Hide resolved
@withoutboats
Copy link
Contributor

I agree that we should expose this under the task module.

@yoshuawuyts
Copy link
Member Author

Updated with @dtolnay's feedback!

@yoshuawuyts yoshuawuyts changed the title Add core::ready! macro Add core::task::ready! macro Jul 15, 2020
@yoshuawuyts
Copy link
Member Author

Note that this PR is affected by #74355 which means it won't show up in the docs. Imo that shouldn't block this PR from being merged in nightly, though probably wait for that to be resolved before stabilizing.

Copy link
Member

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@dtolnay
Copy link
Member

dtolnay commented Jul 18, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Jul 18, 2020

📌 Commit 18be370 has been approved by dtolnay

@bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 18, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 19, 2020
…arth

Rollup of 7 pull requests

Successful merges:

 - rust-lang#70817 (Add core::task::ready! macro)
 - rust-lang#73762 (Document the trait keyword)
 - rust-lang#74021 (impl Index<RangeFrom> for CStr)
 - rust-lang#74071 (rustc_metadata: Make crate loading fully speculative)
 - rust-lang#74445 (add test for rust-lang#62878)
 - rust-lang#74459 (Make unreachable_unchecked a const fn)
 - rust-lang#74478 (Revert "Use an UTF-8 locale for the linker.")

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Jul 19, 2020

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

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 19, 2020
@bors bors merged commit 479c8ad into rust-lang:master Jul 19, 2020
@yoshuawuyts yoshuawuyts deleted the task-ready branch July 19, 2020 07:34
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jul 28, 2021
…=m-ou-se

Stabilize core::task::ready!

_Tracking issue: https://github.com/rust-lang/rust/issues/70922_

This PR stabilizes the `task::ready!` macro. Similar to rust-lang#80886, this PR was waiting on rust-lang#74355 to be fixed.

The `task::ready!` API has existed in the futures ecosystem for several years, and was added on nightly last year in rust-lang#70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library.

r? `@tmandry`

cc/ `@rust-lang/wg-async-foundations` `@rust-lang/libs`

## Example
```rust
use core::task::{Context, Poll};
use core::future::Future;
use core::pin::Pin;

async fn get_num() -> usize {
    42
}

pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
    let mut f = get_num();
    let f = unsafe { Pin::new_unchecked(&mut f) };

    let num = ready!(f.poll(cx));
    // ... use num

    Poll::Ready(())
}
```
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jul 28, 2021
…=m-ou-se

Stabilize core::task::ready!

_Tracking issue: https://github.com/rust-lang/rust/issues/70922_

This PR stabilizes the `task::ready!` macro. Similar to rust-lang#80886, this PR was waiting on rust-lang#74355 to be fixed.

The `task::ready!` API has existed in the futures ecosystem for several years, and was added on nightly last year in rust-lang#70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library.

r? ``@tmandry``

cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs``

## Example
```rust
use core::task::{Context, Poll};
use core::future::Future;
use core::pin::Pin;

async fn get_num() -> usize {
    42
}

pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
    let mut f = get_num();
    let f = unsafe { Pin::new_unchecked(&mut f) };

    let num = ready!(f.poll(cx));
    // ... use num

    Poll::Ready(())
}
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.