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

Rollup of 9 pull requests #70330

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
Contributor

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
Contributor

bors commented Mar 23, 2020

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

@bors
Copy link
Contributor

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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