rustdoc: remove unused Hash impl

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

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.

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.

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

Configure panic hook backtrace behavior

Rollup merge of #93592 - est31:remove_unused_deps, r=bjorn3

Remove unused dep from rustc_arena

Rollup merge of #93590 - est31:let_else, r=lcnr

More let_else adoptions

Continuation of #89933, #91018, #91481, #93046.

Rollup merge of #93574 - compiler-errors:bad-let-suggestion, r=lcnr

don't suggest adding `let` due to bad assignment expressions inside of `while` loop

adds a check that our `lhs` expression is actually within the conditional part of the `while` loop, instead of anywhere in the `while` body.

fixes #93486

Rollup merge of #93571 - compiler-errors:better-where-suggestion, r=lcnr

better suggestion for duplicated `where` clause

fixes #93567

Rollup merge of #93546 - tmiasko:validate-switch-int, r=oli-obk

Validate that values in switch int terminator are unique

Rollup merge of #93542 - GuillaumeGomez:lifetime-elision, r=oli-obk

Prevent lifetime elision in type alias

Fixes #93401.

Apparently, the problem has been fixed in the compiler.

r? `@oli-obk`

Rollup merge of #93221 - alyssaverkade:fix-93093, r=wesleywiser

[borrowck] Fix help on mutating &self in async fns

Previously, when rustc was provided an async function that tried to
mutate through a shared reference to an implicit self (as shown in the
ui test), rustc would suggest modifying the parameter signature
to `&mut` + the fully qualified name of the ty (in the case of the repro
`S`). If a user modified their code to match the suggestion, the
compiler would not accept it.

This commit modifies the suggestion so that when rustc is provided the
ui test that is also attached in this commit, it suggests (correctly)
`&mut self`. We try to be careful about distinguishing between implicit
and explicit self annotations, since the latter seem to be handled
correctly already.

This is my first PR here so I'm pretty sure I probably missed something/could use better terminology. I also didn't try to make the match exhaustive since implicit self is the only real special case that I need to handle (that I'm aware of), and I'm pretty sure there's a cleaner way to do this so any advice would be greatly appreciated! (I'm also not terribly confident about how I wrote the ui tests)

here is your cc as requested `@compiler-errors`

This is an attempt to fix #93093

Rollup merge of #92528 - tmiasko:combine-commutative, r=michaelwoerister

Make `Fingerprint::combine_commutative` associative

The previous implementation swapped lower and upper 64-bits of a result
of modular addition, so the function was non-associative.

r? `@Aaron1011`

Remove unused dep from rustc_arena

More let_else adoptions

Auto merge of #93312 - pierwill:map-all-local-trait-impls, r=cjgillot

Return an indexmap in `all_local_trait_impls` query

The data structure previously used here required that `DefId` be `Ord`. As part of #90317, we do not want `DefId` to implement `Ord`.

Use Option::then in two places

Auto merge of #93154 - michaelwoerister:fix-generic-closure-and-generator-debuginfo, r=wesleywiser

debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo.

Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name.

This commit also emits `{closure_env#0}` as the name of these types in order to disambiguate them from the accompanying closure function (which keeps being called `{closure#0}`). Previously both were assigned the same name.

NOTE: Changing debuginfo names like this can break pretty printers and other debugger plugins. I think it's OK in this particular case because the names we are changing were ambiguous anyway. In general though it would be great to have a process for doing changes like these.

Auto merge of #93573 - matthiaskrgr:rollup-nrjmygz, r=matthiaskrgr

Rollup of 7 pull requests

Successful merges:

 - #92758 (librustdoc: impl core::fmt::Write for rustdoc::html::render::Buffer)
 - #92788 (Detect `::` -> `:` typo in type argument)
 - #93420 (Improve wrapping on settings page)
 - #93493 (Document valid values of the char type)
 - #93531 (Fix incorrect panic message in example)
 - #93559 (Add missing | between print options)
 - #93560 (Fix two incorrect "it's" (typos in comments))

Failed merges:

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

better suggestion for duplicated `where`

don't suggest adding `let` due to expressions inside of `while` loop

Rollup merge of #93560 - steffahn:a_typo, r=petrochenkov

Fix two incorrect "it's" (typos in comments)

Found one of these while reading the documentation online. The other came up because it's in the same file.

Rollup merge of #93559 - danielframpton:link-args-typo, r=oli-obk

Add missing | between print options

The help text for the newly stabilized print option is missing a | between stack-protector-strategies and link-args.

Rollup merge of #93531 - TheColdVoid:patch-1, r=m-ou-se

Fix incorrect panic message in example

The panic message when calling the `connect()` should probably be a  message about connection failure, not a message about binding address failure.

Rollup merge of #93493 - GKFX:char-docs-2, r=scottmcm

Document valid values of the char type

As discussed at #93392, the current documentation on what constitutes a valid char isn't very detailed and is partly on the MAX constant rather than the type itself.

This PR expands on that information, stating the actual numerical range, giving examples of what won't work, and also mentions how a `char` might be a valid USV but still not be a defined character (terminology checked against [Unicode 14.0, table 2-3](https://www.unicode.org/versions/Unicode14.0.0/ch02.pdf#M9.61673.TableTitle.Table.22.Types.of.Code.Points)).

Rollup merge of #93420 - jsha:adjust-settings-layout, r=GuillaumeGomez

Improve wrapping on settings page

Previously, the radio button choices for themes would wrap awkwardly on
narrow screens. With this change, the group of choices will prefer
bumping down to the next line together, leaving the setting name on its
own line.

Also fix some minor spacing issues:

 - Align the setting name vertically with the radio button choices.
 - Use margin instead of padding for most spacing choices.
 - Use no margin/padding on the right-hand side.

 Demo: https://rustdoc.crud.net/jsha/adjust-settings-layout/settings.html

 r? ``@GuillaumeGomez``

Before (narrow screen):


After (narrow screen):


Rollup merge of #92788 - estebank:colon-colon, r=cjgillot

Detect `::` -> `:` typo in type argument

When writing `Vec<A:B>`, suggest `Vec<A::B>`.

Rollup merge of #92758 - mfrw:mfrw/rustdoc-impl-write, r=GuillaumeGomez

librustdoc: impl core::fmt::Write for rustdoc::html::render::Buffer

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

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.

Auto merge of #93466 - cjgillot:query-dead, r=nagisa

Make dead code check a query.

Dead code check is run for each invocation of the compiler, even if no modifications were involved.
This PR makes dead code check a query keyed on the module. This allows to skip the check when a module has not changed.
To perform this, a query `live_symbols_and_ignored_derived_traits` is introduced to encapsulate the global analysis of finding live symbols. The second query `check_mod_deathness` outputs diagnostics for each module based on this first query's results.

Detect `::` -> `:` typo in type argument

When writing `Vec<A:B>`, suggest `Vec<A::B>`.

Auto merge of #93285 - JulianKnodt:const_eq_2, r=oli-obk

Continue work on associated const equality

This actually implements some more complex logic for assigning associated consts to values.
Inside of projection candidates, it now defers to a separate function for either consts or
types. To reduce amount of code, projections are now generic over T, where T is either a Type or
a Const. I can add some comments back later, but this was the fastest way to implement it.

It also now finds the correct type of consts in type_of.

---

The current main TODO is finding the const of the def id for the LeafDef.

Right now it works if the function isn't called, but once you use the trait impl with the bound it fails inside projection.
I was hoping to get some help in getting the `&'tcx ty::Const<'tcx>`, in addition to a bunch of other `todo!()`s which I think may not be hit.

r? `@oli-obk`

Updates #92827

Fix annotation of code blocks

Fix two incorrect "it's"

Add missing | between print options

Fix w/ comments

Auto merge of #93442 - yaahc:Termination-abstraction, r=Mark-Simulacrum

Change Termination::report return type to ExitCode

Related to https://github.com/rust-lang/rust/issues/43301

The goal of this change is to minimize the forward compatibility risks in stabilizing Termination. By using the opaque type `ExitCode` instead of an `i32` we leave room for us to evolve the API over time to provide what cross-platform consistency we can / minimize footguns when working with exit codes, where as stabilizing on `i32` would limit what changes we could make in the future in how we represent and construct exit codes.

Auto merge of #93548 - matthiaskrgr:rollup-f7dkn3p, r=matthiaskrgr

Rollup of 7 pull requests

Successful merges:

 - #86374 (Enable combining `+crt-static` and `relocation-model=pic` on `x86_64-unknown-linux-gnu`)
 - #91828 (Implement `RawWaker` and `Waker` getters for underlying pointers)
 - #92021 (Eliminate duplicate codes of is_single_fp_element)
 - #92584 (add rustc lint, warning when iterating over hashmaps 2)
 - #93267 (implement a lint for suspicious auto trait impls)
 - #93290 (remove `TyS::same_type`)
 - #93436 (Update compiler_builtins to fix duplicate symbols in `armv7-linux-androideabi` rlib)

Failed merges:

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

Rollup merge of #93436 - dcsommer:master, r=Mark-Simulacrum

Update compiler_builtins to fix duplicate symbols in `armv7-linux-androideabi` rlib

I ran `./x.py dist --host= --target=armv7-linux-androideabi` before this diff:
```
$ nm build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/armv7-linux-androideabi/lib/libcompiler_builtins-3d9661a82c59c66a.rlib 2> /dev/null | grep __sync_fetch_and_add_4 | wc -l
2
```
And after:
```
$ nm build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/armv7-linux-androideabi/lib/libcompiler_builtins-ffd2745070943321.rlib 2> /dev/null | grep __sync_fetch_and_add_4 | wc -l
1
```
Fixes #93310

See also https://github.com/rust-lang/compiler-builtins/issues/449 and https://github.com/rust-lang/compiler-builtins/pull/450

Rollup merge of #93290 - lcnr:same_type, r=jackh726

remove `TyS::same_type`

This function ignored regions and constants in adts, but didn't do so for references or any other types. cc https://github.com/rust-lang/rust/pull/93148#discussion_r791408057

Rollup merge of #93267 - lcnr:auto-trait-lint, r=nikomatsakis

implement a lint for suspicious auto trait impls

cc https://github.com/rust-lang/rust/pull/85048#issuecomment-1019805102

r? ``@nikomatsakis``

Rollup merge of #92584 - lcnr:query-stable-lint, r=estebank

add rustc lint, warning when iterating over hashmaps 2

first introduced in #89558 and reverted in #90380 due to its perf impact

r? ``@estebank``

Rollup merge of #92021 - woodenarrow:br_single_fp_element, r=Mark-Simulacrum

Eliminate duplicate codes of is_single_fp_element

There are duplicate codes of is_single_fp_element function. Merge these codes to TyAndLayout impl block.

Rollup merge of #91828 - oxalica:feat/waker-getters, r=dtolnay

Implement `RawWaker` and `Waker` getters for underlying pointers

implement #87021

New APIs:
- `RawWaker::data(&self) -> *const ()`
- `RawWaker::vtable(&self) -> &'static RawWakerVTable`
- ~`Waker::as_raw_waker(&self) -> &RawWaker`~ `Waker::as_raw(&self) -> &RawWaker`

This third one is an auxiliary function to make the two APIs above more useful. Since we can only get `&Waker` in `Future::poll`, without this, we need to `transmute` it into `&RawWaker` (relying on `repr(transparent)`) in order to access its data/vtable pointers.

~Not sure if it should be named `as_raw` or `as_raw_waker`. Seems we always use `as_<something-raw>` instead of just `as_raw`. But `as_raw_waker` seems not quite consistent with `Waker::from_raw`.~ As suggested in https://github.com/rust-lang/rust/pull/91828#discussion_r770729837, use `as_raw`.

Rollup merge of #86374 - bossmc:enable-static-pie-for-gnu, r=nagisa

Enable combining `+crt-static` and `relocation-model=pic` on `x86_64-unknown-linux-gnu`

Modern `gcc` versions support `-static-pie`, and `rustc` will already fall-back to `-static` if the local `gcc` is too old (and hence this change is optimistic rather than absolute).  This brings the `-musl` and `-gnu` targets to feature compatibility (albeit with different default settings).

Of note a `-static` or `-static-pie` binary based on glibc that uses NSS-backed functions (`gethostbyname` or `getpwuid` etc.) need to have access to the `libnss_X.so.2` libraries and any of their dynamic dependencies.

I wasn't sure about the `# only`/`# ignore` changes (I've not got a `gnux32` toolchain to test with hence not also enabling `-static-pie` there).

Auto merge of #93284 - eholk:disable-drop-range-analysis, r=pnkfelix

Disable drop range analysis

The previous PR, #93165, still performed the drop range analysis despite ignoring the results. Unfortunately, there were ICEs in the analysis as well, so some packages failed to build (see the issue #93197 for an example). This change further disables the analysis and just provides dummy results in that case.

librustdoc: render: use render_into instead of creating a temp string

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

librustdoc: inline and forward all methods for `impl Write for Buffer`

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

librustdoc: impl core::fmt::Write for rustdoc::html::render::Buffer

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

Make dead code check a query.

Add test to ensure lifetime is not elided in type alias

Fix lifetime elision in type aliases

remove `TyS::same_type`

it ignored regions and constants in adts,
but didn't do so for references or any other types.
This seemed quite weird

Auto merge of #86988 - thomcc:chunky-splitz-says-no-checking, r=the8472

Carefully remove bounds checks from some chunk iterator functions

So, I was writing code that requires the equivalent of `rchunks(N).rev()` (which isn't the same as forward `chunks(N)` — in particular, if the buffer length is not a multiple of `N`, I must handle the "remainder" first).

I happened to look at the codegen output of the function (I was actually interested in whether or not a nested loop was being unrolled — it was), and noticed that in the outer `rchunks(n).rev()` loop, LLVM seemed to be unable to remove the bounds checks from the iteration: https://rust.godbolt.org/z/Tnz4MYY8f (this panic was from the split_at in `RChunks::next_back`).

After doing some experimentation, it seems all of the `next_back` in the non-exact chunk iterators have the issue: (`Chunks::next_back`, `RChunks::next_back`, `ChunksMut::next_back`, and `RChunksMut::next_back`)...

Even worse, the forward `rchunks` iterators sometimes have the issue as well (... but only sometimes). For example https://rust.godbolt.org/z/oGhbqv53r has bounds checks, but if I uncomment the loop body, it manages to remove the check (which is bizarre, since I'd expect the opposite...). I suspect it's highly dependent on the surrounding code, so I decided to remove the bounds checks from them anyway. Overall, this change includes:
- All `next_back` functions on the non-`Exact` iterators (e.g. `R?Chunks(Mut)?`).
- All `next` functions on the non-exact rchunks iterators (e.g. `RChunks(Mut)?`).

I wasn't able to catch any of the other chunk iterators failing to remove the bounds checks (I checked iterations over `r?chunks(_exact)?(_mut)?` with constant chunk sizes under `-O3`, `-Os`, and `-Oz`), which makes sense, since these were the cases where it was harder to prove the bounds check correct to remove...

In fact, it took quite a bit of thinking to convince myself that using unchecked_ here was valid — so I'm not really surprised that LLVM had trouble (although compilers are slightly better at this sort of reasoning than humans). A consequence of that is the fact that the `// SAFETY` comment for these are... kinda long...

---

I didn't do this for, or even think about it for, any of the other iteration methods; just `next` and `next_back` (where it mattered). If this PR is accepted, I'll file a follow up for someone (possibly me) to look at the others later (in particular, `nth`/`nth_back` looked like they had similar logic), but I wanted to do this now, as IMO `next`/`next_back` are the most important here, since they're what gets used by the iteration protocol.

---

Note: While I don't expect this to impact performance directly, the panic is a side effect, which would otherwise not exist in these loops. That is, this could prevent the compiler from being able to move/remove/otherwise rework a loop over these iterators (as an example, it could not delete the code for a loop whose body computes a value which doesn't get used).

Also, some like to be able to have confidence this code has no panicking branches in the optimized code, and "no bounds checks" is kinda part of the selling point of Rust's iterators anyway.

fix for the issue #92464

debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo.

Before this change, closure/generator environments coming from different
instantiations of the same generic function were all assigned the same
name even though they were distinct types with potentially different data
layout. Now we append the generic arguments of the originating function
to the type name.

This commit also emits '{closure_env#0}' as the name of these types in
order to disambiguate them from the accompanying closure function
'{closure#0}'. Previously both were assigned the same name.

review + rebase

rustfmt is broken, manually reduce line length

add a rustc::query_stability lint

silence lint in clippy

implement lint for suspicious auto trait impls

update `FutureIncompatibilityReason`

Auto merge of #93534 - ehuss:rollup-9ecozo9, r=ehuss

Rollup of 9 pull requests

Successful merges:

 - #91343 (Fix suggestion to slice if scrutinee is a `Result` or `Option`)
 - #93019 (If an integer is entered with an upper-case base prefix (0Xbeef, 0O755, 0B1010), suggest to make it lowercase)
 - #93090 (`impl Display for io::ErrorKind`)
 - #93456 (Remove an unnecessary transmute from opaque::Encoder)
 - #93492 (Hide failed command unless in verbose mode)
 - #93504 (kmc-solid: Increase the default stack size)
 - #93513 (Allow any pretty printed line to have at least 60 chars)
 - #93532 (Update books)
 - #93533 (Update cargo)

Failed merges:

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

Rollup merge of #93533 - ehuss:update-cargo, r=ehuss

Update cargo

10 commits in 1c034752de0df744fcd7788fcbca158830b8bf85..25fcb135d02ea897ce894b67ae021f48107d522b
2022-01-25 22:36:53 +0000 to 2022-02-01 01:32:48 +0000
- fix(install): Keep v1 file formatting the same (rust-lang/cargo#10349)
- fix(vendor): Use tables for sample config (rust-lang/cargo#10348)
- Add bash completion for `cargo clippy` (rust-lang/cargo#10347)
- Do not ignore `--features` when `--all-features` is present (rust-lang/cargo#10337)
- test: Fix compatibilty with new toml_edit (rust-lang/cargo#10350)
- extra-link-arg-etc: support all link types (credit `@davidhewitt)` (rust-lang/cargo#10274)
- Make clippy happy (rust-lang/cargo#10340)
- Update publishing link for semver rules. (rust-lang/cargo#10338)
- Normalize --path when install bin outside current workspace (rust-lang/cargo#10335)
- Bump clap to v3.0.13 (rust-lang/cargo#10336)

Update cargo

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

Update books

## nomicon

4 commits in 66d097d3d80e8f88c288c6879c7c2b909ecf8ad4..9493715a6280a1f74be759c7e1ef9999b5d13e6f
2022-01-05 05:45:21 +0900 to 2022-01-27 19:00:32 -0800
- send-and-sync: it's -&gt; its (rust-lang/nomicon#332)
- Clarify the HRTB chapter (rust-lang/nomicon#330)
- Clarify repr(transparent) in other-reprs (rust-lang/nomicon#329)
- Make C code more recognizably C (rust-lang/nomicon#331)

## reference

10 commits in 4dee6eb63d728ffb9e7a2ed443e9ada9275c69d2..411c2f0d5cebf48453ae2d136ad0c5e611d39aec
2022-01-18 09:26:33 -0800 to 2022-01-30 12:46:37 -0800
- paths.md: update comments of `Canoical paths` section (rust-lang/reference#1146)
- Add undocumented outer attributes above StructExpr fields (rust-lang/reference#1150)
-  (rust-lang/reference#1148)
- Fix micro typo in async/unsafe function docs (rust-lang/reference#1145)
- Note difference in CTFE timing between associated and free constants (rust-lang/reference#1120)
- Update the Preludes chapter for the 2021 edition changes to the standard library prelude (rust-lang/reference#1136)
- Link to associated constants section rather than glossary (rust-lang/reference#1141)
- functions.md: replace `argument` with `parameter` (rust-lang/reference#1142)
- Improve rendering (rust-lang/reference#1143)
- (minor) link references and replace wording by syntax definition (rust-lang/reference#1139)

## book

24 commits in f17df27fc14696912c48b8b7a7a8fa49e648088d..98904efaa4fc968db8ff59cf2744d9f7ed158166
2022-01-18 17:46:28 -0500 to 2022-01-29 21:22:31 -0500
- Snapshot of chapter 17 for nostarch
- Remove the section on object safety.
- Don't put a hyphen in 'object safe'. Fixes rust-lang/book#2960.
- Clarify that add_text on Post will work in any state. Fixes rust-lang/book#2159.
- Fix incorrect descriptions of what the code is doing. Fixes rust-lang/book#2745.
- Fix link style and inclusion in print
- Snapshot of ch16 for nostarch
- Cut discussion of threading models Rust *doesn't* support.
- Update a quote of compiler output
- Move transfers between threads, not shares. Fixes rust-lang/book#2843.
- Ch20-02 Remove reference to a long-gone "trick"
- Clarify translations a bit
- Added a mention to the translations appendix
- Fix listing number from `8-5` to `9-5` in `ch09-02`
- Moving example into blockquote means it can't be extracted to a listing project
- Move a link to the end with all the other links
- Propagate edits back to ch 9
- Responding to edits in chapter 9
- Update to 1.58
- Snapshot of chapter 15 for nostarch
- Change 'only difference' to 'main difference'. Fixes rust-lang/book#1581.
- Add a back reference to tuple struct syntax. Fixes rust-lang/book#1916
- Add a link to a section reference
- Remove an outdated example that says it won't compile but it does

## rustc-dev-guide

2 commits in 78dd6a4684cf8d6b72275fab6d0429ea40b66338..8763adb62c712df69b1d39ea3e692b6d696cc4d9
2022-01-18 14:44:26 -0300 to 2022-01-26 14:01:40 -0800
- git.md: Expanded a note to try to stress what you need to do if you're playing
- Clarify that r? works in comments.

## embedded-book

1 commits in 8c395bdd8073deb20ca67e1ed4b14a3a7e315a37..d5fc1bce3f8eb398f9c25f1b15e0257d7537cd41
2021-11-14 11:38:31 +0000 to 2022-01-24 07:13:31 +0000
- Add link to Japanese translation  (rust-embedded/book#311)

Update books

Rollup merge of #93513 - dtolnay:linewidth, r=nagisa

Allow any pretty printed line to have at least 60 chars

Follow-up to #93155. The rustc AST pretty printer has a tendency to get stuck in "vertical smear mode" when formatting highly nested code, where it puts a linebreak at *every possible* linebreak opportunity once the indentation goes beyond the pretty printer's target line width:

```rust
...
                                                              ((&([("test"
                                                                       as
                                                                       &str)]
                                                                     as
                                                                     [&str; 1])
                                                                   as
                                                                   &[&str; 1]),
                                                               (&([]
                                                                     as
                                                                     [ArgumentV1; 0])
                                                                   as
                                                                   &[ArgumentV1; 0]))
...
```

```rust
...
                                                                          [(1
                                                                               as
                                                                               i32),
                                                                           (2
                                                                               as
                                                                               i32),
                                                                           (3
                                                                               as
                                                                               i32)]
                                                                             as
                                                                             [i32; 3]
...
```

This is less common after #93155 because that PR greatly reduced the total amount of indentation, but the "vertical smear mode" failure mode is still just as present when you have deeply nested modules, functions, or trait impls, such as in the case of macro-expanded code from `-Zunpretty=expanded`.

Vertical smear mode is never the best way to format highly indented code though. It does not prevent the target line width from being exceeded, and it produces output that is less readable than just a longer line.

This PR makes the pretty printing algorithm allow a minimum of 60 chars on every line independent of indentation. So as code gets more indented, the right margin eventually recedes to make room for formatting without vertical smear.

```console
├─────────────────────────────────────┤
├─────────────────────────────────────┤
├─────────────────────────────────────┤
  ├───────────────────────────────────┤
    ├─────────────────────────────────┤
      ├───────────────────────────────┤
        ├─────────────────────────────┤
          ├───────────────────────────┤
            ├───────────────────────────┤
              ├───────────────────────────┤
            ├───────────────────────────┤
          ├───────────────────────────┤
        ├─────────────────────────────┤
      ├───────────────────────────────┤
    ├─────────────────────────────────┤
  ├───────────────────────────────────┤
├─────────────────────────────────────┤
```

Rollup merge of #93504 - solid-rs:fix-kmc-solid-stack-size, r=nagisa

kmc-solid: Increase the default stack size

This PR increases the default minimum stack size on the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets to 64KiB (Arm) and 128KiB (AArch64).

This value was chosen as a middle ground between supporting a relatively complex program (e.g., an application using a full-fledged off-the-shelf web server framework) with no additional configuration and minimizing resource consumption for the embedded platform that doesn't support lazily-allocated pages nor over-commitment (i.e., wasted stack spaces are wasted physical memory). If the need arises, the users can always set the `RUST_MIN_STACK` environmental variable to override the default stack size or use the platform API directly.

Rollup merge of #93492 - Mark-Simulacrum:shorter-failure-output, r=ehuss

Hide failed command unless in verbose mode

This is particularly intended for invoking compiletest; the command line there
is long (3,350 characters on my system) and takes up a lot of screen real estate
for little benefit to the majority of those running bootstrap. This moves
printing it to verbose mode (-v must be passed) which means that it's still
possible to access when needed for debugging.

The main downside is that CI logs will by-default become less usable for
debugging (particularly) spurious failures, but it is pretty rare for us to
really need the information there -- it's usually fairly obvious what is being
run with a little investigation.

r? `@ehuss` as you've done some of the spurious failure investigations, so can
(hopefully) confirm my intuition that this won't seriously hinder them.

Rollup merge of #93456 - bjorn3:remove_unnecessary_unsafe, r=michaelwoerister

Remove an unnecessary transmute from opaque::Encoder

Rollup merge of #93090 - jyn514:errorkind-asstr, r=dtolnay

`impl Display for io::ErrorKind`

This avoids having to convert from `ErrorKind` to `Error` just to print the error message.

Rollup merge of #93019 - 5225225:uppercase-suffix, r=wesleywiser

If an integer is entered with an upper-case base prefix (0Xbeef, 0O755, 0B1010), suggest to make it lowercase

The current error for this case isn't really great, it just complains about the whole thing past the `0` being an invalid suffix.

Rollup merge of #91343 - FabianWolff:issue-91328-as-deref, r=jackh726

Fix suggestion to slice if scrutinee is a `Result` or `Option`

Fixes #91328.

Auto merge of #93259 - eddyb:diagbld-scalar-pair, r=jackh726

rustc_errors: only box the `diagnostic` field in `DiagnosticBuilder`.

I happened to need to do the first change (replacing `allow_suggestions` with equivalent functionality on `Diagnostic` itself) as part of a larger change, and noticed that there's only two fields left in `DiagnosticBuilderInner`.

So with this PR, instead of a single pointer, `DiagnosticBuilder` is two pointers, which should work just as well for passing *it* by value (and may even work better wrt some operations, though probably not by much).

But anything that was already taking advantage of `DiagnosticBuilder` being a single pointer, and wrapping it further (e.g. `Result<T, DiagnosticBuilder>` w/ non-ZST `T`), ~~will probably see a slowdown~~, so I want to do a perf run before even trying to propose this.

Fix incorrect panic message in example

Improve test coverage of {Chunks,RChunks,RChunksMut}::{next,next_back}

Auto merge of #93386 - WaffleLapkin:rustc_must_implement_one_of_check_target, r=nagisa

Check that `#[rustc_must_implement_one_of]` is applied to a trait

`#[rustc_must_implement_one_of]` only makes sense when applied to a trait, so it's sensible to emit an error otherwise.

Validate that values in switch int terminator are unique

(#93493) Add items from code review

Auto merge of #93381 - tmiasko:is-self-recursive, r=ecstatic-morse

Check the number of arguments first in `is_recursive_call`

add inline attribute to new method

Add FIXME comment

Factor convenience functions out of main printer implementation

Bless all pretty printer tests and ui tests

Allow any line to have at least 60 chars

Extract constant MARGIN out of Printer struct

Add ValuePairs::Terms & Fix compile error

And use correct substs.