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>

…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

…atthewjasper

Make `needs_drop` less pessimistic on generators

Generators only have non-trivial drop logic when they may store (in upvars or across yields) a type that does.

This prevents generation of some unnecessary MIR in simple generators. There might be some impact on compile times, but this is probably limited in real-world applications.

~~This builds off of rust-lang#69814 since that contains some fixes that are made relevant by *this* PR (see rust-lang#69814 (comment) (this has been merged)

rustc_mir: remove extra space when pretty-printing MIR.

Add test for issue rust-lang#53275

Fixes rust-lang#53275

add err_machine_stop macro

We have that for all other error kinds, but here I somehow forgot it.

r? @oli-obk

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.