Rollup of 9 pull requests #70295
Closed
Rollup of 9 pull requests #70295
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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`.
The codegen implementation already works for this, so we're: * propagating track_caller attr from trait def to impl * relaxing errors * adding tests Approved in a recent lang team meeting: https://github.com/rust-lang/lang-team/blob/master/minutes/2020-01-09.md
We can do this now that opt_associated_item doesn't have any panicking paths.
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>
…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`.
#[track_caller] in traits Per rust-lang#47809 (comment), this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * "regular" trait impls * default trait impls * "blanket-tracked" trait impls, where the annotation is in the trait definition and is inherited by "regular" impls of the trait
Use getentropy(2) on macos resolves rust-lang#70179
Only display definition when suggesting a typo Closes rust-lang#70206 r? @Centril
…-morse resolve: Avoid "self-confirming" import resolutions in one more case So the idea behind "blacklisted bindings" is that we must ignore some name definitions during resolution because otherwise they cause infinite cycles. E.g. import ```rust use my_crate; ``` would refer to itself (on 2018 edition) without this blacklisting, because `use my_crate;` is the first name in scope when we are resolving `my_crate` here. In this PR we are doing this blacklisting for the case ```rust use same::same; ``` , namely blacklisting the second `same` when resolving the first `same`. This was previously forgotten. Fixes rust-lang#62767
parser: simplify & remove unused field r? @petrochenkov
handle ConstKind::Unresolved after monomorphizing fixes rust-lang#70125 r? @bjorn3
…an-DPC remove redundant closures (clippy::redundant_closure)
…an-DPC Clean up E0449 explanation r? @Dylan-DPC
|
@bors r+ p=9 rollup=never |
|
📌 Commit 6d4025b has been approved by |
bors
added
the
S-waiting-on-bors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Failed merges:
r? @ghost