Run toolstate jobs when src/tools/rustfmt is modified.

Previously, this would be caught by a change for modified submodules;
now that rustfmt is no longer a submodule, the check needs to be
explicit.

Update log to 0.4.14

This avoids the following warning:

```
warning: trailing semicolon in macro used in expression position
   --> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.11/src/macros.rs:152:45
    |
147 | / macro_rules! debug {
148 | |     (target: $target:expr, $($arg:tt)+) => (
149 | |         log!(target: $target, $crate::Level::Debug, $($arg)+);
150 | |     );
151 | |     ($($arg:tt)+) => (
152 | |         log!($crate::Level::Debug, $($arg)+);
    | |                                             ^
153 | |     )
154 | | }
    | |_- in this expansion of `debug!`
    |
   ::: src/tools/rustfmt/src/modules/visitor.rs:36:23
    |
36  |               Err(e) => debug!("{}", e),
    |                         --------------- in this macro invocation
    |
    = note: requested on the command line with `-W semicolon-in-expressions-from-macros`
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
```

Don't copy tool dependencies to the sysroot

This fixes the following error:

```
error: found crates (`serde_derive` and `serde_derive`) with colliding StableCrateId values.
   --> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/cargo_metadata-0.8.2/src/lib.rs:162:1
    |
162 | extern crate serde_derive;
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^
```

This is a bug in resolve (https://github.com/rust-lang/rust/issues/56935)
but it will be difficult to fix in the near future. This works around it
in the meantime by not copying serde_derive and other dependencies to
the sysroot when they're built for other tools. This rebuilds the
dependencies slightly more often than necessary, but avoids the crate
conflicts.

This can be reverted once #56935 is fixed.

Update bootstrap for in-tree rustfmt

- Add rustfmt to `x.py check`
- Update Cargo.lock
- Remove rustfmt from the toolstate list
- Make rustfmt an in-tree tool
- Give an error on `x.py test rustfmt` if rustfmt fails to build or if tests fail
- Don't call `save_toolstate` when testing rustfmt

Add 'src/tools/rustfmt/' from commit '7872306edf2e11a69aaffb9434088fd66b46a863'

git-subtree-dir: src/tools/rustfmt
git-subtree-mainline: e659b6de9170c055b6f2d16e2679b22d67297b13
git-subtree-split: 7872306edf2e11a69aaffb9434088fd66b46a863

Delete rustfmt submodule

add rustfmt crlf files to root gitattributes

chore: update gitattributes for files with windows style line endings

Auto merge of #85211 - Aaron1011:metadata-invalid-span, r=michaelwoerister

Preserve `SyntaxContext` for invalid/dummy spans in crate metadata

Fixes #85197

We already preserved the `SyntaxContext` for invalid/dummy spans in the
incremental cache, but we weren't doing the same for crate metadata.
If an invalid (lo/hi from different files) span is written to the
incremental cache, we will decode it with a 'dummy' location, but keep
the original `SyntaxContext`. Since the crate metadata encoder was only
checking for `DUMMY_SP` (dummy location + root `SyntaxContext`),
the metadata encoder would treat it as a normal span, encoding the
`SyntaxContext`. As a result, the final span encoded to the metadata
would change across sessions, even if the crate itself was unchanged.

This could lead to an 'unstable fingerprint' ICE under the following conditions:
1. We compile a crate with an invalid span using incremental compilation. The metadata encoder discards the `SyntaxContext` since the span is invalid, while the incremental cache encoder preserves the `SyntaxContext`
2. From another crate, we execute a foreign query, decoding the invalid span from the metadata as `DUMMY_SP` (e.g. with `SyntaxContext::root()`). This span gets hashed into the query fingerprint. So far, this has always happened through the `optimized_mir` query.
3. We recompile the first crate using our populated incremental cache, without changing anything. We load the (previously) invalid span from our incremental cache - it gets converted to a span with a dummy (but valid) location, along with the original `SyntaxContext`. This span gets written out to the crate metadata - since it now has a valid location, we preserve its `SyntaxContext`.
4. We recompile the second crate, again using a populated incremental cache. We now re-run the foreign query `optimized_mir` - the foreign crate hash is unchanged, but we end up decoding a different span (it now ha a non-root `SyntaxContext`). This results in the fingerprint changing, resulting in an ICE.

This PR updates our encoding of spans in the crate metadata to mirror
the encoding of spans into the incremental cache. We now always encode a
`SyntaxContext`, and encode location information for spans with a
non-dummy location.

Auto merge of #83640 - bjorn3:shared_metadata_reader, r=nagisa

Use the object crate for metadata reading

This allows sharing the metadata reader between cg_llvm, cg_clif and other codegen backends.

This is not currently useful for rlib reading with cg_spirv ([rust-gpu](https://github.com/EmbarkStudios/rust-gpu/)) as it uses tar rather than ar as .rlib format, but it is useful for dylib reading required for loading proc macros. (cc `@eddyb)`

The object crate is already trusted as dependency of libstd through backtrace. As far as I know it supports reading all object file formats used by targets for which we support rust dylibs with crate metadata, but I am not certain. If this happens to not be the case, I could keep using LLVM for reading dylib metadata.

Marked as WIP for a perf run and as it is based on #83637.

Auto merge of #85236 - nikic:update-llvm-submodule, r=cuviper

Update LLVM submodule

This merges recent changes from the upstream LLVM 12 branch. One of them is intended to address #84958.

Auto merge of #85233 - FabianWolff:issue-85227, r=petrochenkov

Improve error message for non-exhaustive matches on non-exhaustive enums

This pull request fixes #85227. For an enum marked with `#[non_exhaustive]` and not defined in the current crate, the error message for non-exhaustive matches now mentions the fact that the enum is marked as non-exhaustive:
```
error[E0004]: non-exhaustive patterns: `_` not covered
  --> main.rs:12:11
   |
12 |     match e {
   |           ^ pattern `_` not covered
   |
   = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
   = note: the matched value is of type `E`, which is marked as non-exhaustive
```

Auto merge of #85190 - mati865:update-cc, r=Mark-Simulacrum

Update cc crate

To pull in this fix: https://github.com/alexcrichton/cc-rs/commit/801a87bf2f31ad1ad8bd7e8fa4f5a52b0e2b4c00

Auto merge of #85195 - Mark-Simulacrum:variant-by-idx, r=petrochenkov

Store VariantIdx to distinguish enum variants

This saves ~24% of the instructions on the match-stress-enum benchmark, but I'm not 100% sure that this is OK - if we ever compare two constructors across enums (e.g., a Result and an Option), then this is obviously insufficient; I can experiment with continuing to store the DefId for comparison purposes in that case.

Auto merge of #84107 - Amanieu:global_asm2, r=nagisa

Add support for const operands and options to global_asm!

On x86, the default syntax is also switched to Intel to match asm!.

Currently `global_asm!` only supports `const` operands and the `att_syntax` option. In the future, `sym` operands will also be supported. However there is no plan to support any of the other operand types or options since they don't make sense in the context of `global_asm!`.

r? `@nagisa`

Fix tests

Update compiler_builtins to 0.1.43

global_asm! consts do not depend on other items

Clarify error message when both asm! and global_asm! are unsupported

Update global_asm! documentation

Add tests for global_asm!

Add support for const operands and options to global_asm!

On x86, the default syntax is also switched to Intel to match asm!

Auto merge of #85186 - nikomatsakis:issue-83538-polluted-cache, r=jackh726

have on_completion record subcycles

have on_completion record subcycles

Rework `on_completion` method so that it removes all
provisional cache entries that are "below" a completed
node (while leaving those entries that are not below
the node).

This corrects an imprecise result that could in turn lead
to an incremental compilation failure. Under the old
scheme, if you had:

* A depends on...
   * B depends on A
   * C depends on...
       * D depends on C
 * T: 'static

then the provisional results for A, B, C, and D would all
be entangled. Thus, if A was `EvaluatedToOkModuloRegions`
(because of that final condition), then the result for C and
D would also be demoted to "ok modulo regions".

In reality, though, the result for C depends only on C and itself,
and is not dependent on regions. If we happen to evaluate the
cycle starting from C, we would never reach A, and hence the
result would be "ok".

Under the new scheme, the provisional results for C and D
are moved to the permanent cache immediately and are not affected
by the result of A.

Fixes #83538

r? `@Aaron1011`

Auto merge of #85258 - GuillaumeGomez:rollup-kzay7o5, r=GuillaumeGomez

Rollup of 4 pull requests

Successful merges:

 - #85068 (Fix diagnostic for cross crate private tuple struct constructors)
 - #85175 (Rustdoc cleanup)
 - #85177 (add BITS associated constant to core::num::Wrapping)
 - #85240 (Don't suggest adding `'static` lifetime to arguments)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #85240 - Aaron1011:no-suggest-static, r=davidtwco

Don't suggest adding `'static` lifetime to arguments

Fixes #69350

This is almost always the wrong this to do

Rollup merge of #85177 - tspiteri:wrapping-bits, r=joshtriplett

add BITS associated constant to core::num::Wrapping

This keeps `Wrapping` synchronized with the primitives it wraps as for the #32463 `wrapping_int_impl` feature.

Rollup merge of #85175 - GuillaumeGomez:rustdoc-cleanup, r=jsha

Rustdoc cleanup

Part of https://github.com/rust-lang/rust/issues/83332. The goal of this PR is to remove a few unused things:

 * The "loading content" things are now unneeded.
 * Some toggle CSS rules were still there.
 * Some parts of the JS had a different indent, fixed it.

r? `@jsha`

Rollup merge of #85068 - luqmana:78708-xcrate-diag, r=estebank

Fix diagnostic for cross crate private tuple struct constructors

Fixes #78708.

There was already some limited support for certain cross-crate scenarios but that didn't handle a tuple struct rexported from an inner module for example (e.g. the NonZero* types as seen in #85049).

```Rust
➜  cat bug.rs
fn main() {
    let _x = std::num::NonZeroU32(12);
    let n = std::num::NonZeroU32::new(1).unwrap();
    match n {
        std::num::NonZeroU32(i) => {},
    }
}
```

**Before:**
<details>

```Rust
➜  rustc +nightly bug.rs
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::num::NonZeroU32`
   --> bug.rs:2:14
    |
2   |       let _x = std::num::NonZeroU32(12);
    |                ^^^^^^^^^^^^^^^^^^^^^^^^ help: use struct literal syntax instead: `std::num::NonZeroU32 { 0: val }`
    |
   ::: /home/luqman/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/nonzero.rs:148:1
[snip]
error[E0532]: expected tuple struct or tuple variant, found struct `std::num::NonZeroU32`
   --> bug.rs:5:9
    |
5   |           std::num::NonZeroU32(i) => {},
    |           ^^^^^^^^^^^^^^^^^^^^^^^ help: use struct pattern syntax instead: `std::num::NonZeroU32 { 0 }`
    |
   ::: /home/luqman/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/nonzero.rs:148:1
[snip]

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0423, E0532.
For more information about an error, try `rustc --explain E0423`.
```
</details>

**After:**
<details>

```Rust
➜  /rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc bug.rs
error[E0423]: cannot initialize a tuple struct which contains private fields
   --> bug.rs:2:14
    |
2   |     let _x = std::num::NonZeroU32(12);
    |              ^^^^^^^^^^^^^^^^^^^^
    |
note: constructor is not visible here due to private fields
   --> /rust/library/core/src/num/nonzero.rs:148:1
[snip]
error[E0532]: cannot match against a tuple struct which contains private fields
 --> bug.rs:5:9
  |
5 |         std::num::NonZeroU32(i) => {},
  |         ^^^^^^^^^^^^^^^^^^^^
  |
note: constructor is not visible here due to private fields
 --> bug.rs:5:30
  |
5 |         std::num::NonZeroU32(i) => {},
  |                              ^ private field

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0423, E0532.
For more information about an error, try `rustc --explain E0423`.
```
</details>

One question is if we should only collect the needed info for the cross-crate case after encountering an error instead of always doing it. Perf run perhaps to gauge the impact.

Auto merge of #85110 - RalfJung:no-rustc_args_required_const, r=oli-obk

Remove rustc_args_required_const attribute

Now that stdarch no longer needs it (thanks `@Amanieu!),` we can kill the `rustc_args_required_const` attribute. This means that lifetime extension of references to temporaries is the only remaining job that promotion is performing. :-)

r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/69493

fix test suite

update stdarch

Use DefaultMetadataLoader in the hotplug_codegen_backend test

Auto merge of #83129 - LeSeulArtichaut:thir-unsafeck, r=nikomatsakis

Introduce the beginning of a THIR unsafety checker

This poses the foundations for the THIR unsafety checker, so that it can be implemented incrementally:
- implements a rudimentary `Visitor` for the THIR (which will definitely need some tweaking in the future)
- introduces a new `-Zthir-unsafeck` flag which tells the compiler to use THIR unsafeck instead of MIR unsafeck
- implements detection of unsafe functions
- adds revisions to the UI tests to test THIR unsafeck alongside MIR unsafeck

This uses a very simple query design, where bodies are unsafety-checked on a body per body basis. This however has some big flaws:
- the unsafety-checker builds the THIR itself, which means a lot of work is duplicated with MIR building constructing its own copy of the THIR
- unsafety-checking closures is currently completely wrong: closures should take into account the "safety context" in which they are created, here we are considering that closures are always a safe context

I had intended to fix these problems in follow-up PRs since they are always gated under the `-Zthir-unsafeck` flag (which is explicitely noted to be unsound).

r? `@nikomatsakis`
cc https://github.com/rust-lang/project-thir-unsafeck/issues/3 https://github.com/rust-lang/project-thir-unsafeck/issues/7

have on_completion record subcycles

Rework `on_completion` method so that it removes all
provisional cache entries that are "below" a completed
node (while leaving those entries that are not below
the node).

This corrects an imprecise result that could in turn lead
to an incremental compilation failure. Under the old
scheme, if you had:

* A depends on...
     * B depends on A
     * C depends on...
         * D depends on C
     * T: 'static

then the provisional results for A, B, C, and D would all
be entangled. Thus, if A was `EvaluatedToOkModuloRegions`
(because of that final condition), then the result for C and
D would also be demoted to "ok modulo regions".

In reality, though, the result for C depends only on C and itself,
and is not dependent on regions. If we happen to evaluate the
cycle starting from C, we would never reach A, and hence the
result would be "ok".

Under the new scheme, the provisional results for C and D
are moved to the permanent cache immediately and are not affected
by the result of A.

introduce a unit testing feature `rustc_evaluate_where_clauses`

This attribute will cause us to invoke evaluate on every where clause of an
invoked function and to generate an error with the result.

Without this, it is very difficult to observe the effects of invoking the trait
evaluator.

Auto merge of #85041 - mibac138:suggest-generics, r=estebank

Suggest adding a type parameter for impls

Add a new suggestion upon encountering an unknown type in a `impl` that suggests adding a new type parameter. This diagnostic suggests to add a new type parameter even though it may be a const parameter, however after adding the parameter and running rustc again a follow up error steers the user to change the type parameter to a const parameter.

```rust
struct X<const C: ()>();
impl X<C> {}
```
suggests
```
error[E0412]: cannot find type `C` in this scope
 --> bar.rs:2:8
  |
1 | struct X<const C: ()>();
  | ------------------------ similarly named struct `X` defined here
2 | impl X<C> {}
  |        ^
  |
help: a struct with a similar name exists
  |
2 | impl X<X> {}
  |        ^
help: you might be missing a type parameter
  |
2 | impl<C> X<C> {}
  |     ^^^
```
After adding a type parameter the code now becomes
```rust
struct X<const C: ()>();
impl<C> X<C> {}
```
and the error now fully steers the user towards the correct code
```
error[E0747]: type provided when a constant was expected
 --> bar.rs:2:11
  |
2 | impl<C> X<C> {}
  |           ^
  |
help: consider changing this type parameter to be a `const` generic
  |
2 | impl<const C: ()> X<C> {}
  |      ^^^^^^^^^^^
```
r? `@estebank`
Somewhat related #84946

Auto merge of #84732 - DrChat:asm_powerpc, r=Amanieu

Add asm!() support for PowerPC

This includes GPRs and FPRs only.
Note that this does not include PowerPC64.

For my reference, this was mostly duplicated from PR #73214.

Auto merge of #83759 - SkiFire13:fix-diag, r=estebank

Handle more span edge cases in generics diagnostics

This should fix invalid suggestions that didn't account for empty bracket pairs (`<>`) or type bindings.

Bump nightly version

Rename `RealFileName::Named` to `LocalPath`

Only deal with LocalPath in conversion

Rename span_to_string to span_to_diagnostic_string

Don't suggest adding `'static` lifetime to arguments

Fixes #69350

This is almost always the wrong this to do

Auto merge of #82069 - Aaron1011:verbose-in-macro, r=estebank

Show macro name in 'this error originates in macro' message

When there are multiple macros in use, it can be difficult to tell
which one was responsible for producing an error.

Show macro name in 'this error originates in macro' message

When there are multiple macros in use, it can be difficult to tell
which one was responsible for producing an error.

Auto merge of #85218 - kornelski:pointerinline, r=scottmcm

#[inline(always)] on basic pointer methods

Retryng #85201 with only inlining pointer methods. The goal is to make pointers behave just like pointers in O0, mainly to reduce overhead in debug builds.

cc `@scottmcm`

Preserve `SyntaxContext` for invalid/dummy spans in crate metadata

Fixes #85197

We already preserved the `SyntaxContext` for invalid/dummy spans in the
incremental cache, but we weren't doing the same for crate metadata.
If an invalid (lo/hi from different files) span is written to the
incremental cache, we will decode it with a 'dummy' location, but keep
the original `SyntaxContext`. Since the crate metadata encoder was only
checking for `DUMMY_SP` (dummy location + root `SyntaxContext`),
the metadata encoder would treat it as a normal span, encoding the
`SyntaxContext`. As a result, the final span encoded to the metadata
would change across sessions, even if the crate itself was unchanged.

This PR updates our encoding of spans in the crate metadata to mirror
the encoding of spans into the incremental cache. We now always encode a
`SyntaxContext`, and encode location information for spans with a
non-dummy location.

Update LLVM submodule

Auto merge of #85188 - RalfJung:miri, r=RalfJung

update Miri

Fixes https://github.com/rust-lang/rust/issues/85179
Cc `@rust-lang/miri` r? `@ghost`

update Miri

Improve error message for non-exhaustive matches on non-exhaustive enums

Auto merge of #85231 - GuillaumeGomez:rollup-hufe4gz, r=GuillaumeGomez

Rollup of 5 pull requests

Successful merges:

 - #84793 (Recover from invalid `struct` item syntax)
 - #85117 (Move global click handlers to per-element ones.)
 - #85141 (Update documentation for SharedContext::maybe_collapsed_doc_value)
 - #85174 (Fix border radius for doc code blocks in rustdoc)
 - #85205 (Update books)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #85205 - ehuss:update-books, r=ehuss

Update books

## nomicon

4 commits in 8551afbb2ca6f5ea37fe58380318b209785e4e02..55de6fa3c1f331774da19472c9ee57d2ae9eb039
2021-04-01 21:58:50 +0900 to 2021-05-12 00:31:01 +0900
- Clarify some of the language around marking traits safe/unsafe. (rust-lang-nursery/nomicon#268)
- Use pointer 'add' instead of 'offset' (rust-lang-nursery/nomicon#265)
- Adjust Vec to build on stable Rust (rust-lang-nursery/nomicon#223)
- Update link to c++ atomic ordering docs (rust-lang-nursery/nomicon#264)

## reference

3 commits in d23f9da8469617e6c81121d9fd123443df70595d..5aa457bf1b54bd2cd5d4cf49797f29299bdf89a7
2021-04-28 11:16:44 -0700 to 2021-05-05 08:39:22 -0700
- Explicitly state result of compound assignment (rust-lang-nursery/reference#1013)
- Adjust the definition of `target_family` (rust-lang-nursery/reference#1006)
- Fix typo in `Traits` (rust-lang-nursery/reference#1012)

## book

2 commits in 50dd06cb71beb27fdc0eebade5509cdcc1f821ed..55a26488ddefc8433e73a2e8352d70f7a5c7fc2b
2021-04-23 13:21:54 -0500 to 2021-05-09 12:03:18 -0500
- Past-tensify "lead" -&gt; "led" (rust-lang/book#2717)
- Merge pull request rust-lang/book#2718 from rust-lang/update-rustc

## rust-by-example

2 commits in e0a721f5202e6d9bec0aff99f10e44480c0da9e7..5f8c6da200ada77760a2fe1096938ef58151c9a6
2021-04-27 09:32:15 -0300 to 2021-04-29 08:08:01 -0300
- Fix Typo in LRBE section; closes rust-lang/rust-by-example#1434 (rust-lang/rust-by-example#1437)
- Add some tests to cargo/test.md. Partially addresses rust-lang/rust-by-example#1304 (rust-lang/rust-by-example#1438)

## rustc-dev-guide

3 commits in e72b43a64925ce053dc7830e21c1a57ba00499bd..1e6c7fbda4c45e85adf63ff3f82fa9c870b1447f
2021-04-27 12:35:37 -0700 to 2021-05-10 13:38:24 +0900
- Unified CPU Requirements (rust-lang/rustc-dev-guide#1126)
- add 'waiting-for-review' incantation to main contrib page (rust-lang/rustc-dev-guide#1124)
- Link to Zulip search for finding the most recent check-in (rust-lang/rustc-dev-guide#1118)

Rollup merge of #85174 - GuillaumeGomez:doc-code-block-border-radius, r=jsha

Fix border radius for doc code blocks in rustdoc

In #85148, I made an invalid change on the border radius of the doc code blocks (look in the top left and bottom left corners of the code blocks).

Before this fix:


After this fix:


r? `@jsha`

Rollup merge of #85141 - GuillaumeGomez:maybe_collapsed_doc_value-doc, r=jsha

Update documentation for SharedContext::maybe_collapsed_doc_value

Fixes #85120.

The `doc-collapse` was removed, however, the main crate is always "collapsed", meaning that this function is still needed. I updated the documentation instead to avoid misleading readers.

r? `@jsha`

Rollup merge of #85117 - jsha:bubble-bubble-toil-and-trouble, r=GuillaumeGomez

Move global click handlers to per-element ones.

In rustdoc's main.js, we had an onclick handler for the whole document that would dispatch to handlers for various elements. This change attaches the handlers to the elements that trigger them, instead. This simplifies the code and avoids reimplementing the browser's bubbling functionality.

As part of this change, change from a class to an id for help button.

Move the handlers and associated code for highlighting source lines into source-script.js (and factor out a shared regex).

Demo at https://hoffman-andrews.com/rust/bubble-bubble-toil-and-trouble/std/string/struct.String.html

Note: this conflicts with / depends on #85074. Once that's merged I'll rebase this and resolve conflicts.

Part of #83332. Thanks to `@Manishearth` for the [suggestion to not reimplement bubbling](https://github.com/rust-lang/rust/issues/83332#issuecomment-803497509).

r? `@GuillaumeGomez`

Rollup merge of #84793 - estebank:parse-struct-field-default, r=davidtwco

Recover from invalid `struct` item syntax

Parse unsupported "default field const values":

```rust
struct S {
    field: Type = const_val,
}
```

Recover from small `:` typo and provide suggestion:

```rust
struct S {
    field; Type,
    field2= Type,
}
```

add check that simd_shuffle arguments are constants

entirely remove rustc_args_required_const attribute

rustc_args_required_const is no longer a promotion site

Auto merge of #84730 - sexxi-goose:rox-auto-trait, r=nikomatsakis

Add auto traits and clone trait migrations for RFC2229

This PR
- renames the existent RFC2229 migration `disjoint_capture_drop_reorder` to `disjoint_capture_migration`
- add additional migrations for auto traits and clone trait

Closes rust-lang/project-rfc-2229#29
Closes rust-lang/project-rfc-2229#28

r? `@nikomatsakis`

Bless tests

Update wrong-number-of-args test to cover more edge cases

Fix diagnostics spans for missing lifetimes in edge cases

Fix diagnostics spans for missing generics in edge cases

Auto merge of #83813 - cbeuw:remap-std, r=michaelwoerister

Fix `--remap-path-prefix` not correctly remapping `rust-src` component paths and unify handling of path mapping with virtualized paths

This PR fixes #73167 ("Binaries end up containing path to the rust-src component despite `--remap-path-prefix`") by preventing real local filesystem paths from reaching compilation output if the path is supposed to be remapped.

`RealFileName::Named` introduced in #72767 is now renamed as `LocalPath`, because this variant wraps a (most likely) valid local filesystem path.

`RealFileName::Devirtualized` is renamed as `Remapped` to be used for remapped path from a real path via `--remap-path-prefix` argument, as well as real path inferred from a virtualized (during compiler bootstrapping) `/rustc/...` path. The `local_path` field is now an `Option<PathBuf>`, as it will be set to `None` before serialisation, so it never reaches any build output. Attempting to serialise a non-`None` `local_path` will cause an assertion faliure.

When a path is remapped, a `RealFileName::Remapped` variant is created. The original path is preserved in `local_path` field and the remapped path is saved in `virtual_name` field. Previously, the `local_path` is directly modified which goes against its purpose of "suitable for reading from the file system on the local host".

`rustc_span::SourceFile`'s fields `unmapped_path` (introduced by #44940) and `name_was_remapped` (introduced by #41508 when `--remap-path-prefix` feature originally added) are removed, as these two pieces of information can be inferred from the `name` field: if it's anything other than a `FileName::Real(_)`, or if it is a `FileName::Real(RealFileName::LocalPath(_))`, then clearly `name_was_remapped` would've been false and `unmapped_path` would've been `None`. If it is a `FileName::Real(RealFileName::Remapped{local_path, virtual_name})`, then `name_was_remapped` would've been true and `unmapped_path` would've been `Some(local_path)`.

cc `@eddyb` who implemented `/rustc/...` path devirtualisation

Add more precise span informations to generic types

Fix indent in JS files

Remove unused CSS rules

Remove "loading content" which is now unnecessary

#[inline(always)] on basic pointer methods

Auto merge of #83610 - bjorn3:driver_cleanup, r=cjgillot

rustc_driver cleanup

Best reviewed one commit at a time.

Auto merge of #84278 - Aaron1011:feature/new-proc-macro-meta-span, r=estebank

Implement span quoting for proc-macros

This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:

```
error[E0412]: cannot find type `MissingType` in this scope
  --> $DIR/auxiliary/span-from-proc-macro.rs:37:20
   |
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
   | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL |             field: MissingType
   |                    ^^^^^^^^^^^ not found in this scope
   |
  ::: $DIR/span-from-proc-macro.rs:8:1
   |
LL | #[error_from_attribute]
   | ----------------------- in this macro invocation
```

Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`

This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.

This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
  macro to get run. This saves all of the sapns in the input to `quote!`
  into the metadata of *the proc-macro-crate* (which we are currently
  compiling). The `quote!` macro then expands to a call to
  `proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
  and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.

The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.

This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`

Custom quoting currently has a few limitations:

In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.

Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.

Update stderr

The spans generated by `quote!` are (intentionally) no longer all the
same, so I removed that check entirely.

Implement span quoting for proc-macros

This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:

```
error[E0412]: cannot find type `MissingType` in this scope
  --> $DIR/auxiliary/span-from-proc-macro.rs:37:20
   |
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
   | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL |             field: MissingType
   |                    ^^^^^^^^^^^ not found in this scope
   |
  ::: $DIR/span-from-proc-macro.rs:8:1
   |
LL | #[error_from_attribute]
   | ----------------------- in this macro invocation
```

Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`

This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.

This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
  macro to get run. This saves all of the sapns in the input to `quote!`
  into the metadata of *the proc-macro-crate* (which we are currently
  compiling). The `quote!` macro then expands to a call to
  `proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
  and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.

The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.

This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`

Custom quoting currently has a few limitations:

In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.

Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.

Auto merge of #85206 - ehuss:update-cargo, r=ehuss

Update cargo

8 commits in e51522ab3db23b0d8f1de54eb1f0113924896331..070e459c2d8b79c5b2ac5218064e7603329c92ae
2021-05-07 21:29:52 +0000 to 2021-05-11 18:12:23 +0000
- Fix rustdoc warnings (rust-lang/cargo#9468)
- Improve performance of git status check in `cargo package`. (rust-lang/cargo#9478)
- Link to the new rustc tests chapter. (rust-lang/cargo#9477)
- Bump index cache version to deal with semver metadata version mismatch. (rust-lang/cargo#9476)
- Fix Url::into_string deprecation warning (rust-lang/cargo#9475)
- Fix rust-lang/cargo#4482 and rust-lang/cargo#9449: set Fossil ignore and clean settings locally (rust-lang/cargo#9469)
- Improve two error messages (rust-lang/cargo#9472)
- Fix `cargo install` with a semver metadata version. (rust-lang/cargo#9467)

Recover from invalid `struct` item syntax

Parse unsupported "default field const values":

```rust
struct S {
    field: Type = const_val,
}
```

Recover from small `:` typo and provide suggestion:

```rust
struct S {
    field; Type,
    field2= Type,
}
```

Auto merge of #85192 - klensy:bump-deps, r=Mark-Simulacrum

updated deps

filetime v0.2.12 -> v0.2.14
https://github.com/alexcrichton/filetime/compare/0.2.12...0.2.14

socket2 v0.3.16 -> v0.3.19
https://github.com/rust-lang/socket2/commits/v0.3.x

tar v0.4.29 -> v0.4.33
https://github.com/alexcrichton/tar-rs/compare/0.4.29...0.4.33

this drops dependency on redox_syscall 0.1.*

---
measureme v9.1.0 -> v9.1.1
https://github.com/rust-lang/measureme/compare/9.1.0...9.1.1

this drops dependency on memmap v0.7.0

---
version_check v0.9.1 -> v0.9.3
https://github.com/SergioBenitez/version_check/compare/v0.9.1...v0.9.3
fixes version parse

Update cargo

Update books

Add initial asm!() support for PowerPC

This includes GPRs and FPRs only

update cc crate

To pull in this fix: https://github.com/alexcrichton/cc-rs/commit/801a87bf2f31ad1ad8bd7e8fa4f5a52b0e2b4c00

Auto merge of #85199 - JohnTitor:rollup-gz5m06c, r=JohnTitor

Rollup of 8 pull requests

Successful merges:

 - #83501 (rustdoc: Add unstable CLI option to show basic type layout information)
 - #85018 (shrinking the deprecated method span)
 - #85124 (rustdoc: remove explicit boolean comparisons.)
 - #85136 (Change param name (k to key and v to value) in std::env module)
 - #85162 (Fix typo in variable name)
 - #85187 (Use .name_str() to format primitive types in error messages)
 - #85191 (Improve rustdoc gui tester)
 - #85196 (Revert "Auto merge of #84797 - richkadel:cover-unreachable-statements…)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #85196 - richkadel:reverts-cover-unreachable-statements, r=tmandry

Revert "Auto merge of #84797 - richkadel:cover-unreachable-statements…

This reverts commit e5f83d24aee866a14753a7cedbb4e301dfe5bef5, reversing
changes made to ac888e8675182c703c2cd097957878faf88dad94.

See https://github.com/rust-lang/rust/pull/84797#issuecomment-839068132

r? `@tmandry`

Rollup merge of #85191 - GuillaumeGomez:improve-rustdoc-gui-tester, r=Mark-Simulacrum

Improve rustdoc gui tester

I cherry-picked the commit from https://github.com/rust-lang/rust/pull/84834 (and modified it a bit). I also used this opportunity to update it to last version (forgot to update GUI test in https://github.com/rust-lang/rust/pull/85074, really can't wait to make https://github.com/rust-lang/rust/pull/84586 finally work).

cc `@Mark-Simulacrum` for the changes in bootstrap.

r? `@jsha`

Rollup merge of #85187 - FabianWolff:issue-84976, r=jackh726

Use .name_str() to format primitive types in error messages

This pull request fixes #84976. The problem described there is caused by this code
https://github.com/rust-lang/rust/blob/506e75cbf8cb5305e49a41326307004ca3976029/compiler/rustc_middle/src/ty/error.rs#L161-L166
using `Debug` formatting (`{:?}`), while the proper solution is to call `name_str()` of `ty::IntTy`, `ty::UintTy` and `ty::FloatTy`, respectively.

Rollup merge of #85162 - LingMan:patch-1, r=varkor

Fix typo in variable name

All other sibling functions call this variable "slot", so "slote" was most likely a typo.

Rollup merge of #85136 - shirshak55:master, r=dtolnay

Change param name (k to key and v to value) in std::env module

1. When I was reading code the ide displayed `k` and `v`, so I
thought it would be better to show key and value?

2. I noticed var method already uses `key` instead of `k` so it
is more consistent to use `key` instead of `k`?

Thanks

Rollup merge of #85124 - jsha:trust-the-bool, r=GuillaumeGomez

rustdoc: remove explicit boolean comparisons.

For boolean variables it's shorter and more readable to check the value directly, or negate it with `!`.

In a couple of cases I reordered an if/else pair because it made the initial `if` statement simpler.

An example of a style guide recommending this: https://airbnb.io/javascript/#comparison--shortcuts

r? `@GuillaumeGomez`

Rollup merge of #85018 - hi-rustin:rustin-patch-84637, r=estebank

shrinking the deprecated method span

close https://github.com/rust-lang/rust/issues/84637

Rollup merge of #83501 - camelid:rustdoc-layout, r=jyn514,GuillaumeGomez

rustdoc: Add unstable CLI option to show basic type layout information

Closes #75988.

Right now it just shows the size.

Move global click handlers to per-element ones.

In rustdoc's main.js, we had an onclick handler for the whole document
that would dispatch to handlers for various elements. This change
attaches the handlers to the elements that trigger them, instead.
This simplfies the code and avoids reimplementing the browser's bubbling
functionality.

As part of this change, change from a class to an id for help button.

Move the handlers and associated code for highlighting source lines into
source-script.js (and factor out a shared regex).

Add explanatory comment to the issue-84976.rs test case

Revert "Auto merge of #84797 - richkadel:cover-unreachable-statements, r=tmandry"

This reverts commit e5f83d24aee866a14753a7cedbb4e301dfe5bef5, reversing
changes made to ac888e8675182c703c2cd097957878faf88dad94.

Store VariantIdx to distinguish enum variants

This saves ~24% of the instructions on the match-stress-enum benchmark.

Auto merge of #84904 - ssomers:btree_drop_kv_in_place, r=Mark-Simulacrum

BTree: no longer copy keys and values before dropping them

When dropping BTreeMap or BTreeSet instances, keys-value pairs are up to now each copied and then dropped, at least according to source code. This is because the code for dropping and for iterators is shared.

This PR postpones the treatment of doomed key-value pairs from the intermediate functions `deallocating_next`(`_back`) to the last minute, so the we can drop the keys and values in place. According to the library/alloc benchmarks, this does make a difference, (and a positive difference with an `#[inline]` on `drop_key_val`). It does not change anything for #81444 though.

r? `@Mark-Simulacrum`

fix tidy

Make rustdoc-gui test suite able to run with different sub directories

updated deps

Update toggle-docs GUI test to last version