The current code in `SipHasher128::short_write` is inefficient. It uses
`u8to64_le` (which is complex and slow) to extract just the right number of
bytes of the input into a u64 and pad the result with zeroes. It then
left-shifts that value in order to bitwise-OR it with `self.tail`.

For example, imagine we have a u32 input 0xIIHH_GGFF and only need three bytes
to fill up `self.tail`. The current code uses `u8to64_le` to construct
0x0000_0000_00HH_GGFF, which is just 0xIIHH_GGFF with the 0xII removed and
zero-extended to a u64. The code then left-shifts that value by five bytes --
discarding the 0x00 byte that replaced the 0xII byte! -- to give
0xHHGG_FF00_0000_0000. It then then ORs that value with self.tail.

There's a much simpler way to do it: zero-extend to u64 first, then left shift.
E.g. 0xIIHH_GGFF is zero-extended to 0x0000_0000_IIHH_GGFF, and then
left-shifted to 0xHHGG_FF00_0000_0000. We don't have to take time to exclude
the unneeded 0xII byte, because it just gets shifted out anyway! It also avoids
multiple occurrences of `unsafe`.

There's a similar story with the setting of `self.tail` at the method's end.
The current code uses `u8to64_le` to extract the remaining part of the input,
but the same effect can be achieved more quickly with a right shift on the
zero-extended input.

All that works on little-endian. It doesn't work for big-endian, but we
can just do a `to_le` before calling `short_write` and then it works.

This commit changes `SipHasher128` to use the simpler shift-based approach. The
code is also smaller, which means that `short_write` is now inlined where
previously it wasn't, which makes things faster again. This gives big
speed-ups for all incremental builds, especially "baseline" incremental
builds.

Allows parallel install of different rust channels

Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>

These methods explicitly check if a char is in a specific ASCII range,
therefore the `is_ascii()` check is not needed, but LLVM seems to be
unable to remove it.

WARNING: this change improves the performance on ASCII `char`s, but
complex checks such as `is_ascii_punctuation` become slower on
non-ASCII `char`s.

This makes it faster and also changes it to a safe function. (Thanks to
Michael Woerister for the suggestion.) `load_int_le!` is also no longer
necessary.

See servo/servo#25550.

…r=Amanieu

Improve `char::is_ascii_*` codegen

This PR is an attempt to fix rust-lang#65127

A couple of warnings:
 1. the generated code might be further improved (in LLVM and/or MIR) by emitting better comparison sequences; in particular, this would improve the performance of "complex" checks such as those in `is_ascii_punctuation`
 2. the second commit is currently marked "DO NOT MERGE", because it regresses SIMD on `u8` slices; this could likely be fixed by improving the computation/usage of demanded bits in LLVM

An alternative approach to remove the code duplication might be the use of macros, but currently most of the duplication is actually in the doc comments, so maybe just keeping the redundancy could be ok

…r=michaelwoerister

Speed up `SipHasher128`.

The current code in `SipHasher128::short_write` is inefficient. It uses
`u8to64_le` (which is complex and slow) to extract just the right number of
bytes of the input into a u64 and pad the result with zeroes. It then
left-shifts that value in order to bitwise-OR it with `self.tail`.

For example, imagine we have a u32 input `0xIIHH_GGFF` and only need three bytes
to fill up `self.tail`. The current code uses `u8to64_le` to construct
`0x0000_0000_00HH_GGFF`, which is just `0xIIHH_GGFF` with the `0xII` removed and
zero-extended to a u64. The code then left-shifts that value by five bytes --
discarding the `0x00` byte that replaced the `0xII` byte! -- to give
`0xHHGG_FF00_0000_0000`. It then then ORs that value with `self.tail`.

There's a much simpler way to do it: zero-extend to u64 first, then left shift.
E.g. `0xIIHH_GGFF` is zero-extended to `0x0000_0000_IIHH_GGFF`, and then
left-shifted to `0xHHGG_FF00_0000_0000`. We don't have to take time to exclude
the unneeded `0xII` byte, because it just gets shifted out anyway! It also avoids
multiple occurrences of `unsafe`.

There's a similar story with the setting of `self.tail` at the method's end.
The current code uses `u8to64_le` to extract the remaining part of the input,
but the same effect can be achieved more quickly with a right shift on the
zero-extended input.

This commit changes `SipHasher128` to use the simpler shift-based approach. The
code is also smaller, which means that `short_write` is now inlined where
previously it wasn't, which makes things faster again. This gives big
speed-ups for all incremental builds, especially "baseline" incremental
builds.

r? @michaelwoerister

…-Simulacrum

rustbuild: include channel in sanitizers installed name

Allows parallel install of different rust channels.

I'm not sure if the channel is the right thing to use there, but currently both beta and nightly try to install e.g. `/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_rt.asan.a` when before (and in current stable) it used to be `/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_asan-45a4390180e83d28.rlib` which contained a hash, making it unique.
With this patch, `/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-nightly_rt.asan.a` gets installed

…t-lang#69017, r=petrochenkov

ICE in nightly-2020-02-08: handle TerminatorKind::Yield in librustc_mir::transform::promote_consts::Validator method

IR: rust-lang#69017
regressed commit: rust-lang@f8fd462
Source: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=55e65a869e1f5fef64cc4462b1a5a087

Addresses ICE reported in rust-lang#69017 by handling `TerminatorKind::Yield` in https://github.com/rust-lang/rust/blob/4d1241f5158ffd66730e094d8f199ed654ed52ae/src/librustc_mir/transform/promote_consts.rs#L465-L468.

<details><summary>Nightly build</summary>
<p>

```
$ cargo +nightly build
Compiling yielder v0.1.0 (/Users/chris/Desktop/tests/rustlang-tests/yielder)
error: internal compiler error: src/librustc_mir/transform/promote_consts.rs:467: _1 = suspend(move _21) -> [resume: bb2, drop: bb3] not promotable
 --> src/main.rs:8:27
  |
8 |         println!("-> {}", yield);
  |                           ^^^^^

thread 'rustc' panicked at 'Box<Any>', <::std::macros::panic macros>:2:4
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.43.0-nightly (71c7e14 2020-02-09) running on x86_64-apple-darwin

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

error: aborting due to previous error

error: could not compile `yielder`.

To learn more, run the command again with --verbose.
```

</p>
</details>

<details><summary>Stage 1 dev build</summary>
<p>

```
$ cargo +stage1 build
Compiling yielder v0.1.0 (/Users/chris/Desktop/tests/rustlang-tests/yielder)
warning: function is never used: `gen`
 --> src/main.rs:6:4
  |
6 | fn gen() -> impl Generator<usize> {
  |    ^^^
  |
  = note: `#[warn(dead_code)]` on by default

    Finished dev [unoptimized + debuginfo] target(s) in 0.53s
```

</p>
</details>

@jonas-schievink @oli-obk

parser: Remove `Parser::prev_token_kind`

Follow-up to rust-lang#69006.
r? @Centril

Remove backtrace header text

Fixes point 3 from rust-lang#65280

related to rust-lang#53487

This should probably be double checked by someone who works on fuschia because theres some extra fuschia specific output in `add_context` that is also removed by this change.

Remove a few unused objects

As far as I can tell, these won't be missed:

- `infer::region_constraints::ConstraintInfo`
- `driver::DefaultCallbacks`
- ~~`hir::intravisit::ParDeepVisitor`~~

Properly use the darwin archive format on Apple targets

See servo/servo#25550.