Previously, generate-deriving-span-tests.py would regenerate all the tests anew, even if they hadn't changed. This creates unnecessary diffs that only change the copyright year. Now we check to see if any of the content of the test has changed before generating the new one.

`Layout` is often used at the core of allocation APIs and is as a result pretty
sensitive to codegen in various circumstances. I was profiling `-C opt-level=z`
with a wasm project recently and noticed that the `unwrap()` wasn't removed
inside of `Layout`, causing the program to be much larger than it otherwise
would be. If inlining were more aggressive LLVM would have figured out that the
panic could be eliminated, but in general the methods here can't panic in the
first place!

As a result this commit makes the following tweaks:

* Removes `unwrap()` and replaces it with `unsafe` in `Layout::new` and
  `Layout::for_value`. For posterity though a debug assertion was left behind.
* Removes an `unwrap()` in favor of `?` in the `repeat` method. The comment
  indicating that the function call couldn't panic wasn't quite right in that if
  `alloc_size` becomes too large and if `align` is high enough it could indeed
  cause a panic.

This'll hopefully mean that panics never get introduced into code in the first
place, ensuring that `opt-level=z` is closer to `opt-level=s` in this regard.

…ans::LOAD.

…oerister

Make OnDiskCache thread-safer

I'm not sure if `synthetic_expansion_infos` is handled correctly.

`interpret_alloc_cache` and `interpret_alloc_size` seems to be wrong though, since the code may now decode two `AllocId`s in parallel. I'd like some input on how to fix that.

cc @oli-obk

r? @michaelwoerister

Implement Chalk lowering rule Normalize-From-Impl

This extends the Chalk lowering pass with the "Normalize-From-Impl" rule for generating program clauses from a trait definition as part of rust-lang#49177.

r? @nikomatsakis

…r=alexcrichton

Cross-compile builder to Windows for PRs on Travis

I chose a completely arbitrary windows target here (I have no idea what's best, we could do multiple -- they are relatively fast).

r? @alexcrichton

…☹, r=nrc

Don't inject clippy into rls on stable/beta

r? @nrc

as discussed at the all-hands

…mulacrum

core: Remove panics from some `Layout` methods

`Layout` is often used at the core of allocation APIs and is as a result pretty
sensitive to codegen in various circumstances. I was profiling `-C opt-level=z`
with a wasm project recently and noticed that the `unwrap()` wasn't removed
inside of `Layout`, causing the program to be much larger than it otherwise
would be. If inlining were more aggressive LLVM would have figured out that the
panic could be eliminated, but in general the methods here can't panic in the
first place!

As a result this commit makes the following tweaks:

* Removes `unwrap()` and replaces it with `unsafe` in `Layout::new` and
  `Layout::for_value`. For posterity though a debug assertion was left behind.
* Removes an `unwrap()` in favor of `?` in the `repeat` method. The comment
  indicating that the function call couldn't panic wasn't quite right in that if
  `alloc_size` becomes too large and if `align` is high enough it could indeed
  cause a panic.

This'll hopefully mean that panics never get introduced into code in the first
place, ensuring that `opt-level=z` is closer to `opt-level=s` in this regard.

…-usability, r=nikomatsakis

Ignore copyright year when generating deriving span tests

Previously, generate-deriving-span-tests.py would regenerate all the tests anew, even if they hadn't changed. This creates unnecessary diffs that only change the copyright year. Now we check to see if any of the content of the test has changed before generating the new one.

…lexcrichton

Work around LLVM debuginfo problem in librustc_driver.

Works around a problem (rust-lang#48910) with global variable debuginfo generation for `rustc_driver::get_trans::LOAD` by applying `#[no_debug]` to it (which just disables debuginfo generation for that variable). This way we can build the compiler with debuginfo again.

Since the problem is also present in beta, this workaround might have to be backported.

r? @alexcrichton

…st-without-rpath, r=Mark-Simulacrum

Fix test failure in src/tools/rustdoc-themes when rust.rpath = false

See rust-lang#49907

Remove -Zmiri debugging option

?r @oli-obk

…ennytm

improve Atomic*::fetch_update docs

This clarifies that fetch_update *always* returns the previous value, either as `Ok(_)` or `Err(_)`, depending on whether the supplied update function returned `Some(_)` or `None`.

…r=michaelwoerister

Make --emit=metadata output metadata regardless of link

Fixes rust-lang#40109. I'm not sure whether this condition was important here or not, but I can't see why it is required (removing it doesn't cause the error the comment warns about, so I'm assuming it's safe). If this is too heavy-handed, I can special-case on `OutputType::Metadata`.