Add test for remap-from in the form of $PWD/trailing

Auto merge of #85304 - Stupremee:crates-in-sidebar-in-root, r=Nemo157

rustdoc: Call `initSidebarItems` in root module of crate

r? `@jsha`

Resolves #85301

Auto merge of #85279 - DrChat:asm_powerpc64, r=Amanieu

Add asm!() support for PowerPC64

I was anticipating this to be difficult so I didn't do it as part of #84732... but this was pretty easy to do 👀

Auto merge of #85259 - Smittyvb:thir-unsafeck-inline-asm, r=nikomatsakis

Check for inline assembly in THIR unsafeck

#83129 was merged recently and added a THIR unsafe checker. This adds a check for inline assembly. (and this is 2x simpler than the MIR version, which has to check for `asm` and `llvm_asm` in two separate spots!)

 see also rust-lang/project-thir-unsafeck#7

Auto merge of #81858 - ijackson:fork-no-unwind, r=m-ou-se

Do not allocate or unwind after fork

### Objective scenarios

 * Make (simple) panics safe in `Command::pre_exec_hook`, including most `panic!` calls, `Option::unwrap`, and array bounds check failures.
 * Make it possible to `libc::fork` and then safely panic in the child (needed for the above, but this requirement means exposing the new raw hook API which the `Command` implementation needs).
 * In singlethreaded programs, where panic in `pre_exec_hook` is already memory-safe, prevent the double-unwinding malfunction #79740.

I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe`, beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural.

#### Approach

 * Provide a way for a program to, at runtime, switch to having panics abort.  This makes it possible to panic without making *any* heap allocations, which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370, and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)).
 * Make that change in the child spawned by `Command`.
 * Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code.
 * Test that this all works as expected (and in particular, that there aren't any heap allocations we missed)

Fixes #79740

#### Rejected (or previously attempted) approaches

 * Change the panic machinery to be able to unwind without allocating, at least when the payload and message are both `'static`.  This seems like it would be even more subtle.  Also that is a potentially-hot path which I don't want to mess with.
 * Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook.  This would be a surprising change for existing code and would not be detected by the type system.
 * Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate.  (That was an earlier version of this MR.)

### History

This MR could be considered a v2 of #80263.  Thanks to everyone who commented there.  In particular, thanks to `@m-ou-se,` `@Mark-Simulacrum` and `@hyd-dev.`  (Tagging you since I think you might be interested in this new MR.)  Compared to #80263, this MR has very substantial changes and additions.

Additionally, I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.`

r? `@m-ou-se`

Auto merge of #84920 - Aaron1011:pretty-print-rental, r=petrochenkov

Remove some unncessary spaces from pretty-printed tokenstream output

In addition to making the output look nicer for all crates, this also
aligns the pretty-printing output with what the `rental` crate expects.
This will allow us to eventually disable a backwards-compat hack in a
follow-up PR.

See https://github.com/rust-lang/rust/issues/84428 for some background information about why we want to make this change. Note that this change would be desirable (but not particularly necessary) even if `rental` didn't exist, so we're not adding any crate-specific hacks into the compiler.

Auto merge of #85335 - GuillaumeGomez:rollup-0tvc14g, r=GuillaumeGomez

Rollup of 4 pull requests

Successful merges:

 - #84751 (str::is_char_boundary - slight optimization)
 - #85185 (Generate not more docs than necessary)
 - #85324 (Warn about unused `pub` fields in non-`pub` structs)
 - #85329 (fix version_str comment)

Failed merges:

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

Call `initSidebarItems` in root module of crate

Remove some unncessary spaces from pretty-printed tokenstream output

In addition to making the output look nicer for all crates, this also
aligns the pretty-printing output with what the `rental` crate expects.
This will allow us to eventually disable a backwards-compat hack in a
follow-up PR.

Rollup merge of #85329 - RalfJung:version, r=Mark-Simulacrum

fix version_str comment

This version string is ultimately generated here
https://github.com/rust-lang/rust/blob/87423fbc6af5aae2b5f6d0a11f2a0c60c7c22e98/src/bootstrap/channel.rs#L72
and I don't think it includes the `rustc` prefix. That also matches its use here
https://github.com/rust-lang/rust/blob/ac923d94f86a6f7c881ecbedcd0a68d7986a35bd/compiler/rustc_driver/src/lib.rs#L758

Rollup merge of #85324 - FabianWolff:issue-85255, r=varkor

Warn about unused `pub` fields in non-`pub` structs

This pull request fixes #85255. The current implementation of dead code analysis is too prudent because it marks all `pub` fields of structs as live, even though they cannot be accessed from outside of the current crate if the struct itself only has restricted or private visibility.

I have changed this behavior to take the containing struct's visibility into account when looking at field visibility and liveness. This also makes dead code warnings more consistent; consider the example given in #85255:
```rust
struct Foo {
    a: i32,
    pub b: i32,
}

struct Bar;

impl Bar {
    fn a(&self) -> i32 { 5 }
    pub fn b(&self) -> i32 { 6 }
}

fn main() {
    let _ = Foo { a: 1, b: 2 };
    let _ = Bar;
}
```
Current nightly already warns about `Bar::b()`, even though it is `pub` (but `Bar` is not). It should therefore also warn about `Foo::b`, which it does with the changes in this PR.

Rollup merge of #85185 - GuillaumeGomez:generate-not-more-docs-than-necessary, r=Mark-Simulacrum

Generate not more docs than necessary

This is something that `@Nemo157` was talking about: they wanted that when using `x.py doc std`, it only generated `std` (and the crates "before" it).

r? `@Mark-Simulacrum`

Rollup merge of #84751 - Soveu:is_char_boundary_opt, r=Amanieu

str::is_char_boundary - slight optimization

Current `str::is_char_boundary` implementation emits slightly more instructions, because it includes an additional branch for `index == s.len()`
```rust
pub fn is_char_boundary(s: &str, index: usize) -> bool {
    if index == 0 || index == s.len() {
        return true;
    }
    match s.as_bytes().get(index) {
        None => false,
        Some(&b) => (b as i8) >= -0x40,
    }
}
```
Just changing the place of `index == s.len()` merges it with `index < s.len()` from `s.as_bytes().get(index)`
```rust
pub fn is_char_boundary2(s: &str, index: usize) -> bool {
    if index == 0 {
        return true;
    }

    match s.as_bytes().get(index) {
        // For some reason, LLVM likes this comparison here more
        None => index == s.len(),
        // This is bit magic equivalent to: b < 128 || b >= 192
        Some(&b) => (b as i8) >= -0x40,
    }
}
```
This one has better codegen on every platform, except powerpc
<details><summary>x86 codegen</summary>
<p>

```nasm
example::is_char_boundary:
        mov     al, 1
        test    rdx, rdx
        je      .LBB0_5
        cmp     rsi, rdx
        je      .LBB0_5
        cmp     rsi, rdx
        jbe     .LBB0_3
        cmp     byte ptr [rdi + rdx], -65
        setg    al
.LBB0_5:
        ret
.LBB0_3:
        xor     eax, eax
        ret

example::is_char_boundary2:
        test    rdx, rdx
        je      .LBB1_1
        cmp     rsi, rdx
        jbe     .LBB1_4
        cmp     byte ptr [rdi + rdx], -65
        setg    al
        ret
.LBB1_1:  ; technically this branch is the same as LBB1_4
        mov     al, 1
        ret
.LBB1_4:
        sete    al
        ret
 ```
</p>
</details>

<details><summary>aarch64 codegen</summary>
<p>

```as
example::is_char_boundary:
        mov     x8, x0
        mov     w0, #1
        cbz     x2, .LBB0_4
        cmp     x1, x2
        b.eq    .LBB0_4
        b.ls    .LBB0_5
        ldrsb   w8, [x8, x2]
        cmn     w8, #65
        cset    w0, gt
.LBB0_4:
        ret
.LBB0_5:
        mov     w0, wzr
        ret

example::is_char_boundary2:
        cbz     x2, .LBB1_3
        cmp     x1, x2
        b.ls    .LBB1_4
        ldrsb   w8, [x0, x2]
        cmn     w8, #65
        cset    w0, gt
        ret
.LBB1_3:
        mov     w0, #1
        ret
.LBB1_4:
        cset    w0, eq
        ret
```

</p>
</details>

<details><summary>riscv64gc codegen</summary>
<p>

example::is_char_boundary:
        seqz    a3, a2
        xor     a4, a1, a2
        seqz    a4, a4
        or      a4, a4, a3
        addi    a3, zero, 1
        bnez    a4, .LBB0_3
        bgeu    a2, a1, .LBB0_4
        add     a0, a0, a2
        lb      a0, 0(a0)
        addi    a1, zero, -65
        slt     a3, a1, a0
.LBB0_3:
        mv      a0, a3
        ret
.LBB0_4:
        mv      a0, zero
        ret

example::is_char_boundary2:
        beqz    a2, .LBB1_3
        bgeu    a2, a1, .LBB1_4
        add     a0, a0, a2
        lb      a0, 0(a0)
        addi    a1, zero, -65
        slt     a0, a1, a0
        ret
.LBB1_3:
        addi    a0, zero, 1
        ret
.LBB1_4:
        xor     a0, a1, a2
        seqz    a0, a0
        ret

</p>
</details>

[Link to godbolt](https://godbolt.org/z/K8avEz8Gr)

`@rustbot` label: A-codegen

Don't generate more docs than necessary

Auto merge of #82208 - jyn514:rustfmt-subtree, r=Mark-Simulacrum

Convert rustfmt from a submodule to a subtree

r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum`

The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days, causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling, since now people making breaking changes will be responsible for fixing them.

I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history, which is not terribly much compared to the 702 MB that already exist.

- Add `src/tools/rustfmt` to `x.py check`
- Fix CRLF issues with rustfmt tests (see commit for details)
- Use `rustc_private` instead of crates.io dependencies

  This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust.

- Add `yansi-term` to the list of allowed dependencies.

  This is a false positive - rustc doesn't actually use it, only rustfmt, but because it's activated by the cargo feature of a dependency, tidy gets confused. It's fairly innocuous in any case, it's used for color printing.
  This would have happened in the next submodule bump.

- Remove rustfmt from the list of toolstate tools.
- Give a hard error if testing or building rustfmt fails.
-  Update log to 0.4.14

   This avoids a warning about semicolons in macros; see the commit for details.

- Don't add tools to the sysroot when they finish building.

  This is the only change that could be considered a regression - this avoids a "colliding StableCrateId" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details.

Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.

Auto merge of #85328 - GuillaumeGomez:rollup-exe9nbj, r=GuillaumeGomez

Rollup of 12 pull requests

Successful merges:

 - #84461 (rustdoc: Remove unnecessary `StripItem` wrapper)
 - #85067 (Minimize amount of fake `DefId`s used in rustdoc)
 - #85207 (Fix typo in comment)
 - #85215 (coverage bug fixes and some refactoring)
 - #85221 (dbg macro: Discuss use in tests, and slightly clarify)
 - #85246 (Miner code formatting)
 - #85253 (swap function order for better read flow)
 - #85256 (Fix display for "implementors" section)
 - #85268 (Use my real name)
 - #85278 (Improve match statements)
 - #85289 (Fix toggle position on mobile)
 - #85323 (Fix eslint errors)

Failed merges:

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

fix version_str comment

Rollup merge of #85323 - GuillaumeGomez:fix-eslint-errors, r=jsha

Fix eslint errors

I cherry-picked the two non-CI commits from #85285.

r? ```@jsha```

Rollup merge of #85289 - GuillaumeGomez:fix-toggle-position-mobile, r=jsha

Fix toggle position on mobile

Before:


After:


r? ```@jsha```

Rollup merge of #85278 - ayushmishra2005:code-refactoring, r=jackh726

Improve match statements

Rollup merge of #85268 - camelid:real-name, r=Mark-Simulacrum

Use my real name

Rollup merge of #85256 - GuillaumeGomez:fix-implementors-display, r=notriddle

Fix display for "implementors" section

Just saw this problem when going through docs:


This fix puts it back to normal:


You can see it on the `TryFrom` page for example.

r? ```@Nemo157```

Rollup merge of #85253 - RafaelKr:patch-1, r=varkor

swap function order for better read flow

I was reading this error message for the first time.

I was a little bit confused when reading that part:
```
foo.bar(); // we can now use this method since i32 implements the Foo trait
```

At the time I was reading `// we can now use this method` I wasn't sure why. It only made sense when reading on. So swapping these parts results in a better read flow.

Rollup merge of #85246 - ayushmishra2005:minor-reactoring, r=petrochenkov

Miner code formatting

Rollup merge of #85221 - ijackson:dbg-doc-re-tests, r=joshtriplett

dbg macro: Discuss use in tests, and slightly clarify

As discussed in a tangent in #82778.

I chose to use [semantic newlines](https://rhodesmill.org/brandon/2012/one-sentence-per-line/) in the source text but I don't mind reformatting it.

Rollup merge of #85215 - richkadel:ice-fixes-minus-dead-blocks, r=tmandry

coverage bug fixes and some refactoring

This replaces the relevant commits (2 and 3) from PR #85082, and also corrects an error querying for coverageinfo.

1. `coverageinfo` query needs to use the same MIR as codegen

I ran into an error trying to fix dead block coverage and realized the
`coverageinfo` query is getting a different MIR compared to the
codegenned MIR, which can sometimes be a problem during mapgen.

I changed that query to use the `InstandeDef` (which includes the
generic parameter substitutions, prosibly specific to const params)
instead of the `DefId` (without unknown/default const substitutions).

2. Simplified body_span and filtered span code

  Some code cleanup extracted from future (but unfinished) commit to fix
  coverage in attr macro functions.

3. Spanview needs the relevant body_span used for coverage

The coverage body_span doesn't always match the function body_span.

r? ```@tmandry```

Rollup merge of #85207 - andrewhalle:typo-rootseparator, r=kennytm

Fix typo in comment

missing space in "rootseparator"

Rollup merge of #85067 - Stupremee:minimize-amount-of-fake-defids, r=jyn514,GuillaumeGomez

Minimize amount of fake `DefId`s used in rustdoc

Follow up from #84707, which minimizes the amount of fake defids to the smallest amount possible. Every `FakeDefId` that is now used in the rustdoc library must be preserved and can not be replaced with a normal `DefId`.

Rollup merge of #84461 - jyn514:remove-strip-item, r=GuillaumeGomez

rustdoc: Remove unnecessary `StripItem` wrapper

Minimize amount of fake `DefId`s used in rustdoc

Update rustdoc-js tools

Fix eslint errors

Warn about unused pub fields in non-pub structs

Auto merge of #84152 - sexxi-goose:insignificant_dtor, r=nikomatsakis

Insignificant destructors rfc 2229

- Adds new attribute `rustc_insignificant_dtor` to annotate the drop method.
- Adds a query to check if a type has a significant drop.
- Updates closure analysis to check for significant drops rather than just drop.

A type marked with the attribute `rustc_insignificant_dtor` is considered to not be significant. A drop is significant if it is implemented by the user or does anything that will have any observable behavior (other than freeing up memory).

https://github.com/rust-lang/project-rfc-2229/issues/35

Auto merge of #85311 - camelid:box-blanket-impl, r=jyn514

Box `Impl.blanket_impl` to reduce size

Blanket impls are probably not super common, and `Type` is a fairly
large type, so this should reduce `Impl`'s size by a lot: `Option<Type>`
is around 96 bytes, and `Option<Box<Type>>` is 8 bytes, so it's a big
difference!

Auto merge of #84997 - pietroalbini:ci-verify-channel, r=Mark-Simulacrum

Error out if a PR is sent to the wrong channel

It happened multiple times that a PR meant to go on beta ends up being opened (and occasionally merged) to master. This PR does two things:

* Moves the definition of the channel in `src/ci/channel` so it's easier for tools to read it. I was not sure whether to move it to `src/channel` (like `src/version`): ended up with `src/ci` as it's currently only used for CI, but I'm open to moving it to `src`. We'll need to update the release process after this.
* Adds a check on **non-bors** builds that errors out if the base branch is not the expected one for the currently defined channel. This will not cause problems for promotion PRs, as those PRs are meant to also update the channel name.

r? `@Mark-Simulacrum`

add new attribute rustc_insignificant_dtor and a query to check if a type has a significant drop

ci(should-skip-this): only check commits when skip rule enabled

should-skip-this: Check for changes between the master branch, not the previous commit.

The previous commit could be part of the current PR.

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

Box `Impl.blanket_impl` to reduce size

Blanket impls are probably not super common, and `Type` is a fairly
large type, so this should reduce `Impl`'s size by a lot: `Option<Type>`
is around 96 bytes, and `Option<Box<Type>>` is 8 bytes, so it's a big
difference!

chore: update gitattributes for files with windows style line endings

Add test for toggle on mobile size

Unify toggle rules on smaller resolutions

Move @media rules at the end so they override the other rules

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.

Add tests where asm! is properly in unsafe block

Fix toggle position on mobile

Check for inline assembly in THIR unsafeck

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.

Addressed PR coments

panic abort after fork test: Disable on android

And link to the issue.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

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

Add asm!() support for PowerPC64

Improve match statements

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`

Tolerate SIGTRAP for panic abort after panic::always_abort

Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort!

See eg
  https://github.com/rust-lang/rust/pull/81858#issuecomment-840702765

This is probably a bug, but we don't want to entangle this MR with it.
When it's fixed, this commit should be reverted.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Use SIGUSR1 rather than SIGTRAP for "allocated after fork"

Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort!

See eg
  https://github.com/rust-lang/rust/pull/81858#issuecomment-840702765

This is probably a bug, but (i) we want to avoid that bug rather than
trying to fix it now and (ii) it would better to use a signal that is
less at risk of strangeness.

I grepped the rust-lang/rut codebase for SIGUSR and there were no hits.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Use my real name

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

Change "etc." to "and similar"

Co-authored-by: Josh Triplett <josh@joshtriplett.org>

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 display for "implementors" section

fix test suite

update stdarch

swap function order for better read flow

When having the order

```
foo.bar(); // we can now use this method since i32 implements the Foo trait

[...]

impl Foo for i32
```

the `// we can now use this method` comment is less clear to me.

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.

removed compilation error

Miner code formatting

`coverageinfo` query needs to use the same MIR as codegen

I ran into an error trying to fix dead block coverage and realized the
`coverageinfo` query is getting a different MIR compared to the
codegenned MIR, which can sometimes be a problem during mapgen.

I changed that query to use the `InstandeDef` (which includes the
generic parameter substitutions, prosibly specific to const params)
instead of the `DefId` (without unknown/default const substitutions).

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