add fut/back compat tests for implied trait bounds

Auto merge of #93643 - lcnr:fold-substs-perf, r=michaelwoerister

use `fold_list` in `try_super_fold_with` for `SubstsRef`

split out from #93505 as this by itself is responsible for most of the perf improvements there

r? `@michaelwoerister`

Auto merge of #93179 - Urgau:unreachable-2021, r=m-ou-se,oli-obk

Fix invalid special casing of the unreachable! macro

This pull-request fix an invalid special casing of the `unreachable!` macro in the same way the `panic!` macro was solved, by adding two new internal only macros `unreachable_2015` and `unreachable_2021` edition dependent and turn `unreachable!` into a built-in macro that do dispatching. This logic is stolen from the `panic!` macro.

~~This pull-request also adds an internal feature `format_args_capture_non_literal` that allows capturing arguments from formatted string that expanded from macros. The original RFC #2795 mentioned this as a future possibility. This feature is [required](https://github.com/rust-lang/rust/issues/92137#issuecomment-1018630522) because of concatenation that needs to be done inside the macro:~~
```rust
$crate::concat!("internal error: entered unreachable code: ", $fmt)
```

**In summary** the new behavior for the `unreachable!` macro with this pr is:

Edition 2021:
```rust
let x = 5;
unreachable!("x is {x}");
```
```
internal error: entered unreachable code: x is 5
```

Edition <= 2018:
```rust
let x = 5;
unreachable!("x is {x}");
```
```
internal error: entered unreachable code: x is {x}
```

Also note that the change in this PR are **insta-stable** and **breaking changes** but this a considered as being a [bug](https://github.com/rust-lang/rust/issues/92137#issuecomment-998441613).
If someone could start a perf run and then a crater run this would be appreciated.

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

Auto merge of #93695 - matthiaskrgr:rollup-zslgooo, r=matthiaskrgr

Rollup of 2 pull requests

Successful merges:

 - #90998 (Require const stability attribute on all stable functions that are `const`)
 - #93489 (Mark the panic_no_unwind lang item as nounwind)

Failed merges:

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

Rollup merge of #93489 - Amanieu:panic_no_unwind, r=nagisa

Mark the panic_no_unwind lang item as nounwind

This has 2 effects:
- It helps LLVM when inlining since it doesn't need to generate landing pads for `panic_no_unwind`.
- It makes it sound for a panic handler to unwind even if `PanicInfo::can_unwind` returns true. This will simply cause another panic once the unwind tries to go past the `panic_no_unwind` lang item. Eventually this will cause a stack overflow, which is safe.

Rollup merge of #90998 - jhpratt:require-const-stability, r=oli-obk

Require const stability attribute on all stable functions that are `const`

This PR requires all stable functions (of all kinds) that are `const fn` to have a `#[rustc_const_stable]` or `#[rustc_const_unstable]` attribute. Stability was previously implied if omitted; a follow-up PR is planned to change the fallback to be unstable.

Auto merge of #90414 - thomcc:count-chars-faster, r=nagisa

Optimize `core::str::Chars::count`

I wrote this a while ago after seeing this function as a bottleneck in a profile, but never got around to contributing it. I saw it again, and so here it is. The implementation is fairly complex, but I tried to explain what's happening at both a high level (in the header comment for the file), and in line comments in the impl. Hopefully it's clear enough.

This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below), for a wide variety of workloads, without regressing performance on any of the workload sizes I've tried.

I also improved the benchmarks for this code, so that they explicitly check text in different languages and of different sizes (err, the cross product of language x size). The results of the benchmarks are here:

<details>
<summary>Benchmark results</summary>
<pre>
test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20,216 ns/iter (+/- 3,673) = 17931 MB/s
test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108,851 ns/iter (+/- 12,777) = 3330 MB/s
test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329,502 ns/iter (+/- 4,163) = 1100 MB/s
test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223,333 ns/iter (+/- 14,167) = 1623 MB/s
test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s
test str::char_count::emoji_large::case01_old_libcore      ... bench:       1,681 ns/iter (+/- 28) = 3369 MB/s
test str::char_count::emoji_large::case02_iter_increment   ... bench:       5,166 ns/iter (+/- 85) = 1096 MB/s
test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3,476 ns/iter (+/- 62) = 1629 MB/s
test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s
test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s
test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s
test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s
test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s
test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s
test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s
test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s
test str::char_count::en_huge::case00_cur_libcore          ... bench:      25,909 ns/iter (+/- 39,260) = 13299 MB/s
test str::char_count::en_huge::case01_old_libcore          ... bench:     102,887 ns/iter (+/- 3,257) = 3349 MB/s
test str::char_count::en_huge::case02_iter_increment       ... bench:     166,370 ns/iter (+/- 12,439) = 2071 MB/s
test str::char_count::en_huge::case03_manual_char_len      ... bench:     166,332 ns/iter (+/- 4,262) = 2071 MB/s
test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s
test str::char_count::en_large::case01_old_libcore         ... bench:       1,598 ns/iter (+/- 19) = 3369 MB/s
test str::char_count::en_large::case02_iter_increment      ... bench:       2,598 ns/iter (+/- 167) = 2072 MB/s
test str::char_count::en_large::case03_manual_char_len     ... bench:       2,578 ns/iter (+/- 55) = 2088 MB/s
test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s
test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s
test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s
test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s
test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s
test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s
test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s
test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s
test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16,439 ns/iter (+/- 3,105) = 19777 MB/s
test str::char_count::ru_huge::case01_old_libcore          ... bench:      89,480 ns/iter (+/- 2,555) = 3633 MB/s
test str::char_count::ru_huge::case02_iter_increment       ... bench:     217,703 ns/iter (+/- 22,185) = 1493 MB/s
test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157,330 ns/iter (+/- 19,188) = 2066 MB/s
test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s
test str::char_count::ru_large::case01_old_libcore         ... bench:       1,384 ns/iter (+/- 51) = 3670 MB/s
test str::char_count::ru_large::case02_iter_increment      ... bench:       3,381 ns/iter (+/- 543) = 1502 MB/s
test str::char_count::ru_large::case03_manual_char_len     ... bench:       2,423 ns/iter (+/- 429) = 2096 MB/s
test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s
test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s
test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s
test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s
test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s
test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s
test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s
test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s
test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15,053 ns/iter (+/- 2,640) = 20067 MB/s
test str::char_count::zh_huge::case01_old_libcore          ... bench:      82,622 ns/iter (+/- 3,602) = 3656 MB/s
test str::char_count::zh_huge::case02_iter_increment       ... bench:     230,456 ns/iter (+/- 7,246) = 1310 MB/s
test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220,595 ns/iter (+/- 11,624) = 1369 MB/s
test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s
test str::char_count::zh_large::case01_old_libcore         ... bench:       1,136 ns/iter (+/- 144) = 4154 MB/s
test str::char_count::zh_large::case02_iter_increment      ... bench:       3,147 ns/iter (+/- 253) = 1499 MB/s
test str::char_count::zh_large::case03_manual_char_len     ... bench:       2,993 ns/iter (+/- 400) = 1577 MB/s
test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s
test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s
test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s
test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s
test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s
test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s
test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
</pre>
</details>

I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s, which is surprising given how thorough they are, but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though, so... hopefully I'm not about to embarrass myself).

This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066, so I'm going to request review from the same person who reviewed that one. That said am not particularly picky, and might not have the correct syntax for requesting a review from someone (so it goes).

r? `@nagisa`

Auto merge of #93689 - matthiaskrgr:rollup-3pd1ept, r=matthiaskrgr

Rollup of 9 pull requests

Successful merges:

 - #91939 (Clarify error on casting larger integers to char)
 - #92300 (mips64-openwrt-linux-musl: Add Tier 3 target)
 - #92383 (Add new target armv7-unknown-linux-uclibceabi (softfloat))
 - #92651 (Remove "up here" arrow on item-infos)
 - #93556 (Change struct expr pretty printing to match rustfmt style)
 - #93649 (Add regression tests for issue 80309)
 - #93657 (Update CPU idle tracking for apple hosts)
 - #93659 (Refactor conditional)
 - #93669 (Resolve lifetimes for const generic defaults)

Failed merges:

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

Rollup merge of #93669 - compiler-errors:const-generic-args, r=lcnr

Resolve lifetimes for const generic defaults

We weren't visiting the const generic default argument in `rustc_resolve::late::lifetimes`. This seems to fix the issue, and we deny any non-`'static` lifetimes anyways.

Fixes #93647

Rollup merge of #93659 - UltiRequiem:refactor_conditional_static_rustdoc, r=GuillaumeGomez

Refactor conditional

Merge two `if` in just one.

Rollup merge of #93657 - Mark-Simulacrum:apple-measurement, r=pietroalbini

Update CPU idle tracking for apple hosts

The previous setup did not properly consider hyperthreads (at least in local
testing), which likely skews CI results as well. The new code is both simpler
and hopefully will produce more accurate results; locally it matches behavior
of the Linux version of this script.

Rollup merge of #93649 - WaffleLapkin:regression_test_80309, r=oli-obk

Add regression tests for issue 80309

Closes #80309 😝

I'm not sure where to put the tests, is `ui/issues` the right place for this kind of tests?

Rollup merge of #93556 - dtolnay:trailingcomma, r=cjgillot

Change struct expr pretty printing to match rustfmt style

This PR backports trailing comma support from https://github.com/dtolnay/prettyplease into rustc_ast_pretty and uses it to improve the formatting of struct expressions.

Example:

```rust
macro_rules! stringify_expr {
    ($expr:expr) => {
        stringify!($expr)
    };
}

fn main() {
    println!("{}", stringify_expr!(Struct {
        a: Struct { b, c },
    }));
    println!("{}", stringify_expr!(Struct {
        aaaaaaaaaa: AAAAAAAAAA,
        bbbbbbbbbb: Struct {
            cccccccccc: CCCCCCCCCC,
            dddddddddd: DDDDDDDDDD,
            eeeeeeeeee: EEEEEEEEEE,
        },
    }));
}
```

🤮 Before:

```console
Struct{a: Struct{b, c,},}
Struct{aaaaaaaaaa: AAAAAAAAAA,
    bbbbbbbbbb:
        Struct{cccccccccc: CCCCCCCCCC,
            dddddddddd: DDDDDDDDDD,
            eeeeeeeeee: EEEEEEEEEE,},}
```

After:

```console
Struct { a: Struct { b, c } }
Struct {
    aaaaaaaaaa: AAAAAAAAAA,
    bbbbbbbbbb: Struct {
        cccccccccc: CCCCCCCCCC,
        dddddddddd: DDDDDDDDDD,
        eeeeeeeeee: EEEEEEEEEE,
    },
}
```

Rollup merge of #92651 - jsha:impl-spacing, r=GuillaumeGomez

Remove "up here" arrow on item-infos

Use spacing to distinguish what is related to a given heading.

This was originally introduced in #53043, in response to #51387. The arrow is a little distracting, and leads the item-info to not be aligned properly with the text below it.

Demo: https://rustdoc.crud.net/jsha/impl-spacing/std/string/struct.String.html

r? ``@GuillaumeGomez``

Rollup merge of #92383 - lancethepants:armv7-unknown-linux-uclibceabi, r=nagisa

Add new target armv7-unknown-linux-uclibceabi (softfloat)

This adds the new target `armv7-unknown-linux-uclibceabi (softfloat)`. It is of course similar to `armv7-unknown-linux-uclibceabihf (hardfloat)` which was just recently added to rust except that it is `softfloat`.

My interest lies in the Broadcom BCM4707/4708/BCM4709 family, notably found in some Netgear and Asus consumer routers. The armv7 Cortex-A9 cpus found in these devices do not have an fpu or NEON support.

With this patch I've been able to bootstrap rustc, std and host tools `(extended = true)` to run on the target device for native compilation, allowing the target to be used as a development platform.

With the recent addition of `armv7-unknown-linux-uclibceabihf (hardfloat)` it looks like many of the edge cases of using the uclibc c-library are getting worked out nicely. I've been able to compile some complex projects. Some patching still needed in some crates, but getting there for sure.  I think `armv7-unknown-linux-uclibceabi` is ready to be a tier 3 target.

I use a cross-toolchain from my project to bootstrap rust.
https://github.com/lancethepants/tomatoware
The goal of this project is to create a native development environment with support for various languages.

Rollup merge of #92300 - Itus-Shield:mips64-openwrt, r=nagisa

mips64-openwrt-linux-musl: Add Tier 3 target

Tier 3 tuple for Mips64 OpenWrt toolchain.

This add first-time support for OpenWrt.  Future Tier3 targets will be added as I test them.

Signed-off-by: Donald Hoskins <grommish@gmail.com>

Rollup merge of #91939 - GKFX:feature-91866, r=cjgillot

Clarify error on casting larger integers to char

Closes #91836 with changes to E0604.md and a `span_help`.

Auto merge of #92535 - Amanieu:oom_hook_unwind, r=m-ou-se

Allow unwinding from OOM hooks

This is split off from #88098 and contains just the bare minimum to allow specifying a custom OOM hook with `set_alloc_error_hook` which unwinds instead of aborting.

See #88098 for an actual command-line flag which switches the default OOM behavior to unwind instead of aborting.

Previous perf results show a negligible impact on performance.

Update llvm-project submodule

Mark __rgl_oom and __rd_oom as "C-unwind"

Allow handle_alloc_error to unwind

Fix comment grammar for `do_count_chars`

Respond to review feedback, and improve implementation somewhat

Ensure non-power-of-two sizes are tested in the Chars::count test

Fix zh::SMALL string in core::str benchmarks

Optimize `core::str::Chars::count`

Auto merge of #93539 - petrochenkov:doclink, r=camelid,michaelwoerister

rustdoc: Collect traits in scope for foreign inherent impls

Inherent impls can be inlined for variety of reasons (impls of reexported types, impls available through `Deref`, impls inlined for unclear reasons like in https://github.com/rust-lang/rust/pull/88679#issuecomment-1023929480).
If an impl is inlined, then doc links in its comments are resolved and we may need the set of traits that are in scope at that impl's definition point.
So in this PR we simply collect traits in scope for *all* inherent impls from other crates if their `Self` type is public, which is very similar for the strategy for trait impls previously used in https://github.com/rust-lang/rust/pull/88679.

Fixes https://github.com/rust-lang/rust/issues/93476
Fixes https://github.com/rust-lang/rust/pull/88679#issuecomment-1026520300
Fixes https://github.com/rust-lang/rust/pull/88679#issuecomment-1023929480

Auto merge of #93597 - GuillaumeGomez:update-browser-ui-test, r=jsha

Update browser-ui-test version

The puppeteer version update is limited because new versions has some "interesting" flaws.

r? `@jsha`

resolve lifetimes for const generic defaults

Auto merge of #93655 - matthiaskrgr:rollup-dm88b02, r=matthiaskrgr

Rollup of 7 pull requests

Successful merges:

 - #90132 (Stabilize `-Z instrument-coverage` as `-C instrument-coverage`)
 - #91589 (impl `Arc::unwrap_or_clone`)
 - #93495 (kmc-solid: Fix off-by-one error in `SystemTime::now`)
 - #93576 (Emit more valid HTML from rustdoc)
 - #93608 (Clean up `find_library_crate`)
 - #93612 (doc: use U+2212 for minus sign in integer MIN/MAX text)
 - #93615 (Fix `isize` optimization in `StableHasher` for big-endian architectures)

Failed merges:

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

Refactor conditional

Add new target armv7-unknown-linux-uclibceabi (softfloat)

Update CPU idle tracking for apple hosts

The previous setup did not properly consider hyperthreads (at least in local
testing), which likely skews CI results as well. The new code is both simpler
and hopefully will produce more accurate results.

Specify min llvm version for issue 80309 regression tests

Rollup merge of #93615 - Kobzol:stable-hash-opt-endianness, r=the8472

Fix `isize` optimization in `StableHasher` for big-endian architectures

This PR fixes a problem with the stable hash optimization introduced in https://github.com/rust-lang/rust/pull/93432. As `@michaelwoerister` has [found out](https://github.com/rust-lang/rust/pull/93432#issuecomment-1028756212), the original implementation wouldn't produce the same hash on little/big architectures.

r? `@the8472`

Rollup merge of #93612 - tspiteri:master, r=m-ou-se

doc: use U+2212 for minus sign in integer MIN/MAX text

Closes #90793.

Rollup merge of #93608 - nnethercote:speed-up-find_library_crate, r=petrochenkov

Clean up `find_library_crate`

Some clean-ups.

r? `@petrochenkov`

Rollup merge of #93576 - jsha:fix-rustdoc-html, r=GuillaumeGomez

Emit more valid HTML from rustdoc

Previously, tidy-html5 (`tidy`) would complain about a few things in our HTML. The main thing is that `<summary>` tags can't contain `<div>`s. That's easily fixed by changing out the `<div>`s for `<span>`s with `display: block`.

However, there's also a rule that `<span>`s can't contain heading elements. `<span>` permits only "phrasing content" https://developer.mozilla.org/en-US/docs/Web/HTML/Element/span, and `<h3>` (and friends) are "Flow content, heading content, palpable content". https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements

We have a wrapping `<div>` that goes around each `<h3>`/`<h4>`, etc. We turn that into a `<section>` rather than a `<span>` because `<section>` permits "flow content". https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section

After this change we get only three warnings from tidy, run on struct.String.html:

line 6 column 10790 - Warning: trimming empty <span>
line 1 column 1118 - Warning: <link> proprietary attribute "disabled"
line 1 column 1193 - Warning: <link> proprietary attribute "disabled"

The empty `<span>` is a known issue - there's a span in front of the search box to work around a strange Safari issue.

The `<link>` attributes are the non-default stylesheets. We can probably refactor theme application to avoid using this proprietary "disabled" attribute.

We can suppress those warnings with flags to tidy, and get a run that returns 0 (success):

```
tidy -o /dev/null -quiet --drop-empty-elements no --warn-proprietary-attributes no build/x86_64-unknown-linux-gnu/doc/std/string/trait.ToString.html
```

Note: this requires the latest version of tidy-html5, built from https://github.com/htacg/tidy-html5. Older versions (including the default version on Ubuntu 21.10) think `<section>` can't occur inside `<summary>`.

Demo: https://rustdoc.crud.net/jsha/fix-rustdoc-html/std/string/struct.String.html

r? `@GuillaumeGomez`

Rollup merge of #93495 - solid-rs:fix-kmc-solid-rtc-month, r=yaahc

kmc-solid: Fix off-by-one error in `SystemTime::now`

Fixes a miscalculation of `SystemTime`  on the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.

Unlike the identically-named libc counterpart `tm::tm_mon`, `SOLID_RTC_TIME::tm_mon` contains a 1-based month number.

Rollup merge of #91589 - derekdreery:arc_unwrap_or_clone, r=m-ou-se

impl `Arc::unwrap_or_clone`

The function gets the inner value, cloning only if necessary. The conversation started on [`irlo`](https://internals.rust-lang.org/t/arc-into-inner/15707). If the reviewer think the PR has potential to be merged, and does not need an RFC, then I will create the corresponding tracking issues and update the PR.

## Alternative names

 - `into_inner`
 - `make_owned`
 - `make_unique`
 - `take_*` (`take_inner`?)

Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage, r=wesleywiser

Stabilize `-Z instrument-coverage` as `-C instrument-coverage`

(Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121)

This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.)

Many, many people have tested this support, and there are numerous reports of it working as expected.

Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option.

Addressing questions raised in the tracking issue:

> If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.)

This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration.

> The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline?

This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version).

> The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM.

Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement.

The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization.

The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that, `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.

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

update miri

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

update miri

doc: use U+2212 for minus sign in integer MIN/MAX text

Add regression tests for issue 80309

Auto merge of #93645 - matthiaskrgr:rollup-eua2621, r=matthiaskrgr

Rollup of 11 pull requests

Successful merges:

 - #92735 (Add crate filter parameter in URL)
 - #93402 (Windows: Disable LLVM crash dialog boxes.)
 - #93508 (Add rustdoc info to jsondocck output)
 - #93551 (Add package.json in gitignore)
 - #93555 (Link `try_exists` docs to `Path::exists`)
 - #93585 (Missing tests for #92630)
 - #93593 (Fix ret > 1 bound if shadowed by const)
 - #93630 (clippy::perf fixes)
 - #93631 (rustc_mir_dataflow: use iter::once instead of Some().into_iter)
 - #93632 (rustdoc: clippy::complexity fixes)
 - #93638 (rustdoc: remove unused Hash impl)

Failed merges:

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

rustdoc: Collect traits in scope for foreign inherent impls

Rollup merge of #93638 - notriddle:notriddle/unused-hash, r=GuillaumeGomez

rustdoc: remove unused Hash impl

Rollup merge of #93632 - matthiaskrgr:rustdoclippy2, r=GuillaumeGomez

rustdoc: clippy::complexity fixes

clippy::map_flatten
clippy::clone_on_copy
clippy::useless_conversion
clippy::needless_arbitrary_self_type

Rollup merge of #93631 - notriddle:notriddle/cleanup-some-into-iter, r=oli-obk

rustc_mir_dataflow: use iter::once instead of Some().into_iter

Rollup merge of #93630 - matthiaskrgr:clipperf, r=oli-obk

clippy::perf fixes

single_char_pattern and to_string_in_format_args

Rollup merge of #93593 - JulianKnodt:master, r=oli-obk

Fix ret > 1 bound if shadowed by const

Prior to a change, it would only look at types in bounds. When it started looking for consts,
shadowing type variables with a const would cause an ICE, so now defer looking at consts only if
there are no types present.

cc ``````@compiler-errors``````
Should Fix #93553

Rollup merge of #93585 - tamaroning:add_tests_for_92630, r=m-ou-se

Missing tests for #92630

fixes #93143

Rollup merge of #93555 - ChrisDenton:fs-try-exists-doc, r=Mark-Simulacrum

Link `try_exists` docs to `Path::exists`

Links to the existing `Path::exists` method from both `std::Path::try_exists` and `std::fs:try_exists`.

Tracking issue for `path_try_exists`: #83186

Rollup merge of #93551 - GuillaumeGomez:ignore-package-json, r=Mark-Simulacrum

Add package.json in gitignore

It happened a few times (last one is https://github.com/rust-lang/rust/pull/93537/files#r796757998) so I think it's fine to ignore this file to prevent it to happen again in the future. :)

r? ```@Mark-Simulacrum```

Rollup merge of #93508 - CraftSpider:jsondocck-runtest-output, r=Mark-Simulacrum

Add rustdoc info to jsondocck output

Makes debugging issues in the generated output simpler by handling emitted logs and etc.

Rollup merge of #93402 - ehuss:llvm-dialog, r=michaelwoerister

Windows: Disable LLVM crash dialog boxes.

This disables the crash dialog box on Windows. When LLVM hits an assertion, it will open a dialog box with Abort/Retry/Ignore. This is annoying on CI because CI will just hang until it times out (which can take hours).

Instead of opening a dialog box, it will print a message like this:

```
Assertion failed: isa<X>(Val) && "cast<Ty>() argument of incompatible type!", file D:\Proj\rust\rust\src\llvm-project\llvm\include\llvm/Support/Casting.h, line 255
```

Closes #92829

Rollup merge of #92735 - GuillaumeGomez:crate-filter-url-param, r=jsha

Add crate filter parameter in URL

Fixes #92621.

r? `@jsha`

Add comment in GUI test

Update browser-ui-test version

fold substs

Add a comment about possible mismatches.

Remove `staticlibs` local variable.

Fix some tests to use -Cinstrument-coverage

Add missing const stability attributes

Require const stability on all stable const items

This was supposed to be the case previously, but a missed method call
meant that trait impls were not checked.

rustdoc: remove unused Hash impl

Clean up `find_library_crate`.

By introducing prefix and suffix variables for all file types, and
renaming some variables.

rustdoc: clippy::complexity fixes

clippy::map_flatten
clippy::clone_on_copy
clippy::useless_conversion
clippy::needless_arbitrary_self_type

Add GUI test for crate filter URL parameter

Update tester to have FILTER_CRATE set to null if undefined.

Add filter-crate URL parameter

rustc_mir_dataflow: use iter::once instead of Some().into_iter

clippy::perf fixes

single_char_pattern and to_string_in_format_args

Bless all pretty printer tests and ui tests

Change struct expr pretty printing to match rustfmt style

Support offsetting the most recent break

Change pp indent to signed to allow negative indents

Add trailing comma support

Auto merge of #93621 - JohnTitor:rollup-1bcud0x, r=JohnTitor

Rollup of 7 pull requests

Successful merges:

 - #92310 (rustdoc: Fix ICE report)
 - #92802 (Deduplicate lines in long const-eval stack trace)
 - #93515 (Factor convenience functions out of main printer implementation)
 - #93566 (Make rustc use `RUST_BACKTRACE=full` by default)
 - #93589 (Use Option::then in two places)
 - #93600 (fix: Remove extra newlines from junit output)
 - #93606 (Correct incorrect description of preorder traversals)

Failed merges:

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

Fix ret > 1 bound if shadowed by const

Prior to a change, it would only look at types in bounds. When it started looking for consts,
shadowing type variables with a const would cause an ICE, so now defer looking at consts only if
there are no types present.

Only disable dialogs on CI.

The "CI" environment var isn't universal (for example, I think Azure
uses TF_BUILD). However, we are mostly concerned with rust-lang/rust's
own CI which currently is GitHub Actions which does set "CI". And I
think most other providers use "CI" as well.

Rollup merge of #93606 - JakobDegen:mischaracterized-preorder, r=oli-obk

Correct incorrect description of preorder traversals

The internal documentation for the `Preorder` type gave an incorrect description (the description is not even correct for the example provided, since C is visited after one of its successors). This corrects the description, and adds in a sentence explaining more precisely how the traversals are performed.

Rollup merge of #93600 - last-partizan:fix-junit-formatter, r=yaahc

fix: Remove extra newlines from junit output

This PR fixes extra newline in junit output https://github.com/rust-lang/rust/issues/93454

Rollup merge of #93589 - est31:option_then, r=cjgillot

Use Option::then in two places

Rollup merge of #93566 - Aaron1011:rustc-backtrace, r=davidtwco

Make rustc use `RUST_BACKTRACE=full` by default

Compiler panics should be rare - when they do occur, we want the report
filed by the user to contain as much information as possible. This is
especially important when the panic is due to an incremental compilation
bug, since we may not have enough information to reproduce it.

This PR sets `RUST_BACKTRACE=full` inside `rustc` if the user has not
explicitly set `RUST_BACKTRACE`. This is more verbose than
`RUST_BACKTRACE=1`, but this may make it easier to debug incremental
compilation issues. Users who find this too verbose can still manually
set `RUST_BACKTRACE` before invoking the compiler.

This only affects `rustc` (and any tool using `rustc_driver::install_ice_hook`).
It does *not* affect any user crates or the standard library -
backtraces will continue to be off by default in any application
*compiled* by rustc.

Rollup merge of #93515 - dtolnay:convenience, r=davidtwco

Factor convenience functions out of main printer implementation

The pretty printer in rustc_ast_pretty has a section of methods commented "Convenience functions to talk to the printer". This PR pulls those out to a separate module. This leaves pp.rs with only the minimal API that is core to the pretty printing algorithm.

I found this separation to be helpful in https://github.com/dtolnay/prettyplease because it makes clear when changes are adding some fundamental new capability to the pretty printer algorithm vs just making it more convenient to call some already existing functionality.

Rollup merge of #92802 - compiler-errors:deduplicate-stack-trace, r=oli-obk

Deduplicate lines in long const-eval stack trace

Lemme know if this is kinda overkill, lol.

Fixes #92796

Rollup merge of #92310 - ehuss:rustdoc-ice, r=estebank

rustdoc: Fix ICE report

The ICE report in rustdoc was confusing because it was returning an argument parse error:

```
thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`', compiler/rustc_errors/src/lib.rs:1212:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

error: Unrecognized option: 'crate-version'
```

This is because the ICE reporter was trying to parse the arguments as rustc, not rustdoc.  Since an argument error is a fatal error, it was early-exiting with the argument error due to unwinding.

This changes it to be a more primitive scan of the arguments. The arguments being checked are pretty simple, and only have a small handful of forms that are easy to check for.

It now looks like this:

```
thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`', compiler/rustc_errors/src/lib.rs:1212:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

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

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.59.0-dev running on x86_64-apple-darwin

note: compiler flags: --crate-type lib -Z treat-err-as-bug

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

query stack during panic:
end of query stack
```

It still says `rustc`, but I can live with that.

Auto merge of #92932 - ouz-a:master, r=oli-obk

Temporary fix for the layout of aligned enums

Fix for the issue #92464

~~I was after this issue for quite some time now, I have a temporary fix for it.
I think the current problem is [here](https://github.com/ouz-a/rust/blob/e75f96763f99d56d03ada939fe05cbeb2254888d/compiler/rustc_middle/src/ty/layout.rs#L1305-L1310) created `tag` value might be wrong, because when I checked `min` and `max` values it's always between 0..1, which results in wrong size comparison in a few lines down below.
I think `min` and `max` values don't take `#[repr(aligned(8))]` into consideration and just act from base values assigned inside the enum. If what I am saying is true, aligned enums were created with the wrong layout for some time.~~

~~As stated in the title this is only a temporary fix and I think this needs further investigation, if someone wants to mentor it I would like to work on that too.~~ 😸

**Edit: Weird some tests fail now going to close this for now...**

**Edit2: I made it work again.**

I think I figured out the main problem of the issue, layout types of aligned enums with custom discriminant types were not handled, which resulted in confusing(such as this issue) behavior down the line, this is a kinda hacky fix for the issue.

Fix `isize` optimization in `StableHasher` for big-endian architectures

Add tracking issue and impl for `Rc`.

impl `Arc::unwrap_or_clone`

The function gets the inner value, cloning only if necessary.

Auto merge of #93146 - workingjubilee:use-std-simd, r=Mark-Simulacrum

pub use std::simd::StdFloat;

Syncs portable-simd up to commit rust-lang/portable-simd@03f6fbb21e6050da2a05b3ce8f480c020b384916,
Diff: https://github.com/rust-lang/portable-simd/compare/533f0fc81ab9ba097779fcd27c8f9ea12261fef5...03f6fbb21e6050da2a05b3ce8f480c020b384916

This sync requires a little bit more legwork because it also introduces a trait into `std::simd`, so that it is no longer simply a reexport of `core::simd`. Out of simple-minded consistency and to allow more options, I replicated the pattern for the way `core::simd` is integrated in the first place, however this is not necessary if it doesn't acquire any interdependencies inside `std`: it could be a simple crate reexport. I just don't know yet if that will happen or not.

To summarize other misc changes:
- Shifts no longer panic, now wrap on too-large shifts (like `Simd` integers usually do!)
- mask16x32 will now be many i16s, not many i32s... 🙃
- `#[must_use]` is spread around generously
- Adjusts division, float min/max, and `Mask::{from,to}_array` internally to be faster
- Adds the much-requested `Simd::cast::<U>` function (equivalent to `simd.to_array().map(|lane| lane as U)`)

Auto merge of #93432 - Kobzol:stable-hash-isize-hash-compression, r=the8472

Compress amount of hashed bytes for `isize` values in StableHasher

This is another attempt to land https://github.com/rust-lang/rust/pull/92103, this time hopefully with a correct implementation w.r.t. stable hashing guarantees. The previous PR was [reverted](https://github.com/rust-lang/rust/pull/93014) because it could produce the [same hash](https://github.com/rust-lang/rust/pull/92103#issuecomment-1014625442) for different values even in quite simple situations. I have since added a basic [test](https://github.com/rust-lang/rust/pull/93193) that should guard against that situation, I also added a new test in this PR, specialised for this optimization.

## Why this optimization helps
Since the original PR, I have tried to analyze why this optimization even helps (and why it especially helps for `clap`). I found that the vast majority of stable-hashing `i64` actually comes from hashing `isize` (which is converted to `i64` in the stable hasher). I only found a single place where is this datatype used directly in the compiler, and this place has also been showing up in traces that I used to find out when is `isize` being hashed. This place is `rustc_span::FileName::DocTest`, however, I suppose that isizes also come from other places, but they might not be so easy to find (there were some other entries in the trace). `clap` hashes about 8.5 million `isize`s, and all of them fit into a single byte, which is why this optimization has helped it [quite a lot](https://github.com/rust-lang/rust/pull/92103#issuecomment-1005711861).

Now, I'm not sure if special casing `isize` is the correct solution here, maybe something could be done with that `isize` inside `DocTest` or in other places, but that's for another discussion I suppose. In this PR, instead of hardcoding a special case inside `SipHasher128`, I instead put it into `StableHasher`, and only used it for `isize` (I tested that for `i64` it doesn't help, or at least not for `clap` and other few benchmarks that I was testing).

## New approach
Since the most common case is a single byte, I added a fast path for hashing `isize` values which positive value fits within a single byte, and a cold path for the rest of the values.

To avoid the previous correctness problem, we need to make sure that each unique `isize` value will produce a unique hash stream to the hasher. By hash stream I mean a sequence of bytes that will be hashed (a different sequence should produce a different hash, but that is of course not guaranteed).

We have to distinguish different values that produce the same bit pattern when we combine them. For example, if we just simply skipped the leading zero bytes for values that fit within a single byte, `(0xFF, 0xFFFFFFFFFFFFFFFF)` and `(0xFFFFFFFFFFFFFFFF, 0xFF)` would send the same hash stream to the hasher, which must not happen.

To avoid this situation, values `[0, 0xFE]` are hashed as a single byte. When we hash a larger (treating `isize` as `u64`) value, we first hash an additional byte `0xFF`. Since `0xFF` cannot occur when we apply the single byte optimization, we guarantee that the hash streams will be unique when hashing two values `(a, b)` and `(b, a)` if `a != b`:
1) When both `a` and `b` are within `[0, 0xFE]`, their hash streams will be different.
2) When neither `a` and `b` are within `[0, 0xFE]`, their hash streams will be different.
3) When `a` is within `[0, 0xFE]` and `b` isn't, when we hash `(a, b)`, the hash stream will definitely not begin with `0xFF`. When we hash `(b, a)`, the hash stream will definitely begin with `0xFF`. Therefore the hash streams will be different.

r? `@the8472`

Correct incorrect description of preorder traversals.

Auto merge of #93101 - Mark-Simulacrum:library-backtrace, r=yaahc

Support configuring whether to capture backtraces at runtime

Tracking issue: https://github.com/rust-lang/rust/issues/93346

This adds a new API to the `std::panic` module which configures whether and how the default panic hook will emit a backtrace when a panic occurs.

After discussion with `@yaahc` on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/backtrace.20lib.20vs.2E.20panic), this PR chooses to avoid adjusting or seeking to provide a similar API for the (currently unstable) std::backtrace API. It seems likely that the users of that API may wish to expose more specific settings rather than just a global one (e.g., emulating the `env_logger`, `tracing` per-module configuration) to avoid the cost of capture in hot code. The API added here could plausibly be copied and/or re-exported directly from std::backtrace relatively easily, but I don't think that's the right call as of now.

```rust
mod panic {
    #[derive(Copy, Clone, Debug, PartialEq, Eq)]
    #[non_exhaustive]
    pub enum BacktraceStyle {
        Short,
        Full,
        Off,
    }
    fn set_backtrace_style(BacktraceStyle);
    fn get_backtrace_style() -> Option<BacktraceStyle>;
}
```

Several unresolved questions:

* Do we need to move to a thread-local or otherwise more customizable strategy for whether to capture backtraces? See [this comment](https://github.com/rust-lang/rust/pull/79085#issuecomment-727845826) for some potential use cases for this.
   * Proposed answer: no, leave this for third-party hooks.
* Bikeshed on naming of all the options, as usual.
* Should BacktraceStyle be moved into `std::backtrace`?
   * It's already somewhat annoying to import and/or re-type the `std::panic::` prefix necessary to use these APIs, probably adding a second module to the mix isn't worth it.

Note that PR #79085 proposed a much simpler API, but particularly in light of the desire to fully replace setting environment variables via `env::set_var` to control the backtrace API, a more complete API seems preferable. This PR likely subsumes that one.

Unify storage getter and setter functions

fix: Remove extra newlines from junit output

Auto merge of #93594 - matthiaskrgr:rollup-lcvhpdv, r=matthiaskrgr

Rollup of 8 pull requests

Successful merges:

 - #92528 (Make `Fingerprint::combine_commutative` associative)
 - #93221 ([borrowck] Fix help on mutating &self in async fns)
 - #93542 (Prevent lifetime elision in type alias)
 - #93546 (Validate that values in switch int terminator are unique)
 - #93571 (better suggestion for duplicated `where` clause)
 - #93574 (don't suggest adding `let` due to bad assignment expressions inside of `while` loop)
 - #93590 (More let_else adoptions)
 - #93592 (Remove unused dep from rustc_arena)

Failed merges:

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