This has been bugging me. All the regions appear free in the source;
the real difference is that some of them are universally quantified
(those in the function signature) and some are existentially
quantified (those for which we are inferring values).

Previously the code was somewhat duplicated.

No reason for it to live on `Inherited`.

We now visit just the stuff in the CFG, and we add liveness
constraints for all the random types, regions etc that appear within
rvalues and statements.

Now it can be reused by the NLL code.

This revealed some shortcomings, one of which is fixed. Fixes #45937.

This should be more efficient than allocating two BTreeSets for every
region variable?—as it is written in #45670.

In particular, if we see a variable is DROP-LIVE, but it is not
MAYBE-INIT, then we can ignore the drop. This leavess attempt to use
more complex refinements of the idea (e.g., for subpaths or subfields)
to future work.

Rather than declaring some region variables to be constant, and
reporting errors when they would have to change, we instead populate
each free region X with a minimal set of points (the CFG plus end(X)),
and then we let inference do its thing. This may add other `end(Y)`
points into X; we can then check after the fact that indeed `X: Y`
holds.

This requires a bit of "blame" detection to find where the bad
constraint came from: we are currently using a pretty dumb
algorithm. Good place for later expansion.

It will be useful later for diagnostics to be able to remember where
things were live.

Add a specialization of read_exact for Cursor.

The read_exact implementation for &[u8] is optimized and usually allows LLVM to reduce a read_exact call for small numbers of bytes to a bounds check and a register load instead of a generic memcpy.  On a workload I have that decompresses, deserializes (via bincode), and processes some data, this leads to a 40% speedup by essentially eliminating the deserialization overhead entirely.

The read_exact implementation for &[u8] is optimized and usually allows LLVM to reduce a read_exact call for small numbers of bytes to a bounds check and a register load instead of a generic memcpy.  On a workload I have that decompresses, deserializes (via bincode), and processes some data, this leads to a 40% speedup by essentially eliminating the deserialization overhead entirely.

Rollup of 8 pull requests

- Successful merges: #45957, #46260, #46432, #46442, #46454, #46462, #46465, #46473
- Failed merges:

Consistent parameter name for numeric ‘checked’ operations.

Some checked operations use `rhs` as a parameter name, and some use
`other`. For the sake of consistency, unify everything under the `rhs`
name.

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

Fix invalid link to lint_plugin_test.rs

The path to `lint_plugin_test.rs` was moved to `src/test/ui-fulldeps/`
from `src/test/run-pass-fulldeps/` in https://github.com/rust-lang/rust/commit/38ef85696dce84d5e6aff171cbf91d396678cbe0

This patch updates it in the docs.

Fix CopyPropagation regression (2)

Remaining part of MIR copyprop regression by (I think) #45380, which I missed in #45753.

```rust
fn foo(mut x: i32) -> i32 {
    let y = x;
    x = 123; // `x` is assigned only once in MIR, but cannot be propagated to `y`
    y
}
```

So any assignment to an argument cannot be propagated.

Fix search results overlap

Fixes #46434.

r? @QuietMisdreavus

Remove an unstable and dead compiler flag

The last use has been removed by commit fb9ca16b .

Fix documentation for DecodeUtf16Error

Fixes #46307

Make doc stubs for builtin macros reflect existing support for trailing commas

This modifies the `macro_rules!` stubs in `std` for some of the compiler builtin macros in order to better reflect their currently supported grammar.  To my understanding these stubs have no impact on compiler output whatsoever, and only exist so that they may appear in the documentation.

P.S. It is in fact true that `env!` supports trailing commas while `option_env!` currently does not.  (I have another issue for this)

I don't imagine there's any way to automatically test these stubs, but I did *informally* test the new definitions on the playpen to see that they accept the desired invocations, as well as inspect the updated doc output.

Use more convenient and UNIX-agnostic shebang

When using bash-specific features, scripts using env to call bash
are more convenient, as bash be installed in different places
according the OS.

Assume at least LLVM 3.9 in rustllvm and rustc_llvm

We bumped the minimum LLVM to 3.9 in #45326.  This just cleans up the conditional code in the `rustllvm` C++ wrappers to assume that minimum, and similarly cleans up the `rustc_llvm` build script.

[auto-toolstate][2+3/8] Move external tools tests into its own job with --no-fail-fast

This PR performs these  things:

1. The `aux` job now performs "cargotest" and "pretty" tests. The clippy/rustfmt/rls/miri tests are moved into its own job.
2. These tests are run with `--no-fail-fast`, so that we can get the maximum number of failures of all tools from a single CI run.
3. The test results are stored into a JSON file, ready to be uploaded in the future.

This is step 2 and 3/8 of automatic management of broken tools #45861.

Some checked operations use `rhs` as a parameter name, and some use
`other`. For the sake of consistency, unify everything under the `rhs`
name.

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

create a drop ladder for an array if any value is moved out

r? @arielb1
first commit for fix https://github.com/rust-lang/rust/issues/34708 (note: this still handles the subslice case in a very broken manner)

Always unwind through a Resume and other fixes

Should fix most of the small MIR borrowck issues.

r? @nikomatsakis