Use revisions for NLL in hrtb

Use revisions for NLL in traits

Use revisions for NLL in async-await

Use revisions or ignore-compare-mode-nll for NLL in generic-associated-types

Use revisions for NLL in generator

Use revisions for NLL in various directories

Use revisions for NLL in object-lifetime

Use revisions for NLL in borrowck

Use revisions for NLL in const-generics and match

Use revisions for NLL in closures

Use revisions for NLL in associated-types

Use revisions for NLL in nll

Use revisions for NLL in impl-trait

Use revisions for NLL (consistently) in higher-ranked-trait-bounds

For hr-subtype test, use check-pass instead of rustc_error and split nll differences to separate test

Auto merge of #97283 - jackh726:rollup-ga84p7n, r=jackh726

Rollup of 5 pull requests

Successful merges:

 - #97043 (Move some tests to more reasonable directories)
 - #97206 (Do leak check after function pointer coercion)
 - #97275 (small change)
 - #97277 (Avoid accidentally enabling unstable features in compilers (take 2))
 - #97280 (Quote replace target in bootstrap configure)

Failed merges:

 - #97214 (Finish bumping stage0)

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

Rollup merge of #97280 - yue4u:quote-replace-target-in-bootstrap-configure, r=Mark-Simulacrum

Quote replace target in bootstrap configure

close #97263

Rollup merge of #97277 - jyn514:no-unstable-for-bootstrap, r=Mark-Simulacrum

Avoid accidentally enabling unstable features in compilers (take 2)

This allows rustbuild to control whether crates can use nightly features or not.
It also prevents rustbuild from using nightly features itself.

This is #92261, but I fixed the CI error.

Rollup merge of #97275 - pro465:patch-1, r=Dylan-DPC

small change

probably not worth writing a comment about...

Rollup merge of #97206 - jackh726:issue-73154, r=nikomatsakis

Do leak check after function pointer coercion

cc #73154

I still need to clean diagnostics just a tad, but figured I would put this up anyways.

This change is made in order to make match arm coercion order-independent.

Basically, any time we do function pointer coercion, we follow it by doing a leak check. This is necessary because the LUB code doesn't handler higher-ranked things correctly, leading us to "coerce", but use the wrong type. A proper fix is to actually fix that code (so the type returned by `unify_and` is a supertype of both `a` and `b` if `Ok`). However, that requires a more in-depth fix, likely heavily overlapping with the new subtyping changes.

Here, I've been conservative and error early if we generate unsatisfiable constraints. Note, this should *mostly* only affect NLL, since migrate mode falls back to the LUB implementation (followed by leak check), whereas NLL only does sub.

There could be other coercion code that has an order-dependence where a leak check in the coercion code might be useful. However, this is more of a spot-fix for #73154 than a "permanent" fix, since we likely want to go the other way long-term, and allow this pattern without error.

r? `@nikomatsakis`

Rollup merge of #97043 - c410-f3r:z-errors, r=petrochenkov

Move some tests to more reasonable directories

r? `@petrochenkov`

Do leak check after function ptr coercion

Disable unstable features in bootstrap tools

This statically prevents issues like https://github.com/rust-lang/rust/issues/59264,
where tools can only be built with the in-tree compiler and not beta.

Quote replace target in bootstrap configure

Avoid accidentally enabling unstable features in compilers (take 2)

This allows rustbuild to control whether crates can use nightly features or not.
It also prevents rustbuild from using nightly features itself.

small change

Auto merge of #97251 - petrochenkov:eqtokens, r=nnethercote

rustc_parse: Move AST -> TokenStream conversion logic to rustc_ast

In the past falling back to reparsing pretty-printed strings was common, so some of this logic had to live in `rustc_parse`, but now the reparsing fallback is only used in two corner cases so we can move this logic to `rustc_ast` which makes many things simpler.

It also helps to fix `MacArgs::inner_tokens` for `MacArgs::Eq` with non-literal expressions, which is done in the second commit.
r? `@nnethercote`

rustc_ast: Support MacArgs::inner_tokens for arbitrary expressions

rustc_parse: Move AST -> TokenStream conversion logic to `rustc_ast`

Auto merge of #95563 - dingxiangfei2009:dxf-rfc66-refactor, r=nikomatsakis

Move the extended lifetime resolution into typeck context

Related to #15023

This PR is based on the [idea](https://github.com/rust-lang/rust/issues/15023#issuecomment-1070931433) of #15023 by `@nikomatsakis.`

This PR specifically proposes to
- Delay the resolution of scopes of rvalues to a later stage, so that enough type information is available to refine those scopes based on relationships of lifetimes.
- Highlight relevant parts that would help future reviews on the next installments of works to fully implement a solution to RFC 66.

factor out the rvalue lifetime rule

remove region_scope_tree from RegionCtxt

Apply suggestions from code review

Co-authored-by: Niko Matsakis <niko@alum.mit.edu>

Auto merge of #97177 - oli-obk:const-stability, r=davidtwco

Implement proper stability check for const impl Trait, fall back to unstable const when undeclared

Continuation of #93960

`@jhpratt` it looks to me like the test was simply not testing for the failure you were looking for? Your checks actually do the right thing for const traits?

Auto merge of #97265 - JohnTitor:rollup-kgthnjt, r=JohnTitor

Rollup of 6 pull requests

Successful merges:

 - #97144 (Fix rusty grammar in `std::error::Reporter` docs)
 - #97225 (Fix `Display` for `cell::{Ref,RefMut}`)
 - #97228 (Omit stdarch workspace from rust-src)
 - #97236 (Recover when resolution did not resolve lifetimes.)
 - #97245 (Fix typo in futex RwLock::write_contended.)
 - #97259 (Fix typo in Mir phase docs)

Failed merges:

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

Rollup merge of #97259 - jyn514:fix-typo, r=JohnTitor

Fix typo in Mir phase docs

Rollup merge of #97245 - m-ou-se:rwlock-state-typo, r=JohnTitor

Fix typo in futex RwLock::write_contended.

I wrote `state` where I should've used `s`.

This was spotted by `@Warrenren.`

This change removes the unnecessary `s` variable to prevent that mistake.

Fortunately, this typo didn't affect the correctness of the lock, as the
second half of the condition (!has_writers_waiting) is enough for
correctness, which explains why this mistake didn't show up during
testing.

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

Rollup merge of #97236 - cjgillot:recover-lifetime-res, r=jackh726

Recover when resolution did not resolve lifetimes.

This can happen for items inside a foreign fn's body, which are not visited at all.

Fixes https://github.com/rust-lang/rust/issues/97193
Fixes https://github.com/rust-lang/rust/issues/97194

Rollup merge of #97228 - jonhoo:patch-1, r=bjorn3

Omit stdarch workspace from rust-src

The path `library/stdarch/crates/Cargo.toml` does not exist.

In Rust 1.61.0, `rust-src` still includes `src/rust/library/stdarch/Cargo.toml` (but not `stdarch-verify`), which includes
```toml
[workspace]
members = [
  "crates/stdarch-verify"
```

This didn't show up when testing with `-Zbuild-std` in https://github.com/rust-lang/rust/pull/94907 since the [standard list of crates](https://github.com/rust-lang/cargo/blob/f624095e1c98228a74a165ddb702078c0dd8b81e/src/cargo/core/compiler/standard_lib.rs#L26-L30) to include when building `std` does not include `stdarch`, but it will show up if a user explicitly requests `stdarch`. Or, perhaps more importantly, because of https://github.com/rust-lang/rust/issues/95736, many editors (like IntelliJ) won't treat the root of `rust-src` as a workspace, and will instead recurse into all the sub-crates directly, which then includes `stdarch`.

Also related to https://github.com/rust-lang/rust/issues/94906.

Rollup merge of #97225 - cuviper:ref-display, r=scottmcm

Fix `Display` for `cell::{Ref,RefMut}`

These guards changed to pointers in #97027, but their `Display` was
formatting that field directly, which made it show the raw pointer
value. Now we go through `Deref` to display the real value again.

Miri noticed this change, #97204, so hopefully that will be fixed.

Rollup merge of #97144 - samziz:patch-1, r=Dylan-DPC

Fix rusty grammar in `std::error::Reporter` docs

### Commit

I initially saw "print's" instead of "prints" at the start of the doc comment for `std::error::Reporter`, while reading the docs for that type. Then I figured 'probably more where that came from', so, as well as correcting the foregoing to "prints", I've patched up these three minor solecisms (well, two [types](https://en.wikipedia.org/wiki/Type%E2%80%93token_distinction), three [tokens](https://en.wikipedia.org/wiki/Type%E2%80%93token_distinction)):

- One use of the indicative which should be subjunctive - indeed the sentence immediately following it, which mirrors its structure, _does_ use the subjunctive ([L871](https://github.com/rust-lang/rust/blob/master/library/std/src/error.rs?plain=1#L871)). Replaced with the subjunctive.
- Two separate clauses joined with commas ([L975](https://github.com/rust-lang/rust/blob/master/library/std/src/error.rs?plain=1#L975), [L1023](https://github.com/rust-lang/rust/blob/master/library/std/src/error.rs?plain=1#L1023)). Replaced the first with a semicolon and the second with a period. Admittedly those judgements are pretty much 100% subjective, based on my sense of how the sentences flowed into each other (though ofc the _replacement of the comma itself_ is not subjective or opinion-based).

I know this is silly and finicky, but I hope it helps tidy up the docs a bit for future readers!

### PR notes

**This is very much non-urgent (and, honestly, non-important).** I just figured it might be a nice quality-of-life improvement and bit of tidying up for the core contributors themselves not to have to do. 🙂

I'm tagging Steve, per the [contributing guidelines](https://rustc-dev-guide.rust-lang.org/contributing.html#r) ("Steve usually reviews documentation changes. So if you were to make a documentation change, add `r? `@steveklabnik`"):`

r? `@steveklabnik`

Auto merge of #94119 - c410-f3r:array-again-and-again, r=scottmcm

Stabilize `array_from_fn`

## Overall

Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays.

Signature proposed for stabilization here, tweaked as requested in the meeting:

```rust
// in core::array

pub fn from_fn<T, const N: usize, F>(_: F) -> [T; N];
```

Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html

## History

* On 2020-08-17, implementation was [proposed](https://github.com/rust-lang/rust/pull/75644).
* On 2021-09-29, tracking issue was [created](https://github.com/rust-lang/rust/issues/89379).
* On 2021-10-09, the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c).
* On 2021-12-03, the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407).

## Considerations

* It is being assumed that indices are useful and shouldn't be removed from the callbacks
* The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it.
* The addition or not of repeat-like variants is orthogonal to this PR.

These considerations are not ways of saying what is better or what is worse. In reality, they are an attempt to move things forward, anything really.

cc https://github.com/rust-lang/rust/issues/89379

Auto merge of #96515 - lcnr:user-types-in-pat, r=nikomatsakis

correctly deal with user type ascriptions in pat

supersedes #93856

`thir::PatKind::AscribeUserType` previously resulted in `CanonicalUserTypeAnnotations` where the inferred type already had a subtyping relation according to `variance` to the `user_ty`.

The bug can pretty much be summarized as follows:

- during mir building
  - `user_ty -> inferred_ty`: considers variance
  - `StatementKind::AscribeUserType`: `inferred_ty` is the type of the place, so no variance needed
- during mir borrowck
  - `user_ty -> inferred_ty`: does not consider variance
  - `StatementKind::AscribeUserType`: applies variance

This mostly worked fine. The lifetimes in `inferred_ty` were only bound by its relation to `user_ty` and to the `place` of `StatementKind::AscribeUserType`, so it doesn't matter where exactly the subtyping happens.

It does however matter when having higher ranked subtying. At this point the place where the subtyping happens is forced, causing this mismatch between building and borrowck to result in unintended errors.

cc #96514 which is pretty much the same issue

r? `@nikomatsakis`

Fix typo in Mir phase docs

Auto merge of #94530 - tmiasko:alignment-impls, r=dtolnay

Implement Copy, Clone, PartialEq and Eq for core::fmt::Alignment

Alignment is a fieldless exhaustive enum, so it is already possible to
clone and compare it by matching, but it is inconvenient to do so. For
example, if one would like to create a struct describing a formatter
configuration and provide a clone implementation:

```rust
pub struct Format {
    fill: char,
    width: Option<usize>,
    align: fmt::Alignment,
}

impl Clone for Format {
    fn clone(&self) -> Self {
        Format {
            align: match self.align {
                fmt::Alignment::Left => fmt::Alignment::Left,
                fmt::Alignment::Right => fmt::Alignment::Right,
                fmt::Alignment::Center => fmt::Alignment::Center,
            },
            .. *self
        }
    }
}
```

Derive Copy, Clone, PartialEq, and Eq for Alignment for convenience.

Auto merge of #97248 - xFrednet:clippyup, r=Manishearth

Clippyup

This direction was simpler. All test Clippy pass locally :upside_down_face:

r? `@Manishearth`

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

update Miri

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

update nll tests

Fix lint registration

Auto merge of #97246 - GuillaumeGomez:rollup-btcok8x, r=GuillaumeGomez

Rollup of 7 pull requests

Successful merges:

 - #97190 (Add implicit call to from_str via parse in documentation)
 - #97218 (Add eslint checks)
 - #97219 (make ptr::invalid not the same as a regular int2ptr cast)
 - #97223 (Remove quadratic behaviour from -Zunpretty=hir-tree.)
 - #97232 (typo)
 - #97237 (Add some more weird-exprs)
 - #97238 (Bump LLVM fetched from CI to fix run-make)

Failed merges:

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

Merge 'rust-clippy/master' into clippyup

update Miri

Rollup merge of #97238 - Mark-Simulacrum:bump-ci-llvm, r=jyn514

Bump LLVM fetched from CI to fix run-make

cc `@yaahc,` who found this while testing locally

Ideally we'd detect this in CI and catch it, but at least we have a comment now which should hopefully prevent this from happening in the future.

r? `@pietroalbini` or `@jyn514`

Rollup merge of #97237 - oberien:patch-1, r=Dylan-DPC

Add some more weird-exprs

Continuing from https://github.com/rust-lang/rust/pull/86713 (which stalled due to a thinking emoji), I'd like to "improve" the `weird-exprs.rs`-file (as I can't reopen that PR).

Rollup merge of #97232 - tshepang:typo, r=Dylan-DPC

typo

Rollup merge of #97223 - cjgillot:linear-hir-tree, r=jackh726

Remove quadratic behaviour from -Zunpretty=hir-tree.

Closes https://github.com/rust-lang/rust/issues/97115

Rollup merge of #97219 - RalfJung:ptr-invalid, r=thomcc

make ptr::invalid not the same as a regular int2ptr cast

In Miri, we would like to distinguish `ptr::invalid` from `ptr::from_exposed_provenance`, so that we can provide better diagnostics issues like https://github.com/rust-lang/miri/issues/2134, and so that we can detect the UB in programs like
```rust
fn main() {
    let x = 0u8;
    let original_ptr = &x as *const u8;
    let addr = original_ptr.expose_addr();
    let new_ptr: *const u8 = core::ptr::invalid(addr);
    unsafe {
        dbg!(*new_ptr);
    }
}
```

To achieve that, the two functions need to have different implementations. Currently, both are just `as` casts. We *could* add an intrinsic for this, but it turns out `transmute` already has the right behavior, at least as far as Miri is concerned. So I propose we just use that.

Cc `@Gankra`

Rollup merge of #97218 - GuillaumeGomez:eslint-checks, r=notriddle

Add eslint checks

The first check is to ensure that `=>` is always surrounded with whitespaces.

The second is to ensure that the dict objects looks like this: `{"a": 2}` and not `{"a" : 2}` or `{"a":2}`.

r? ``@notriddle``

Rollup merge of #97190 - SylvainDe:master, r=Dylan-DPC

Add implicit call to from_str via parse in documentation

The documentation mentions "FromStr’s from_str method is often used implicitly,
through str’s parse method. See parse’s documentation for examples.".

It may be nicer to show that in the code example as well.

Fix typo in futex RwLock::write_contended.

I wrote `state` where I should've used `s`.

This removes the unnecessary `s` variable to prevent that mistake.

Fortunately, this typo didn't affect the correctness of the lock, as the
second half of the condition (!has_writers_waiting) is enough for
correctness, which explains why this mistake didn't show up during
testing.

Auto merge of #93963 - GuillaumeGomez:reduce-clean-type-size, r=notriddle

rustdoc: Reduce clean::Type size

There is no need to keep the `DefId` around since it's allow used to compute if we should show a cast or not. As such, we can simply directly store the boolean.

I think it's not what you had in mind `@camelid` but I guess it's still an improvement? :wink:

It was discussed in https://github.com/rust-lang/rust/pull/93941.

r? `@camelid`

Recover when resolution did not resolve lifetimes.

Auto merge of #97239 - jhpratt:remove-crate-vis, r=joshtriplett

Remove `crate` visibility modifier

FCP to remove this syntax is just about complete in #53120. Once it completes, this should be merged ASAP to avoid merge conflicts.

The first two commits remove usage of the feature in this repository, while the last removes the feature itself.

update mir dumps

update mir user type printing and apparently fix an ICE

correctly deal with user type ascriptions in pat

Remove `crate` visibility modifier in libs, tests

Auto merge of #96923 - eholk:fix-fake-read, r=nikomatsakis

Drop Tracking: Implement `fake_read` callback

This PR updates drop tracking's use of `ExprUseVisitor` so that we treat `fake_read` events as borrows. Without doing this, we were not handling match expressions correctly, which showed up as a breakage in the `addassign-yield.rs` test. We did not previously notice this because we still had rather large temporary scopes that we held borrows for, which changed in #94309.

This PR also includes a variant of the `addassign-yield.rs` test case to make sure we continue to have correct behavior here with drop tracking.

r? `@nikomatsakis`

Auto merge of #96605 - Urgau:string-retain-codegen, r=thomcc

Improve codegen of String::retain method

This pull-request improve the codegen of the `String::retain` method.

Using `unwrap_unchecked` helps the optimizer to not generate a panicking path that will never be taken for valid UTF-8 like string.

Using `encode_utf8` saves us from an expensive call to `memcpy`, as the optimizer is unable to realize that `ch_len <= 4` and so can generate much better assembly code.

https://rust.godbolt.org/z/z73ohenfc

Remove `crate` visibility usage in compiler

Auto merge of #95824 - zx2c4-forks:grnd_insecure, r=thomcc

Use GRND_INSECURE instead of /dev/urandom when possible

From reading the source code, it appears like the desired semantic of
std::unix::rand is to always provide some bytes and never block. For
that reason GRND_NONBLOCK is checked before calling getrandom(0), so
that getrandom(0) won't block. If it would block, then the function
falls back to using /dev/urandom, which for the time being doesn't
block. There are some drawbacks to using /dev/urandom, however, and so
getrandom(GRND_INSECURE) was created as a replacement for this exact
circumstance.

getrandom(GRND_INSECURE) is the same as /dev/urandom, except:

- It won't leave a warning in dmesg if used at early boot time, which is
  a common occurance (and the reason why I found this issue);

- It won't introduce a tiny delay at early boot on newer kernels when
  /dev/urandom tries to opportunistically create jitter entropy;

- It only requires 1 syscall, rather than 3.

Other than that, it returns the same "quality" of randomness as
/dev/urandom, and never blocks.

It's only available on kernels ≥5.6, so we try to use it, cache the
result of that attempt, and fall back to to the previous code if it
didn't work.

Bump LLVM fetched from CI to fix run-make

Add back thinking emoji

Add a function returning itself to weird-exprs

Add unicode identifier to weird-exprs

Use unicode identifiers and a unicode emoji in weird-exprs.rs

Make the most special expression even more special

Add or-pattern syntax in argument position

Use GRND_INSECURE instead of /dev/urandom when possible

From reading the source code, it appears like the desired semantic of
std::unix::rand is to always provide some bytes and never block. For
that reason GRND_NONBLOCK is checked before calling getrandom(0), so
that getrandom(0) won't block. If it would block, then the function
falls back to using /dev/urandom, which for the time being doesn't
block. There are some drawbacks to using /dev/urandom, however, and so
getrandom(GRND_INSECURE) was created as a replacement for this exact
circumstance.

getrandom(GRND_INSECURE) is the same as /dev/urandom, except:

- It won't leave a warning in dmesg if used at early boot time, which is
  a common occurance (and the reason why I found this issue);

- It won't introduce a tiny delay at early boot on newer kernels when
  /dev/urandom tries to opportunistically create jitter entropy;

- It only requires 1 syscall, rather than 3.

Other than that, it returns the same "quality" of randomness as
/dev/urandom, and never blocks.

It's only available on kernels ≥5.6, so we try to use it, cache the
result of that attempt, and fall back to to the previous code if it
didn't work.

Update libc dependency of std to 0.2.126

This is required for the next commit, which uses libc::GRND_INSECURE.

Auto merge of #8856 - xFrednet:rustup, r=Manishearth,Alexendoo

Rustup

`@rust-lang/clippy,` `@Jarcho,` `@dswij,` `@Alexendoo.` Could someone review this? It should be pretty straight forward since it's just a sync. I think it's also fine if either one of `@Jarcho,` `@dswij,` `@Alexendoo` approves this, as these are usually not reviewed. I just want to make sure that I didn't break something obvious :upside_down_face:

It should be enough to look at the merge commit :upside_down_face:

changelog: none
changelog: move [`significant_drop_in_scrutinee`] to `suspicious`

Remove duplicated code and ignore deadlock test

Auto merge of #8852 - Alexendoo:indirect-disallowed-methods, r=Manishearth

Lint indirect usages in `disallowed_methods`

Fixes #8849

changelog: Lint indirect usages in [`disallowed_methods`]

Auto merge of #95418 - cjgillot:more-disk, r=davidtwco

Cache more queries on disk

One of the principles of incremental compilation is to allow saving results on disk to avoid recomputing them.
This PR investigates persisting a lot of queries whose result are to be saved into metadata.
Some of the queries are cheap reads from HIR, but we may also want to get rid of these reads for incremental lowering.

typo

Update compiler/rustc_typeck/src/check/generator_interior/drop_ranges/record_consumed_borrow.rs

Omit stdarch workspace from rust-src

The path `library/stdarch/crates/Cargo.toml` does not exist.

This was introduced in #94907.

Update clippy version `0.1.62` -> `0.1.63`

move  to sus and fix dogfood

Merge remote-tracking branch 'upstream/master' into rustup

Add eslint key-spacing check

Add eslint arrow-spacing check

Auto merge of #97224 - matthiaskrgr:rollup-it5nw68, r=matthiaskrgr

Rollup of 7 pull requests

Successful merges:

 - #97109 (Fix misleading `cannot infer type for type parameter` error)
 - #97187 (Reverse condition in Vec::retain_mut doctest)
 - #97201 (Fix typo)
 - #97203 (Minor tweaks to rustc book summary formatting.)
 - #97208 (Do not emit the lint `unused_attributes` for *inherent* `#[doc(hidden)]` associated items)
 - #97215 (Add complexity estimation of iterating over HashSet and HashMap)
 - #97220 (Add regression test for#81827)

Failed merges:

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

Fix `Display` for `cell::{Ref,RefMut}`

These guards changed to pointers in #97027, but their `Display` was
formatting that field directly, which made it show the raw pointer
value. Now we go through `Deref` to display the real value again.

Rollup merge of #97220 - JohnTitor:issue-81827, r=compiler-errors

Add regression test for#81827

Closes #81827
r? `@compiler-errors`

Rollup merge of #97215 - AngelicosPhosphoros:add_hashtable_iteration_complexity_note, r=thomcc

Add complexity estimation of iterating over HashSet and HashMap

It is not obvious (at least for me) that complexity of iteration over hash tables depends on capacity and not length. Especially comparing with other containers like Vec or String. I think, this behaviour is worth mentioning.

I run benchmark which tests iteration time for maps with length 50 and different capacities and get this results:
```
capacity - time
64       - 203.87 ns
256      - 351.78 ns
1024     - 607.87 ns
4096     - 965.82 ns
16384    - 3.1188 us
```

If you want to dig why it behaves such way, you can look current implementation in [hashbrown code](https://github.com/rust-lang/hashbrown/blob/f3a9f211d06f78c5beb81ac22ea08fdc269e068f/src/raw/mod.rs#L1933).

Benchmarks code would be presented in PR related to this commit.

Rollup merge of #97208 - fmease:fix-issue-97205, r=oli-obk

Do not emit the lint `unused_attributes` for *inherent* `#[doc(hidden)]` associated items

Fixes #97205 (embarrassing oversight from #96008).

`@rustbot` label A-lint

Rollup merge of #97203 - ehuss:rustc-summary-formatting, r=Dylan-DPC

Minor tweaks to rustc book summary formatting.

This includes a few minor tweaks to the summary/titles of chapters for the rustc book:

* Use a consistent chapter capitalization and hyphenation.
* Move "Codegen Options" underneath "Command-line Arguments". I feel like they are two closely related chapters, where codegen is just a subset of the total arguments.
* Move "Target Tier Policy" underneath "Platform Support". That chapter includes that policy for platform support, and thus I feel it is more closely related to that grouping.

Rollup merge of #97201 - ydah:fix_spelling, r=GuillaumeGomez

Fix typo

This PR is fixes typo "avaiable" to "available".

Rollup merge of #97187 - ajtribick:patch-1, r=thomcc

Reverse condition in Vec::retain_mut doctest

I find that the doctest for `Vec::retain_mut` is easier to read and understand when the `if` block corresponds to the path that returns `true` and the `else` block returns `false`. Having the `if` block be the `false` path led me to stare at the example for somewhat longer than I probably had to.

Rollup merge of #97109 - TaKO8Ki:fix-misleading-cannot-infer-type-for-type-parameter-error, r=oli-obk

Fix misleading `cannot infer type for type parameter` error

closes #93198

Remove quadratic behaviour from -Zunpretty=hir-tree.

Add regression test for #81827

Add complexity estimation of iterating over HashSet and HashMap

It is not obvious (at least for me) that complexity of iteration over hash tables depends on capacity and not length. Especially comparing with other containers like Vec or String. I think, this behaviour is worth mentioning.

I run benchmark which tests iteration time for maps with length 50 and different capacities and get this results:
```
capacity - time
64       - 203.87 ns
256      - 351.78 ns
1024     - 607.87 ns
4096     - 965.82 ns
16384    - 3.1188 us
```

If you want to dig why it behaves such way, you can look current implementation in [hashbrown code](https://github.com/rust-lang/hashbrown/blob/f3a9f211d06f78c5beb81ac22ea08fdc269e068f/src/raw/mod.rs#L1933).

Benchmarks code would be presented in PR related to this commit.