The `Context` argument is currently smuggled through TLS for
async-generated futures. The current infrastructure is closure-based,
and results in an extra 6 stack frames when .awaiting an async-generated
future!
```
12: foo::async_b::{{closure}}
at src/main.rs:10
13: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}}
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43
14: std::future::set_task_context
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79
15: <std::future::GenFuture<T> as core::future::future::Future>::poll
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43
16: std::future::poll_with_tls_context::{{closure}}
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121
17: std::future::get_task_context
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111
18: std::future::poll_with_tls_context
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121
19: foo::async_a::{{closure}}
at src/main.rs:6
```
While the long (medium?) term solution is to remove the use of TLS
entirely, we can improve things a bit in the meantime. In particular,
this commit does 2 things:
1. `get_task_context` has been inlined into `poll_with_tls_context`,
removing 2 frames (16 and 17 above).
2. `set_task_context` now returns a guard type that resets the TLS
rather than taking a closure, removing 2 frames (13 and 14 above).
We can also remove frame 18 by removing `poll_with_tls_context` in favor
of a `get_task_context` function which returns a guard, but that
requires adjusting the code generated for .await, so I've left that off
for now.
This commit improves obligation errors for async/await:
```
note: future does not implement `std::marker::Send` because this value is used across an
await
--> $DIR/issue-64130-non-send-future-diags.rs:15:5
|
LL | let g = x.lock().unwrap();
| - has type `std::sync::MutexGuard<'_, u32>`
LL | baz().await;
| ^^^^^^^^^^^ await occurs here, with `g` maybe used later
LL | }
| - `g` is later dropped here
```
Signed-off-by: David Wood <david@davidtw.co>
This change updates the future and task API as discussed in the stabilization RFC at https://github.com/rust-lang/rfcs/pull/2592.
Changes:
- Replacing UnsafeWake with RawWaker and RawWakerVtable
- Removal of LocalWaker
- Removal of Arc-based Wake trait
Remove pin::Unpin reexport and add Unpin to the prelude.
Change Pin associated functions to methods.
Rename get_mut_unchecked_ to get_unchecked_mut
Remove impl Unpin for Pin
Mark Pin repr(transparent)
r?
This is all of my scheduler work on #4419 from the last 3 weeks or so. I've had a few failed pull requests so far but I think the problems are ironed out.
* TCP
* The beginnings of runtime embedding APIs
* Porting various corners of core to be compatible with both schedulers
* libuv timer bindings
* Further refinement of I/O error handling, including a new, incomplete, `read_error` condition
* Incomplete refactoring to make tasks work without coroutines and user-space scheduling
* Implementations of Reader/Writer extension methods
* Implementations of the most important part of core::comm
I'm particularly happy with how easy the [comm types on top of the scheduler](https://github.com/brson/rust/blob/io-upstream/src/libcore/rt/comm.rs). Note that these implementations do not use pipes. If anything here needs careful review though it's this code.
This branch passes 95% of the run-pass tests (with `TESTARGS=--newrt`)
In the next week I'll probably spend some time adding preliminary multithreading and seeing how close we are to removing the old runtime.
fail!() used to require owned strings but can handle static strings
now. Also, it can pass its arguments to fmt!() on its own, no need for
the caller to call fmt!() itself.
