Rollup merge of #91950 - estebank:point-at-type-of-non-allocator, r=matthewjasper

Point at type when a `static` `#[global_allocator]` doesn't `impl` `GlobalAlloc`

Auto merge of #93626 - wesleywiser:fix_hashmap_natvis, r=michaelwoerister

Fix HashMap not displaying correctly in VS debugger

The natvis to render HashMaps was not working correctly in Visual Studio
because the type names for tuples changed from `tuple$<A, B>` to
`tuple$<A,B>` (notice the missing space). WinDbg and cdb continued to
parse this type name which is why no tests in CI broke. VS however is
slightly more strict and this caused the visualizer to break.

Since we cannot test the VS debugger in CI, I'm not checking in any
test changes.

Fixes #92286

r? `@michaelwoerister`

Auto merge of #93762 - matthiaskrgr:rollup-vdjpfmz, r=matthiaskrgr

Rollup of 9 pull requests

Successful merges:

 - #86497 (Add {floor,ceil}_char_boundary methods to str)
 - #92695 (Add `#[no_coverage]` tests for nested functions)
 - #93521 (Fix hover effects in sidebar)
 - #93568 (Include all contents of first line of scraped item in Rustdoc)
 - #93569 (rustdoc: correct unclosed HTML tags as generics)
 - #93672 (update comment wrt const param defaults)
 - #93715 (Fix horizontal trim for block doc comments)
 - #93721 (rustdoc: Special-case macro lookups less)
 - #93728 (Add in ValuePair::Term)

Failed merges:

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

Rollup merge of #93728 - JulianKnodt:toterm, r=oli-obk

Add in ValuePair::Term

This adds in an enum when matching on positions which can either be types or consts.
It will default to emitting old special cased error messages for types.

r? `@oli-obk`
cc `@matthiaskrgr`
Fixes #93578

Rollup merge of #93721 - jyn514:less-macro-special-casing, r=petrochenkov

rustdoc: Special-case macro lookups less

Previously, rustdoc had 3 fallbacks it used:
1. `resolve_macro_path`
2. `all_macros`
3. `resolve_str_path_error`

Ideally, it would only use `resolve_str_path_error`, to be consistent with other namespaces.
Unfortunately, that doesn't consider macros that aren't defined at module scope;
consider for instance
```rust
{
    struct S;

    macro_rules! mac { () => {} }
    // `mac`'s scope starts here

    /// `mac` <- `resolve_str_path_error` won't see this
   struct Z;

    //`mac`'s scope ends here
}
```

This changes it to only use `all_macros` and `resolve_str_path_error`, and gives
`resolve_str_path_error` precedence over `all_macros` in case there are two macros with the same
name in the same module.

This is a smaller version of https://github.com/rust-lang/rust/pull/91427.

r? `@petrochenkov`

Rollup merge of #93715 - GuillaumeGomez:horizontal-trim, r=notriddle

Fix horizontal trim for block doc comments

Fixes #93662.

r? `@notriddle`

Rollup merge of #93672 - lcnr:const-param-defaults-xx, r=matthewjasper

update comment wrt const param defaults

after #93669 i looked through all other uses of `GenericParamKind::Const` again to detect if we missed the `default` there as well, but afaict we really only missed lifetime resolution '^^ at least i found an outdated comment :3

Rollup merge of #93569 - notriddle:notriddle/rustdoc-html-tags-generics, r=CraftSpider

rustdoc: correct unclosed HTML tags as generics

CC https://github.com/rust-lang/rust/issues/67799

Rollup merge of #93568 - willcrichton:scrape-examples-leading-whitespace, r=CraftSpider

Include all contents of first line of scraped item in Rustdoc

This fixes #93528. When scraping examples, it extends the span of the enclosing item to include all characters up to the start of the first line of the span.

r? `@camelid`

Rollup merge of #93521 - jsha:sidebar-hover, r=GuillaumeGomez

Fix hover effects in sidebar

The dark and ayu themes have a menu-like highlight on sidebar items. The light theme used to, but it was accidentally lost in the sidebar unification. The change brings back the hover effect in the light theme.

It also makes the hover effect apply consistently to all links in the sidebar, including headings.

It also simplifies the "In _path_" heading so it's one big link. The breadcrumbs are still readily available at the top of the page.

Note that a small number of headings are not linkified and so don't get the hover effect. That will be fixed with #92957.

Demo: https://rustdoc.crud.net/jsha/sidebar-hover/std/string/trait.ToString.html

r? `@GuillaumeGomez`

Fixes #93115

Rollup merge of #92695 - Swatinem:cover-nested, r=wesleywiser

Add `#[no_coverage]` tests for nested functions

I was playing around a bit trying to figure out how `#[no_coverage]` behaves for nested functions and thought I might as well add this as a testcase.

The "nesting covered fn inside not covered fn" case looks pretty much as expected.

The "nesting not covered fn inside a covered fn" case however seems a bit counterintuitive.
Essentially the region of the outer function "covers" its whole lexical range. And the inner function does not generate any region at all. 🤷🏻‍♂️

r? `@richkadel`

Rollup merge of #86497 - clarfonthey:nearest_char_boundary, r=scottmcm

Add {floor,ceil}_char_boundary methods to str

This is technically already used internally by the standard library in the form of `truncate_to_char_boundary`.

Essentially these are two building blocks to allow for approximate string truncation, where you want to cut off the string at "approximately" a given length in bytes but don't know exactly where the character boundaries lie. It's also a good candidate for the standard library as it can easily be done naively, but would be difficult to properly optimise. Although the existing code that's done in error messages is done naively, this code will explicitly only check a window of 4 bytes since we know that a boundary must lie in that range, and because it will make it possible to vectorise.

Although this method doesn't take into account graphemes or other properties, this would still be a required building block for splitting that takes those into account. For example, if you wanted to split at a grapheme boundary, you could take your approximate splitting point and then determine the graphemes immediately following and preceeding the split. If you then notice that these two graphemes could be merged, you can decide to either include the whole grapheme or exclude it depending on whether you decide splitting should shrink or expand the string.

This takes the most conservative approach and just offers the raw indices to the user, and they can decide how to use them. That way, the methods are as useful as possible despite having as few methods as possible.

(Note: I'll add some tests and a tracking issue if it's decided that this is worth including.)

Auto merge of #93561 - Amanieu:more-unwind-abi, r=nagisa

Add more *-unwind ABI variants

The following *-unwind ABIs are now supported:
- "C-unwind"
- "cdecl-unwind"
- "stdcall-unwind"
- "fastcall-unwind"
- "vectorcall-unwind"
- "thiscall-unwind"
- "aapcs-unwind"
- "win64-unwind"
- "sysv64-unwind"
- "system-unwind"

cc `@rust-lang/wg-ffi-unwind`

Auto merge of #92007 - oli-obk:lazy_tait2, r=nikomatsakis

Lazy type-alias-impl-trait

Previously opaque types were processed by

1. replacing all mentions of them with inference variables
2. memorizing these inference variables in a side-table
3. at the end of typeck, resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type

This worked okayish for `impl Trait` in return position, but required lots of roundabout type inference hacks and processing.

This PR instead stops this process of replacing opaque types with inference variables, and just keeps the opaque types around.
Whenever an opaque type `O` is compared with another type `T`, we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it, we grab the recorded type (`T`) and compare that against `U`. This makes implementing

* https://github.com/rust-lang/rfcs/pull/2515

much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities).

r? `@nikomatsakis`

fixes #93411
fixes #88236

Auto merge of #87869 - thomcc:skinny-io-error, r=yaahc

Make io::Error use 64 bits on targets with 64 bit pointers.

I've wanted this for a long time, but didn't see a good way to do it without having extra allocation. When looking at it yesterday, it was more clear what to do for some reason.

This approach avoids any additional allocations, and reduces the size by half (8 bytes, down from 16). AFAICT it doesn't come additional runtime cost, and the compiler seems to do a better job with code using it.

Additionally, this `io::Error` has a niche (still), so `io::Result<()>` is *also* 64 bits (8 bytes, down from 16), and `io::Result<usize>` (used for lots of io trait functions) is 2x64 bits (16 bytes, down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally, it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`.

(For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this)

On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it, since one of the fields it stores is a `i32`, so we can't get below that, and it's already about as close as we can get to it.

---

### Isn't Pointer Tagging Dodgy?

The details of the layout, and why its implemented the way it is, are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be, but I didn't trim it down that much, since there's a lot of stuff I did deliberately, that might have not seemed that way.

There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error.

I believe the scheme used to tag it is not UB, and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add`, and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation, so it would follow the safety contract of `core::ptr::{add,sub}`.

The other pointer this had to encode is not tagged — or rather, the tagged repr is equivalent to untagged (it's tagged with 0b00, and has >=4b alignment, so we can reuse the bottom bits). And the other variants we encode are just integers, which (which can be untagged using bitwise operations without worry — they're integers).

CC `@RalfJung` for the stuff in repr_bitpacked.rs, as my comments are informed by a lot of the UCG work, but it's possible I missed something or got it wrong (even if the implementation is okay, there are parts of the header comment that says things like "We can't do $x" which could be false).

---

### Why So Many Changes?

The repr change was mostly internal, but changed one widely used API: I had to switch how `io::Error::new_const` works.

This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static`, rather than just the string. This would have been really tedious, but I made a macro that made it much simpler, but it was a wide change since `io::Error::new_const` is used everywhere.

This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things), so I expect there to be spottiness in CI initially, unless luck is on my side.

Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file), whereas the packing stuff is all in commit 2.

---

P.S. I haven't looked at all of this since writing it, and will do a pass over it again later, sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such.

(It probably could use more tests too. I did some basic testing, and made it so we `debug_assert!` in cases the decode isn't what we encoded, but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal, especially around error cases, although I have no idea).

Fix hover effects in sidebar

The dark and ayu themes have a menu-like highlight on sidebar items. The
light theme used to, but it was accidentally lost in the sidebar
unification. The change brings back the hover effect in the light theme.

It also makes the hover effect apply consistently to all links in the
sidebar, including headings.

It also simplifies the "In _path_" heading so it's one big link. The
breadcrumbs are still readily available at the top of the page.

Add {floor,ceil}_char_boundary methods to str

Rm ValuePairs::Ty/Const

Remove old value pairs which is a strict subset of Terms.

Update rustdoc test

Add test for block doc comments horizontal trim

Add a test showing that we don't infer across multiple uses of the same opaque type but with a different order of generic arguments

Fix horizontal trim for block doc comments

Print opaque types from type aliases via their path

Auto merge of #93738 - m-ou-se:rollup-zjyd2et, r=m-ou-se

Rollup of 13 pull requests

Successful merges:

 - #88313 (Make the pre-commit script pre-push instead)
 - #91530 (Suggest 1-tuple parentheses on exprs without existing parens)
 - #92724 (Cleanup c_str.rs)
 - #93208 (Impl {Add,Sub,Mul,Div,Rem,BitXor,BitOr,BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0)
 - #93394 (Don't allow {} to refer to implicit captures in format_args.)
 - #93416 (remove `allow_fail` test flag)
 - #93487 (Fix linking stage1 toolchain in `./x.py setup`)
 - #93673 (Linkify sidebar headings for sibling items)
 - #93680 (Drop json::from_reader)
 - #93682 (Update tracking issue for `const_fn_trait_bound`)
 - #93722 (Use shallow clones for submodules managed by rustbuild, not just bootstrap.py)
 - #93723 (Rerun bootstrap's build script when RUSTC changes)
 - #93737 (bootstrap: prefer using '--config' over 'RUST_BOOTSTRAP_CONFIG')

Failed merges:

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

Rollup merge of #93737 - mfrw:mfrw/bootstrap-config, r=Mark-Simulacrum

bootstrap: prefer using '--config' over 'RUST_BOOTSTRAP_CONFIG'

Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
Closes: #93725
Rleated: #92260

Rollup merge of #93723 - jyn514:rerun-if-changed, r=Mark-Simulacrum

Rerun bootstrap's build script when RUSTC changes

Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names:

```
$ mkdir tmp && cd tmp
$ ../x.py check
Building rustbuild
    Finished dev [unoptimized] target(s) in 35.27s
Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
^C
$ cd ..
$ mv tmp/build build
$ ./x.py check
Building rustbuild
   Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap)
    Finished dev [unoptimized] target(s) in 11.18s

failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir"
error: No such file or directory (os error 2)
```

This fixes the error. Reusing the same build directory is useful if you want to test path-related things in
bootstrap itself, without having to recompile it each time.

For good measure, this also reruns the build script when PATH changes.

Rollup merge of #93722 - jyn514:less-submodule-cloning, r=Mark-Simulacrum

Use shallow clones for submodules managed by rustbuild, not just bootstrap.py

I missed this in https://github.com/rust-lang/rust/pull/89757; it made
`x.py test src/bootstrap` very slow.

Rollup merge of #93682 - PatchMixolydic:where-in-the-world-is-const_fn_trait_bound, r=oli-obk

Update tracking issue for `const_fn_trait_bound`

It previously pointed to #57563, the conglomerate issue for `const fn` (presumably under the feature gate `const_fn`). This tracking issue doesn't mention anything about `const_fn_trait_bound`(the only occurrence of "trait bound" is for the now-removed `?const Trait` syntax), which can be confusing to people who want to find out more about trait bounds on `const fn`s. This pull request changes the tracking issue to one meant specifically for `const_fn_trait_bound`, #93706, which can help collect information on this feature's stabilization and point users towards `const_trait_impl` if they're looking for const-in-const-contexts trait bounds.

Fixes #93679.

`````@rustbot````` modify labels +A-const-fn +F-const_trait_impl

Rollup merge of #93680 - Mark-Simulacrum:drop-json-reader, r=bjorn3

Drop json::from_reader

Just a small cleanup -- this was essentially unused; the one use site is better suited to reading from &str regardless.

Rollup merge of #93673 - jsha:linkify-sidebar-headings, r=GuillaumeGomez

Linkify sidebar headings for sibling items

Also adjust CSS so this doesn't produce excess padding/margin.

Note: I tried and failed to write a test with browser-UI-test. First I tried to `assert-property: (".block.mod h3 a", {"href": "index.html#macros"})`. But the `href` that gets read out is the fully-quallified URL, starting with `file:///`. That URL will differ depending on what path the test is run from, so that doesn't work.

Next I tried clicking on the appropriate sidebar link, and verifying that the appropriate heading on the next page is highlighted with the right background color. However, that also didn't work: according to browser-UI-test, the targeted heading was plain white. However, running with no-headless, I could see that it actually was yellow. I suspect this is a bug in the older version of Chromium used with browser-UI-test's bundled puppeteer, since it doesn't reproduce on latest Chrome.

Fixes #92957

Demo: https://rustdoc.crud.net/jsha/linkify-sidebar-headings/std/string/trait.ToString.html

r? ``@GuillaumeGomez``

Rollup merge of #93487 - yerke:yerke/fix-link-toolchain-in-setup, r=Mark-Simulacrum

Fix linking stage1 toolchain in `./x.py setup`

Closes [92319](https://github.com/rust-lang/rust/issues/92319)

Fix linking stage1 toolchain in `./x.py setup`. I guess this can be considered a follow up to https://github.com/rust-lang/rust/pull/89212 by `````@Sl1mb0.`````

We create 2 directories and 1 file that are required by rustup to [link a custom toolchain from path](https://github.com/rust-lang/rustup/blob/5225e87a5d974ab5f1626bcb2a7b43f76ab883f0/src/toolchain.rs#L479-L497).

cc `````@jyn514````` and `````@Mark-Simulacrum````` as they were active in https://github.com/rust-lang/rust/issues/89206

Rollup merge of #93416 - name1e5s:chore/remove_allow_fail, r=m-ou-se

remove `allow_fail` test flag

close #93345

Rollup merge of #93394 - m-ou-se:fix-93378, r=estebank

Don't allow {} to refer to implicit captures in format_args.

Fixes #93378

Rollup merge of #93208 - kellerkindt:wrapping_int_assign_impl, r=m-ou-se

Impl {Add,Sub,Mul,Div,Rem,BitXor,BitOr,BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0

Tracking issue #93204

This is about adding basic integer operations to the `Wrapping` type:

```rust
let mut value = Wrapping(2u8);
value += 3u8;
value -= 1u8;
value *= 2u8;
value /= 2u8;
value %= 2u8;
value ^= 255u8;
value |= 123u8;
value &= 2u8;
```

Because this adds stable impls on a stable type, it runs into the following issue if an `#[unstable(...)]` attribute is used:

```
an `#[unstable]` annotation here has no effect
note: see issue #55436 <https://github.com/rust-lang/rust/issues/55436> for more information
```

This means - if I understood this correctly - the new impls have to be stabilized instantly.
Which in turn means, this PR has to kick of an FCP on the tracking issue as well?

This impl is analog to 1c0dc1810d778bb6fea16aac02cafc5aa2e84b11 #92356 for the `Saturating` type ``@dtolnay``  ``@Mark-Simulacrum``

Rollup merge of #92724 - inteon:cleanup, r=Mark-Simulacrum

Cleanup c_str.rs

Some code cleanups in `c_str.rs`.
No functional changes.

ref: https://github.com/bytecodealliance/rustix/pull/163

Rollup merge of #91530 - bobrippling:suggest-1-tuple-parens, r=camelid

Suggest 1-tuple parentheses on exprs without existing parens

A follow-on from #86116, split out from #90677.

This alters the suggestion to add a trailing comma to create a 1-tuple - previously we would only apply this if the relevant expression was parenthesised. We now make the suggestion regardless of parentheses, which reduces the fragility of the check (w.r.t formatting).

e.g.
```rust
let a: Option<(i32,)> = Some(3);
```

gets the below suggestion:

```rust
let a: Option<(i32,)> = Some((3,));
//                           ^ ^^
```

This change also improves the suggestion in other ways, such as by only making the suggestion if the types would match after the suggestion is applied and making the suggestion a multipart suggestion.

Rollup merge of #88313 - jyn514:pre-push, r=Mark-Simulacrum

Make the pre-commit script pre-push instead

This should make it substantially less annoying, and hopefully more
people will find it useful. In particular, it will no longer run tidy
each time you run `git commit --amend` or rebase a branch.

This also warns if you have the old script in pre-commit; see the HACK
comment for details.

r? ````@Mark-Simulacrum```` cc ````@caass````

bootstrap: prefer using '--config' over 'RUST_BOOTSTRAP_CONFIG'

Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>

Auto merge of #93719 - scottmcm:core-as-2021-everywhere, r=Mark-Simulacrum

Build libcore as 2021 in a few more places

The `Cargo.toml` has `edition = "2021"` (as of #92068), so that's what these command lines should use too.

Add `#[no_coverage]` tests for nested functions

Stabilize wrapping_int_assign_impl in 1.60.0.

Add in ValuePair::Term

This adds in an enum when matching on positions which can either be types or consts.
It will default to emitting old special cased error messages for types.

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`

Rerun bootstrap's build script when RUSTC changes

Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names:

```
$ mkdir tmp && cd tmp
$ ../x.py check
Building rustbuild
    Finished dev [unoptimized] target(s) in 35.27s
Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
^C
$ cd ..
$ mv tmp/build build
$ ./x.py check
Building rustbuild
   Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap)
    Finished dev [unoptimized] target(s) in 11.18s

failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir"
error: No such file or directory (os error 2)
```

This fixes the error. Reusing the same build directory is useful if you want to test path-things in
bootstrap itself, without having to recompile it each time.

For good measure, this also reruns the build script when PATH changes.

Use shallow clones for submodules managed by rustbuild, not just bootstrap.py

I missed this in https://github.com/rust-lang/rust/pull/89757; it made
`x.py test src/bootstrap` very slow.

rustdoc: Special-case macro lookups less

Previously, rustdoc had 3 fallbacks it used:
1. `resolve_macro_path`
2. `all_macros`
3. `resolve_str_path_error`

Ideally, it would only use `resolve_str_path_error`, to be consistent with other namespaces.
Unfortunately, that doesn't consider macros that aren't defined at module scope;
consider for instance
```rust
{
    struct S;

    macro_rules! mac { () => {} }
    // `mac`'s scope starts here

    /// `mac` <- `resolve_str_path_error` won't see this
   struct Z;

    //`mac`'s scope ends here
}
```

This changes it to only use `all_macros` and `resolve_str_path_error`, and gives
`resolve_str_path_error` precedence over `all_macros` in case there are two macros with the same
name in the same module.

This also adds a failing test case which will catch trying to remove `all_macros`.

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

Build libcore as 2021 in a few more places

The `Cargo.toml` has `edition = "2021"`, so that's what these command lines should use too.

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

Merge duplicate suggestion string

Factor out emit_tuple_wrap_err, improve Applicability

rewrite from_bytes_with_nul to match code style in from_vec_with_nul

Signed-off-by: Inteon <42113979+inteon@users.noreply.github.com>

Fix tracking issue for `const_fn_trait_bound`

It previously pointed to #57563, the conglomerate issue for
`const fn` (presumably under the feature gate `const_fn`).
`const_fn_trait_bounds` weren't mentioned here, so this commit changes
its tracking issue to a new one.

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`

Linkify sidebar headings for sibling items

Also adjust CSS so this doesn't produce excess padding/margin.

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

fix linking stage1 toolchain in setup

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

Drop json::from_reader

Performing UTF-8 decode outside the JSON module makes more sense in almost all cases.

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`

update comment

resolve lifetimes for const generic defaults

Add more tests for io::Error packing, and fix some comments that weren't quite accurate anymore

Update documentation somewhat

Use wrapping pointer arithmetic in the bitpacked io::Error

Elaborate some in the documentation and respond to some review comments

Update library/std/src/io/error/repr_bitpacked.rs

Co-authored-by: the8472 <the8472@users.noreply.github.com>

Fix comment typos noticed by code review.

Co-authored-by: Ralf Jung <post@ralfj.de>

Address address comments, improve comments slightly

Optimize io::error::Repr layout on 64 bit targets.

Hide Repr details from io::Error, and rework `io::Error::new_const`.

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`