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`.

Rollup of 8 pull requests

Successful merges:

 - #69080 (rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.)
 - #69940 (librustc_codegen_llvm: Replace deprecated API usage)
 - #69942 (Increase verbosity when suggesting subtle code changes)
 - #69968 (rustc: keep upvars tupled in {Closure,Generator}Substs.)
 - #70123 (Ensure LLVM is in the link path for rustc tools)
 - #70159 (Update the bundled wasi-libc with libstd)
 - #70233 (resolve: Do not resolve visibilities on proc macro definitions twice)
 - #70286 (Miri error type: remove UbExperimental variant)

Failed merges:

r? @ghost

Miri error type: remove UbExperimental variant

In https://github.com/rust-lang/miri/pull/1250, I will move Miri away from that variant, and use a custom `MachineStop` exception instead.

resolve: Do not resolve visibilities on proc macro definitions twice

Fixes https://github.com/rust-lang/rust/issues/68921

Update the bundled wasi-libc with libstd

Brings in WebAssembly/wasi-libc#184 which can help standalone programs
with environment variables!

Ensure LLVM is in the link path for rustc tools

The build script for `rustc_llvm` outputs LLVM information in `cargo:rustc-link-lib` and `cargo:rustc-link-search` so the compiler can be linked correctly. However, while the lib is carried along in metadata, the search paths are not. So when cargo is invoked again later for rustc _tools_, they'll also try to link with LLVM, but the necessary paths may be left out.

Rustbuild can use the environment to set the LLVM link path for tools -- `LIB` for MSVC toolchains and `LIBRARY_PATH` for everyone else.

Fixes #68714.

rustc: keep upvars tupled in {Closure,Generator}Substs.

Previously, each closure/generator capture's (aka "upvar") type was tracked as one "synthetic" type parameter in the closure/generator substs, and figuring out where the parent `fn`'s generics end and the synthetics start involved slicing at `tcx.generics_of(def_id).parent_count`.

Needing to query `generics_of` limited @davidtwco (who wants to compute some `TypeFlags` differently for parent generics vs upvars, and `TyCtxt` is not available there), which is how I got started on this, but it's also possible that the `generics_of` queries are slowing down `{Closure,Generator}Substs` methods.

To give an example, for a `foo::<T, U>::{closure#0}` with captures `x: X` and `y: Y`, substs are:
* before this PR: `[T, U, /*kind*/, /*signature*/, X, Y]`
* after this PR: `[T, U, /*kind*/, /*signature*/, (X, Y)]`

You can see that, with this PR, no matter how many captures, the last 3 entries in the substs (or 5 for a generator) are always the "synthetic" ones, with the last one being the tuple of capture types.

r? @nikomatsakis cc @Zoxc

Increase verbosity when suggesting subtle code changes

Do not suggest changes that are actually quite small inline, to minimize the likelihood of confusion.

Fix #69243.

librustc_codegen_llvm: Replace deprecated API usage

rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.

Works towards #69074 by adding more checks for `DebugInfo::Full` in a few places in `rustc_codegen_llvm`, bringing us in line with what `clang -g1` generates (no debuginfo types, nor debuginfo for `static`s).

<hr/>

My local build's (`debuginfo-level=1`, `debug-assertions=1`) `librustc_driver-*.so` went from just over 1GiB (1019MiB) down to 402MiB.

It's still bad, but the `.debug_*` sections themselves (as reported by `objdump`) went from something like 853MiB down to 236MiB, i.e. roughly a 3.6x reduction.

<hr/>

Sadly, I don't think this is enough to justify *shipping* all of this debuginfo, but now it's more plausible that we could at least *build* with `debuginfo-level=1` *then* strip it.
That would give us real backtraces for e.g. ICEs during builds, but I don't know how often that's relevant.

We could also look into split DWARF, and maybe have a `rustc-debuginfo` component in `rustup`.

There's also the possibility of making it slimmer by omitting parameters to functions, or perhaps some deduplication (I think right now there is no DWARF reuse across CGUs? maybe ThinLTO helps?).

r? @michaelwoerister cc @rust-lang/wg-codegen @alexcrichton @Mark-Simulacrum

Rollup of 9 pull requests

Successful merges:

 - #69251 (#[track_caller] in traits)
 - #69880 (miri engine: turn error sanity checks into assertions)
 - #70207 (Use getentropy(2) on macos)
 - #70227 (Only display definition when suggesting a typo)
 - #70236 (resolve: Avoid "self-confirming" import resolutions in one more case)
 - #70248 (parser: simplify & remove unused field)
 - #70249 (handle ConstKind::Unresolved after monomorphizing)
 - #70269 (remove redundant closures (clippy::redundant_closure))
 - #70270 (Clean up E0449 explanation)

Failed merges:

r? @ghost

Clean up E0449 explanation

r? @Dylan-DPC

remove redundant closures (clippy::redundant_closure)

handle ConstKind::Unresolved after monomorphizing

fixes #70125

r? @bjorn3

parser: simplify & remove unused field

r? @petrochenkov

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 https://github.com/rust-lang/rust/issues/62767

Only display definition when suggesting a typo

Closes #70206
r? @Centril

Use getentropy(2) on macos

resolves #70179

miri engine: turn error sanity checks into assertions

We had these as debug assertions so far to make sure our test suite is clean, but really these are conditions that should never arise and also @EddyB told me to turn non-performance-critical debug assertions into full assertions so here we go. ;)

I propose that we do a check-only crater run to make sure this does not actually happen in practice.

r? @oli-obk

#[track_caller] in traits

Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760, 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

Liberate `rustc_ast_lowering` from `rustc`

The whole point of this PR is the very last commit, in which we remove `rustc` as one of `rustc_ast_lowering`'s dependencies, thereby improving `./x.py` parallelism and working towards https://github.com/rust-lang/rust/issues/65031.

Noteworthy:
- From `rustc::arena` we move logic into `arena`, in particular `declare_arena!`. This is then used in `rustc_ast_lowering` so that lowering has its own separate arena.
- Some linting code is unfortunately moved to `rustc_session::lint` cause its used both in `rustc_lint` and `rustc_ast_lowering`, and this is their common dependency.
- `rustc_session::CrateDisambiguator` is moved into `rustc_ast` so that `rustc::hir::map::definitions` can be moved into `rustc_hir`, so that `rustc_ast_lowering` can stop referring to `rustc::hir`.

r? @Zoxc

We can do this now that opt_associated_item doesn't have any panicking paths.

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

perf(dep_graph): Avoid allocating a set on when the number reads are …

…small

`reserve_and_rehash` takes up 1.4% of the runtime on the `packed-simd`
benchmark which I believe is due to the number of reads are very low in
many cases (see https://github.com/rust-lang/rust/pull/50565 for
instance).

This avoids allocating the set until we start allocating the `reads`
`SmallVec` but it is possible that a lower limit might be better (not
tested since the improvement will be hard to spot either way).

Allow calculating the layout behind a pointer

There was some discussion around allowing this previously.

This does make the requirement for raw pointers to have valid metadata exposed as part of the std API (as a safety invariant, not validity invariant), though I think this is not strictly necessarily required as of current. cc @rust-lang/wg-unsafe-code-guidelines

Naming is hard; I picked the best "obvious" name I could come up with.

If it's agreed that this is actually a desired API surface, I'll file a tracking issue and update the attributes.