Skip to content

Rollup of 9 pull requests #70330

New issue

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

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

Already on GitHub? # to your account

Merged
merged 28 commits into from
Mar 23, 2020
Merged

Rollup of 9 pull requests #70330

merged 28 commits into from
Mar 23, 2020

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Mar 23, 2020

Successful merges:

Failed merges:

r? @ghost

GuillaumeGomez and 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.

Fix rust-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

Fixes rust-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.
@Centril Centril added the rollup A PR which is a rollup label Mar 23, 2020
@Centril
Copy link
Contributor Author

Centril commented Mar 23, 2020

@bors r+ p=9 rollup=never

@bors
Copy link
Collaborator

bors commented Mar 23, 2020

📌 Commit 5b29348 has been approved by Centril

@bors bors 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
Copy link
Collaborator

bors commented Mar 23, 2020

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

@bors
Copy link
Collaborator

bors commented Mar 23, 2020

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 23, 2020
@bors bors merged commit 1edd389 into rust-lang:master Mar 23, 2020
@Centril Centril deleted the rollup-ts0clvx branch March 23, 2020 22:03
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: 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