Skip to content

Rollup of 9 pull requests - #70330

Merged
bors merged 28 commits into
rust-lang:masterfrom
Centril:rollup-ts0clvx
Mar 23, 2020
Merged

Rollup of 9 pull requests#70330
bors merged 28 commits into
rust-lang:masterfrom
Centril:rollup-ts0clvx

Conversation

@Centril

Copy link
Copy Markdown
Contributor

Successful merges:

Failed merges:

r? @ghost

GuillaumeGomezand others added 28 commits February 26, 2020 22:08
This required revising some of the client code to stop relying on
the returned set of lines being non-empty.
Currently, constructing a waker requires calling the unsafe
`Waker::from_raw` API. This API requires the user to manually construct
a vtable for the waker themself - which is both cumbersome and very
error prone. This API would provide an ergonomic, straightforward and
guaranteed memory-safe way of constructing a waker.
It has been our longstanding intention that the `Waker` type essentially
function as an `Arc<dyn Wake>`, with a `Wake` trait as defined here. Two
considerations prevented the original API from being shipped as simply
an `Arc<dyn Wake>`:
- We want to support futures on embedded systems, which may not have an
allocator, and in optimized executors for which this API may not be
best-suited. Therefore, we have always explicitly supported the
maximally-flexible (but also memory-unsafe) `RawWaker` API, and
`Waker` has always lived in libcore.
- Because `Waker` lives in libcore and `Arc` lives in liballoc, it has
not been feasible to provide a constructor for `Waker` from `Arc<dyn
Wake>`.
Therefore, the Wake trait was left out of the initial version of the
task waker API.
However, as Rust 1.41, it is possible under the more flexible orphan
rules to implement `From<Arc<W>> for Waker where W: Wake` in liballoc.
Therefore, we can now define this constructor even though `Waker` lives
in libcore.
This PR adds these APIs:
- A `Wake` trait, which contains two methods
- A required method `wake`, which is called by `Waker::wake`
- A provided method `wake_by_ref`, which is called by
`Waker::wake_by_ref` and which implementors can override if they
can optimize this use case.
- An implementation of `From<Arc<W>> for Waker where W: Wake + Send +
Sync + 'static`
- A similar implementation of `From<Arc<W>> for RawWaker`.
Co-Authored-By: Ashley Mannix <ashleymannix@live.com.au>
Co-Authored-By: Ashley Mannix <ashleymannix@live.com.au>
Co-Authored-By: Ashley Mannix <ashleymannix@live.com.au>
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
…oats
Add Wake trait for safe construction of Wakers.
Currently, constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic, straightforward and guaranteed memory-safe way of constructing a waker.
It has been our longstanding intention that the `Waker` type essentially function as an `Arc<dyn Wake>`, with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc<dyn Wake>`:
- We want to support futures on embedded systems, which may not have an allocator, and in optimized executors for which this API may not be best-suited. Therefore, we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API, and `Waker` has always lived in libcore.
- Because `Waker` lives in libcore and `Arc` lives in liballoc, it has not been feasible to provide a constructor for `Waker` from `Arc<dyn Wake>`.
Therefore, the Wake trait was left out of the initial version of the task waker API.
However, as Rust 1.41, it is possible under the more flexible orphan rules to implement `From<Arc<W>> for Waker where W: Wake` in liballoc. Therefore, we can now define this constructor even though `Waker` lives in libcore.
This PR adds these APIs:
- A `Wake` trait, which contains two methods
- A required method `wake`, which is called by `Waker::wake`
- A provided method `wake_by_ref`, which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case.
- An implementation of `From<Arc<W>> for Waker where W: Wake + Send + Sync + 'static`
- A similar implementation of `From<Arc<W>> for RawWaker`.
…ion, r=ehuss,aleksator,ollie27
Stabilize --crate-version option in rustdoc
I don't see any reason to not stabilize it anymore, so let's go!
cc @kinnison@ehuss
r? @ollie27
rustc_mir: remove extra space when pretty-printing MIR.
…y-spans-into-invalid-lines, r=estebank
Revised span-to-lines conversion to produce an empty vec on DUMMY_SP.
This required revising some of the client code to stop relying on the returned set of lines being non-empty.
Fixrust-lang#68808
add err_machine_stop macro
We have that for all other error kinds, but here I somehow forgot it.
r? @oli-obk
…ble_warning, r=Dylan-DPC
Reword unused variable warning
Fixesrust-lang#66636
Rename remaining occurences of Void to Opaque.
Two mentions of the type were missed when the type was renamed.
Split long derive lists into two derive attributes.
@CentrilCentril added the rollup A PR which is a rollup label Mar 23, 2020
@Centril

Copy link
Copy Markdown
ContributorAuthor

@bors r+ p=9 rollup=never

@bors

bors commented Mar 23, 2020

Copy link
Copy Markdown
Collaborator

📌 Commit 5b29348 has been approved by Centril

@borsbors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 23, 2020
@bors

bors commented Mar 23, 2020

Copy link
Copy Markdown
Collaborator

⌛ Testing commit 5b29348 with merge 1edd389...

@bors

bors commented Mar 23, 2020

Copy link
Copy Markdown
Collaborator

☀️ Test successful - checks-azure
Approved by: Centril
Pushing 1edd389 to master...

@borsbors added the merged-by-bors This PR was explicitly merged by bors. label Mar 23, 2020
@bors
bors merged commit 1edd389 into rust-lang:masterMar 23, 2020
@Centril
Centril deleted the rollup-ts0clvx branch March 23, 2020 22:03
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-borsThis PR was explicitly merged by bors.rollupA PR which is a rollupS-waiting-on-borsStatus: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants

@Centril@bors@GuillaumeGomez@anyska@rylev@pnkfelix@aleksator@RalfJung@withoutboats