Fix an ICE when lowering a float with missing exponent magnitude

Co-authored-by: Simonas Kazlauskas <github@kazlauskas.me>

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

update Miri

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

Auto merge of #91590 - flip1995:clippyup, r=Manishearth

Update Clippy

Since RLS is now already broken #91543 , we shouldn't be blocked by it anymore. I plan to do the RLS update once new rustc-ap packages are released.

r? `@Manishearth`

update Miri

Auto merge of #91279 - scottmcm:small-refactor, r=nagisa

Small mir-opt refactor

Hopefully-non-controversial changes from some not-ready-yet work that I'd figured I'd submit on their own.

Update Cargo.lock

Merge commit 'a5d597637dcb78dc73f93561ce474f23d4177c35' into clippyup

Auto merge of #91580 - scottmcm:less-inband-1-of-28, r=petrochenkov

Stop enabling `in_band_lifetimes` in rustc_data_structures

There's a conversation started in the tracking issue about possibly unaccepting `in_band_lifetimes`, but it's used heavily in the compiler, and thus there'd need to be a bunch of PRs like this if that were to happen.

So here's one to see how much of an impact it has.  For this crate, at least, it doesn't seem like in-band was a big win -- about half the places that were using it didn't even need a named lifetime.

(Oh, and I removed `nll` while I was here too, since it didn't seem needed.  Let me know if I should put that back.)

r? `@petrochenkov`

Auto merge of #91565 - dtolnay:printhelpers, r=jackh726

Delete duplicated helpers from HIR printer

These functions (`cbox`, `nbsp`, `word_nbsp`, `head`, `bopen`, `space_if_not_bol`, `break_offset_if_not_bol`, `synth_comment`, `maybe_print_trailing_comment`, `print_remaining_comments`) are duplicated with identical behavior across the AST printer and HIR printer, but are not specific to AST or HIR data structures.

Auto merge of #8077 - nixxquality:single_char_pattern-false-negatives, r=camsteffen

Fix some false negatives for [`single_char_pattern`]

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: Fix some false negatives for [`single_char_pattern`]

I noticed that clippy wasn't complaining about my usage of `split_once("x")` in a personal project so I updated the list of functions.

I had to update the test case for an unrelated issue because replace is now included in the list of functions to be linted.

Stop enabling `in_band_lifetimes` in rustc_data_structures

There's a conversation in the tracking issue about possibly unaccepting `in_band_lifetimes`, but it's used heavily in the compiler, and thus there'd need to be a bunch of PRs like this if that were to happen.

So here's one to see how much of an impact it has.

(Oh, and I removed `nll` while I was here too, since it didn't seem needed.  Let me know if I should put that back.)

Auto merge of #91284 - t6:freebsd-riscv64, r=Amanieu

Add support for riscv64gc-unknown-freebsd

For https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-3-target-policy:

* A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

For all Rust targets on FreeBSD, it's [rust@FreeBSD.org](mailto:rust@FreeBSD.org).

* Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.

Done.

* Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.

Done

* Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

Done.

* The target must not introduce license incompatibilities.

Done.

* Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).

Fine with me.

* The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.

Done.

* If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.

Done.

* Targets should not require proprietary (non-FOSS) components to link a functional binary or library.

Done.

* "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

Fine with me.

* Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.

Ok.

* This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

Ok.

* Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

std is implemented.

* The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

Building is possible the same way as other Rust on FreeBSD targets.

* Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

Ok.

* Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

Ok.

* Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.

Ok.

* In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

Ok.

Auto merge of #91573 - matthiaskrgr:rollup-wcygm2r, r=matthiaskrgr

Rollup of 5 pull requests

Successful merges:

 - #91367 (Fix ICE in `check_must_not_suspend_ty()`)
 - #91391 (Simplify --no-headless option for rustdoc-gui tester)
 - #91537 (compiler/rustc_target: make m68k-unknown-linux-gnu use the gnu base)
 - #91554 (Update doc about code block edition attributes)
 - #91563 (Bump download-ci-llvm-stamp for LLD inclusion)

Failed merges:

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

Rollup merge of #91563 - Aaron1011:bump-llvm-stamp, r=Mark-Simulacrum

Bump download-ci-llvm-stamp for LLD inclusion

This will make 'lld' available locally now, instead of
needing to wait for the next LLVM submodule bump.

Rollup merge of #91554 - r00ster91:patch-3, r=GuillaumeGomez

Update doc about code block edition attributes

Rollup merge of #91537 - sunshowers:m68k-gnu, r=joshtriplett

compiler/rustc_target: make m68k-unknown-linux-gnu use the gnu base

This makes the m68k arch match the other GNU/Linux based targets by setting the environment to gnu.

Rollup merge of #91391 - GuillaumeGomez:simplify-no-headless, r=jsha

Simplify --no-headless option for rustdoc-gui tester

It adds a message stating the change for the concurrency and also remove the extra condition when running the tests.

r? `@camelid`

Rollup merge of #91367 - FabianWolff:issue-91334-ice, r=nagisa

Fix ICE in `check_must_not_suspend_ty()`

Fixes #91334. I have also used `TyS::tuple_fields()` (instead of the `SubstsRef` directly) to get the tuple fields, because that's what [the documentation](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Tuple) says, although it doesn't seem to make a difference in practice (this is not what fixed the ICE).

Fix dogfood

Fix ICE in `check_must_not_suspend_ty()`

Delete duplicated helpers from HIR printer

Bump download-ci-llvm-stamp for LLD inclusion

This will make 'lld' available locally now, instead of
needing to wait for the next LLVM submodule bump.

Auto merge of #91356 - GuillaumeGomez:improve-rustdoc-layout, r=jsha

Improve rustdoc layout

This is an overtake of https://github.com/rust-lang/rust/pull/89385 originally written by `@cynecx.`

I kept the original commit and simply added the missing fixes into a new one. You can test it online [here](https://rustdoc.crud.net/imperio/improve-rustdoc-layout/std/index.html).

r? `@jsha`

Auto merge of #8072 - xFrednet:0000-teach-rustbot-acronyms, r=llogiq

Enable rustbot shortcuts for rust-clippy

This enables shortcuts for ``@rustbot`.` Just a quality of life feature for contributors.

|Shortcut| Full comment |
|---|---|
| ``@rustbot` ready` | ``@rustbot` label -S-waiting-on-author +S-waiting-on-review` |
| ``@rustbot` author` | ``@rustbot` label +S-waiting-on-author -S-waiting-on-review` |

See: https://github.com/rust-lang/triagebot/wiki/Shortcuts

The documentation also states that the author/assignee will be pinged. However, this doesn't seem to be the case, it at least hasn't done so for me and in this [PR](https://github.com/rust-lang/rust/pull/90642#issuecomment-962465404)

---

changelog: none

fix some false negatives for single_char_pattern

Auto merge of #91555 - matthiaskrgr:rollup-pq0iaq7, r=matthiaskrgr

Rollup of 4 pull requests

Successful merges:

 - #90529 (Skip reborrows in AbstractConstBuilder)
 - #91437 (Pretty print empty blocks as {})
 - #91450 (Don't suggest types whose inner type is erroneous)
 - #91535 (Stabilize `-Z emit-future-incompat` as `--json future-incompat`)

Failed merges:

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

Rollup merge of #91535 - Aaron1011:stabilize-future-incompat, r=nagisa

Stabilize `-Z emit-future-incompat` as `--json future-incompat`

The FCP was completed in https://github.com/rust-lang/rust/issues/71249

Rollup merge of #91450 - hkmatsumoto:hide-type-error, r=estebank

Don't suggest types whose inner type is erroneous

Currently, we check if the returned type equals to `tcx.ty_error()` not to emit
erroneous types, but this has a pitfall; for example,
`Option<[type error]> != tcx.ty_error()` holds.

Fixes #91371.

Rollup merge of #91437 - dtolnay:emptybrace, r=nagisa

Pretty print empty blocks as {}

**Example:**

```rust
macro_rules! p {
    ($e:expr) => {
        println!("{}", stringify!($e));
    };
    ($i:item) => {
        println!("{}", stringify!($i));
    };
}

fn main() {
    p!(if true {});
    p!(struct S {});
}
```

**Before:**

```console
if true { }
struct S {
}
```

**After:**

```console
if true {}
struct S {}
```

This affects [`dbg!`](https://doc.rust-lang.org/std/macro.dbg.html), as well as ecosystem uses of stringify such as in [`anyhow::ensure!`](https://docs.rs/anyhow/1/anyhow/macro.ensure.html). Printing a `{ }` in today's heavily rustfmt'd world comes out looking jarring/sloppy.

Rollup merge of #90529 - b-naber:reborrows-consts, r=lcnr

Skip reborrows in AbstractConstBuilder

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

Temporary fix to prevent confusing diagnostics that refer to implicit borrows and derefs until we allow borrows and derefs on constant expressions.

r? `@oli-obk`

Update doc about code block edition attributes

Auto merge of #88611 - m-ou-se:array-into-iter-new-deprecate, r=joshtriplett

Deprecate array::IntoIter::new.

bless tests

skip reborrows during AbstractConst building

add test

Auto merge of #91510 - camelid:two-cleanups, r=GuillaumeGomez

rustdoc: Cleanup two things in `clean::types`

Explanations are in the individual commits.

Auto merge of #91229 - Aaron1011:dist-lld, r=Mark-Simulacrum

Include `lld` in `rust-dev` package

Fixes #88941

This will allow using `download-ci-llvm` while still having LLD
available.

Auto merge of #91475 - ecstatic-morse:mir-pass-manager3, r=oli-obk

Add a MIR pass manager (Taylor's Version)

The final draft of #91386 and #77665.

While the compile-time constraints in #91386 are cool, I decided on a more minimal approach for now. I want to explore phase constraints and maybe relative-ordering constraints in the future, though. This should preserve existing behavior **exactly** (please let me know if it doesn't) while making the following changes to the way we organize things today:

- Each `MirPhase` now corresponds to a single MIR pass. `run_passes` is not responsible for listing the correct MIR phase.
- `run_passes` no longer silently skips passes if the declared MIR phase is greater than or equal to the body's. This has bitten me multiple times. If you want this behavior, you can always branch on `body.phase` yourself.
- If your pass is solely to emit errors, you can use the `MirLint` interface instead, which gets a shared reference to `Body` instead of a mutable one. By differentiating the two, I hope to make it clearer in the short term where lints belong in the pipeline. In the long term perhaps we could enforce this at compile-time?
- MIR is no longer dumped for passes that aren't enabled, or for lints.

I tried to check that `-Zvalidate` still works correctly, since the MIR phase is now updated as soon as the associated pass is done, instead of at the end of all the passes in `run_passes`. However, it looks like `-Zvalidate` is broken with current nightlies anyways :cry: (it spits out a bunch of errors).

cc `@oli-obk` `@wesleywiser`

r? rust-lang/wg-mir-opt

Auto merge of #91539 - matthiaskrgr:rollup-rnl10yb, r=matthiaskrgr

Rollup of 6 pull requests

Successful merges:

 - #89642 (environ on macos uses directly libc which has the correct signature.)
 - #90022 (Explain why `Self` is invalid in generic parameters)
 - #90023 (Postpone the evaluation of constant expressions that depend on inference variables)
 - #91215 (Implement VecDeque::retain_mut)
 - #91355 (std: Stabilize the `thread_local_const_init` feature)
 - #91528 (LLVM support .insn directive)

Failed merges:

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

Rollup merge of #91528 - piegamesde:master, r=cuviper

LLVM support .insn directive

Closes #90558. See also https://github.com/rust-lang/llvm-project/pull/121.

Rollup merge of #91355 - alexcrichton:stabilize-thread-local-const, r=m-ou-se

std: Stabilize the `thread_local_const_init` feature

This commit is intended to follow the stabilization disposition of the
FCP that has now finished in #84223. This stabilizes the ability to flag
thread local initializers as `const` expressions which enables the macro
to generate more efficient code for accessing it, notably removing
runtime checks for initialization.

More information can also be found in #84223 as well as the tests where
the feature usage was removed in this PR.

Closes #84223

Rollup merge of #91215 - GuillaumeGomez:vec-deque-retain-mut, r=m-ou-se

Implement VecDeque::retain_mut

Part of https://github.com/rust-lang/rust/issues/90829.

In https://github.com/rust-lang/rust/pull/90772, someone suggested that `retain_mut` should also be implemented on `VecDeque`. I think that it follows the same logic (coherency). So first: is it ok? Second: should I create a new feature for it or can we put it into the same one?

r? `@joshtriplett`

Rollup merge of #90023 - b-naber:postpone_const_eval_infer_vars, r=nikomatsakis

Postpone the evaluation of constant expressions that depend on inference variables

Previously `delay_span_bug` calls were triggered once an inference variable was included in the substs of a constant that was to be evaluated. Some of these would merely have resulted in trait candidates being rejected, hence no real error was ever encountered, but the triggering of the `delay_span_bug` then caused an ICE in later stages of the compiler due to no error ever occurring.
We now postpone the evaluation of these constants, so any trait obligation fulfillment will simply stall on this constant and the existing type inference machinery of the compiler handles any type errors if present.

Fixes https://github.com/rust-lang/rust/issues/89320
Fixes https://github.com/rust-lang/rust/issues/89146
Fixes https://github.com/rust-lang/rust/issues/87964
Fixes https://github.com/rust-lang/rust/issues/87470
Fixes https://github.com/rust-lang/rust/issues/83288
Fixes https://github.com/rust-lang/rust/issues/83249
Fixes https://github.com/rust-lang/rust/issues/90654

I want to thank `@BoxyUwU` for cooperating on this and for providing some help.

r? `@lcnr` maybe?

Rollup merge of #90022 - hkmatsumoto:self-upper-as-generic-parameter, r=jackh726

Explain why `Self` is invalid in generic parameters

Close #89985.

r? `@estebank`

Rollup merge of #89642 - devnexen:macos_getenv_chng, r=m-ou-se

environ on macos uses directly libc which has the correct signature.

compiler/rustc_target: make m68k-unknown-linux-gnu use the gnu base

This makes the m68k arch match the other GNU/Linux based targets.

Include `lld` in `rust-dev` package

Fixes #88941

This will allow using `download-ci-llvm` while still having LLD
available.

Stabilize `-Z emit-future-incompat` as `--json future-incompat`

Update array::IntoIter::new deprecation version.

Update docs.

Use IntoIterator for array impl everywhere.

Swap body of array::IntoIter::new and IntoIterator::new.

Deprecate array::IntoIter::new.

Auto merge of #8074 - Qwaz:send_nonnull, r=xFrednet

Consider NonNull as a pointer type

PR 1/2 for issue #8045. Add `NonNull` as a pointer class to suppress false positives like `UnsafeCell<NonNull<()>>`. However, this change is not sufficient to handle the cases shared in gtk-rs and Rug in the issue.

changelog: none

r? `@xFrednet`

LLVM support .insn directive

Don't suggest types whose inner type is erroneous

Currently, we check if the returned type equals to `tcx.ty_error()` not to emit
erroneous types, but this has a pitfall; for example,
`Option<[type error]> != tcx.ty_error()` holds.

Auto merge of #8054 - camsteffen:map-flatten-style, r=giraffate

Upgrade map_flatten to complexity

changelog: upgrade [`map_flatten`] to complexity

Resolves #7999

Auto merge of #91517 - matthiaskrgr:rollup-3fmp4go, r=matthiaskrgr

Rollup of 3 pull requests

Successful merges:

 - #87054 (Add a `try_reduce` method to the Iterator trait)
 - #89701 (Updated error message for accidental uses of derive attribute as a crate attribute)
 - #90519 (Keep spans for generics in `#[derive(_)]` desugaring)

Failed merges:

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

Rollup merge of #90519 - estebank:issue-84003, r=petrochenkov

Keep spans for generics in `#[derive(_)]` desugaring

Keep the spans for generics coming from a `derive`d Item, so that errors
and suggestions have better detail.

Fix #84003.

Rollup merge of #89701 - tom7980:issue-89566-fix, r=petrochenkov

Updated error message for accidental uses of derive attribute as a crate attribute

This partially fixes the original issue #89566 by adding derive to the list of invalid crate attributes and then providing an updated error message however I'm not sure how to prevent the resolution error message from emitting without causing the compiler to just abort when it finds an invalid crate attribute (which I'd prefer not to do so we can find and emit other errors).

`@petrochenkov` I have been told you may have some insight on why it's emitting the resolution error though honestly I'm not sure if we need to worry about fixing it as long as we can provide the invalid crate attribute error also (which happens first anyway)

Rollup merge of #87054 - kit-981:master, r=scottmcm

Add a `try_reduce` method to the Iterator trait

Tracking issue: #87053

Auto merge of #88439 - cynecx:unwind_asm, r=Amanieu

Unwinding support for inline assembly

r? `@Amanieu`

Remove single-use `GenericParamDef::get_type` function

Rationale:

* The name was confusing.

* It was only used in one place.

* That place didn't actually need all the functionality of `get_type`;
  rather, removing `get_type` makes that code clearer.

Add a `try_reduce` method to the Iterator trait

rustdoc: Remove single-use `Lifetime::get_ref()` function

Auto merge of #91505 - matthiaskrgr:rollup-orxgsxo, r=matthiaskrgr

Rollup of 7 pull requests

Successful merges:

 - #90538 (Document how recursion is handled for `ty::Ty`)
 - #90851 (Add unchecked downcast methods)
 - #91209 (Implement ``@snapshot`` check for htmldocck)
 - #91385 (Suggest the `pat_param` specifier before `|` on 2021 edition )
 - #91478 (Remove incorrect newline from float cast suggestion)
 - #91481 (Use let_else in some more places in rustc_lint)
 - #91488 (Fix ICE when `yield`ing in function returning `impl Trait`)

Failed merges:

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

Rollup merge of #91488 - compiler-errors:issue-91477, r=estebank

Fix ICE when `yield`ing in function returning `impl Trait`

Change an assert to a `delay_span_bug` and remove an unwrap, that should fix it.

Fixes #91477

Rollup merge of #91481 - est31:let_else, r=jackh726

Use let_else in some more places in rustc_lint

Follow-up of #91018 and #89933 . Also cc #90985 which added the first let_else uses to rustc_lint.

Rollup merge of #91478 - estebank:fix-newline-in-cast-suggestion, r=camelid

Remove incorrect newline from float cast suggestion

Rollup merge of #91385 - ecstatic-morse:pat-param-spec-suggest, r=estebank

Suggest the `pat_param` specifier before `|` on 2021 edition

Ran into this today after writing some Rust for the first time in a while.

r? `@estebank`

Rollup merge of #91209 - camelid:snapshot, r=jyn514

Implement `@snapshot` check for htmldocck

This form of check allows performing snapshot tests (à la `src/test/ui`)
on rustdoc HTML output, making it easier to create and update tests.

See [this Zulip thread][1] for more information about the motivation for
this change.

[1]: https://zulip-archive.rust-lang.org/stream/266220-rustdoc/topic/HTML.20snapshot.20tests.html#262651142

r? `@GuillaumeGomez`

Rollup merge of #90851 - ibraheemdev:downcast-unchecked, r=scottmcm

Add unchecked downcast methods

```rust
impl dyn Any (+ Send + Sync) {
    pub unsafe fn downcast_ref_unchecked<T: Any>(&self) -> &T;
    pub unsafe fn downcast_mut_unchecked<T: Any>(&mut self) -> &mut T;
}

impl<A: Allocator> Box<dyn Any (+ Send + Sync), A> {
    pub unsafe fn downcast_unchecked<T: Any>(&self) -> Box<T, A>;
}
```

Rollup merge of #90538 - camelid:doc-recur-ty, r=estebank

Document how recursion is handled for `ty::Ty`

Based on this forum discussion:
https://internals.rust-lang.org/t/recursive-type-representation-in-rustc/15235/4

cc `@estebank`

Consider NonNull as a pointer type

Auto merge of #91501 - camelid:rm-tuple-impls-2, r=GuillaumeGomez

rustdoc: Remove Clean impls for tuples

This PR removes all nine Clean impls on tuples, converting them to
functions instead.

The fact that these are impls causes several problems:

  1. They are nameless, so it's unclear what they do.

  2. It's hard to find where they're used apart from removing them and
     seeing what errors occur (this applies to all Clean impls, not just
     the tuple ones).

  3. Rustc doesn't currently warn when impls are unused, so dead code
     can accumulate easily (all Clean impls).

  4. Their bodies often use tuple field indexing syntax (e.g., `self.1`)
     to refer to their "arguments", which makes reading the code more
     difficult.

As I noted, some of these problems apply to all Clean impls, but even
those problems are exacerbated by the tuple impls since they make
general understanding of the code harder.

Converting the impls to functions solves all four of these problems.

r? `@GuillaumeGomez`

limit may_unwind codegen test to x86_64

fix feature-gate test for may_unwind

fix inline asm test by not hardcoding symbol names

fix inline asm test because of missing attribute

rustc_codegen_gcc: proper check for may_unwind

add clobber_abi("C") to may_unwind inline-asm tests

add tests for asm's options(may_unwind)

add `unwind_asm` feature gate for `may_unwind` option

rustc_codegen_gcc: error on unwinding inline asm

Update unstable-book with recent asm changes (`may_unwind`)

cg_cranelift: check may_unwind flag instead of cleanup

LLVM codgen support for unwinding inline assembly

Adjust llvm wrapper for unwinding support for inlineasm

Add initial AST and MIR support for unwinding from inline assembly

Remove a Clean impl for a tuple (9)

This was the last one!

Remove a Clean impl for a tuple (8)

Remove a Clean impl for a tuple (7)

Remove a Clean impl for a tuple (6)

Remove a Clean impl for a tuple (5)

Remove a Clean impl for a tuple (4)

Clean up definition of `clean_ty_generics` a bit

Remove a Clean impl for a tuple (3)

Remove a Clean impl for a tuple (2)

Remove a Clean impl for a tuple (1)

This commit removes the first of nine Clean impls on tuples, converting
it to a function instead.

The fact that these are impls causes several problems:

  1. They are nameless, so it's unclear what they do.

  2. It's hard to find where they're used apart from removing them and
     seeing what errors occur (this applies to all Clean impls, not just
     the tuple ones).

  3. Rustc doesn't currently warn when impls are unused, so dead code
     can accumulate easily (all Clean impls).

  4. Their bodies often use tuple field indexing syntax (e.g., `self.1`)
     to refer to their "arguments", which makes reading the code more
     difficult.

As I noted, some of these problems apply to all Clean impls, but even
those problems are exacerbated by the tuple impls since they make
general understanding of the code harder.

Converting the impls to functions solves all four of these problems.

rustdoc: Rename bounds to bindings where appropriate