Run rustfmt

Renamed lld_link_script to link_script and support all GNU-like linkers

Add lld_link_script to TargetOptions

Formatting

Update stdarch

Add mipsel-sony-psp target

Auto merge of #72030 - matthiaskrgr:submodule_upd, r=Mark-Simulacrum

submodules: update cargo from f534844c2 to cb06cb269

Changes:
````
more clippy fixes
Document that bench is unstable in the man page.
Update assertions in LTO calculations
Updated comments in resolve.rs to reflect actual data strcture used.
Try to remove secrets from http.debug.
Revert always computing filename Metadata.
clean -p: call `get_many` once.
Implement new `clean -p` using globs.
Rework how Cargo computes the rustc file outputs.
Add CrateType to replace LibKind.
````

I'd like to get the fix for https://github.com/rust-lang/cargo/issues/8223 into nightly asap.

r? @ehuss

Auto merge of #71994 - jyn514:path-independent, r=Mark-Simulacrum

x.py: allow configuring the build directory

This allows configuring the directory for build artifacts, instead of having it always be `./build`. This means you can set it to a constant location, letting you reuse the same cache while working in several different directories.

The configuration lives in `config.toml` under `build.build-dir`. By default, it keeps the existing default of `./build`, but it can be configured to any relative or absolute path. Additionally, it allows making outputs relative to the root of the git repository using `$ROOT`.

r? @Mark-Simulacrum

Auto merge of #72036 - Dylan-DPC:rollup-ca8b0ql, r=Dylan-DPC

Rollup of 8 pull requests

Successful merges:

 - #70834 (Add core::future::{pending,ready})
 - #71839 (Make BTreeMap::new and BTreeSet::new const)
 - #71890 (Simplify the error Registry methods a little)
 - #71942 (Shrink `LocalDecl`)
 - #71947 (Dead-code pass highlights too much of impl functions)
 - #71981 (Fix `strip-priv-imports` pass name in the rustdoc documentation)
 - #72018 (Fix canonicalization links)
 - #72031 (Better documentation for io::Read::read() return value)

Failed merges:

r? @ghost

Rollup merge of #72031 - Elinvynia:master, r=Mark-Simulacrum

Better documentation for io::Read::read() return value

Aims to provide the clarity requested in #70360

Rollup merge of #72018 - mark-i-m:canon-chalk, r=mark-i-m

Fix canonicalization links

Rollup merge of #71981 - DarkEld3r:patch-1, r=ollie27

Fix `strip-priv-imports` pass name in the rustdoc documentation

Rollup merge of #71947 - mibac138:dead-code, r=cramertj

Dead-code pass highlights too much of impl functions

Fixes #66627.
Previous diagnostic:
```
error: method is never used: `unused_impl_fn_3`
  --> src/main.rs:28:5
   |
28 | /     fn unused_impl_fn_3(
29 | |         var: i32,
30 | |     ) {
31 | |         println!("bar {}", var);
32 | |     }
   | |_____^
```
New diagnostic:
```
error: associated function is never used: `unused_impl_fn_3`
  --> $DIR/lint-dead-code-6.rs:13:8
   |
LL |     fn unused_impl_fn_3(
   |        ^^^^^^^^^^^^^^^^
```

This makes associated functions in line with free-standing functions.

Rollup merge of #71942 - nnethercote:shrink-LocalDecl, r=matthewjasper

Shrink `LocalDecl`

`LocalDecl` contributes 4-8% of peak heap memory usage on a range of benchmarks. This PR reduces its size from 128 bytes to 56 bytes on 64-bit, and does some clean-ups as well.

r? @matthewjasper

Rollup merge of #71890 - cuviper:simple-error-Registry, r=cramertj

Simplify the error Registry methods a little

Rollup merge of #71839 - LG3696:master, r=cramertj

Make BTreeMap::new and BTreeSet::new const

Rollup merge of #70834 - yoshuawuyts:future-pending-ready, r=sfackler

Add core::future::{pending,ready}

Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve, or never resolve which is an incredible useful tool when writing documentation.

These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate.

## Examples

In https://github.com/rust-lang/rust/pull/70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin`, which leads to the use of `unsafe`. Instead had we had `future::ready` available, we could've written the same example without using `unsafe`:

```rust
use core::task::{Context, Poll};
use core::future::{self, Future};
use core::pin::Pin;

pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
    let mut fut = future::ready(42_u8);
    let num = ready!(Pin::new(fut).poll(cx));
    // ... use num

    Poll::Ready(())
}
```

## Why future::ready?

Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin`, and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)).

The final, minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future`, and can be used as a useful teaching device.

## References
- [`futures::future::ready`](https://docs.rs/futures/0.3.4/futures/future/fn.ready.html)
- [`futures::future::pending`](https://docs.rs/futures/0.3.4/futures/future/fn.pending.html)
- [`async_std::future::pending`](https://docs.rs/async-std/1.5.0/async_std/future/fn.pending.html)
- [`async_std::future::ready`](https://docs.rs/async-std/1.5.0/async_std/future/fn.ready.html)

x.py: allow configuring the build directory

This allows configuring the directory for build artifacts, instead of having it always be ./build. This means you can set it to a constant location, letting you reuse the same cache while working in several different directories.

The configuration lives in config.toml under build.build-dir. By default, it keeps the existing default of ./build, but it can be configured to any relative or absolute path. Additionally, it allows making outputs relative to the root of the git repository using $ROOT.

Auto merge of #71418 - hbina:rename_miri_undef, r=RalfJung

Renamed "undef" -> "uninit"

1. InvalidUndefBytes -> InvalidUninitBytes
2. ScalarMaybeUndef -> ScalarMaybeUninit
3. UndefMask -> InitMask

Related issue #71193

Better documentation for io::Read::read() return value

submodules: update cargo from f534844c2 to cb06cb269

Changes:
````
more clippy fixes
Document that bench is unstable in the man page.
Update assertions in LTO calculations
Updated comments in resolve.rs to reflect actual data strcture used.
Try to remove secrets from http.debug.
Revert always computing filename Metadata.
clean -p: call `get_many` once.
Implement new `clean -p` using globs.
Rework how Cargo computes the rustc file outputs.
Add CrateType to replace LibKind.
````

Auto merge of #72021 - Dylan-DPC:rollup-1w61ihk, r=Dylan-DPC

Rollup of 6 pull requests

Successful merges:

 - #71581 (Unify lints handling in rustdoc)
 - #71710 (Test for zero-sized function items not ICEing)
 - #71970 (Improve bitcode generation for Apple platforms)
 - #71975 (Reduce `TypedArena` creations in `check_match`.)
 - #72003 (allow wasm target for rustc-ap-rustc_span)
 - #72017 (Work around ICEs during cross-compilation for target, ast, & attr)

Failed merges:

r? @ghost

Rollup merge of #72017 - ctaggart:wasm2, r=ecstatic-morse

Work around ICEs during cross-compilation for target, ast, & attr

This applies the fix for #72003 to work around #56935 to three more libraries. With these additional fixes, I'm able to use rustfmt_lib from wasm (https://github.com/rust-lang/rustfmt/issues/4132#issuecomment-616587989), which was my goal.

To get it working locally and to test, I copied the `.cargo/registry/src` and applied the fix and replaced the reference in my project:
``` toml
[replace]
"rustc-ap-rustc_span:656.0.0" = { path = "../rustc-ap-rustc_span" }
"rustc-ap-rustc_target:656.0.0" = { path = "../rustc-ap-rustc_target" }
"rustc-ap-rustc_ast:656.0.0" = { path = "../rustc-ap-rustc_ast" }
"rustc-ap-rustc_attr:656.0.0" = { path = "../rustc-ap-rustc_attr" }
```

Rollup merge of #72003 - ctaggart:wasm, r=jonas-schievink

allow wasm target for rustc-ap-rustc_span

This fixes #71998 by applying the work-a-round. The root cause is probably #56935, as @petrochenkov pointed out.

I reproduced the bug by:
```
cd ~/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-ap-rustc_span-657.0.0/
cargo build --target wasm32-unknown-unknown
```

Adding this line fixes it.

Rollup merge of #71975 - nnethercote:reduce-TypedArena-creations-in-check_match, r=oli-obk

Reduce `TypedArena` creations in `check_match`.

`check_match` creates a new `TypedArena` for every call to
`create_and_enter`. DHAT tells me that each `TypedArena` typically is
barely used, with typically a single allocation per arena.

This commit moves the `TypedArena` creation outwards a bit, into
`check_match`, and then passes it into `create_and_enter`. This reduces
the number of arenas created by about 4-5x, for a very small perf win.
(Moving the arena creation further outwards is hard because
`check_match` is a query.)

r? @oli-obk

Rollup merge of #71970 - thombles:ios-bitcode-improvements, r=alexcrichton

Improve bitcode generation for Apple platforms

Some improvements for iOS bitcode support suggested by Alex over at https://github.com/getditto/rust-bitcode/issues/9. r? @alexcrichton

This improves Rust's bitcode generation so that provided you have a compatible LLVM version, Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps, and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM, [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE).

1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections, even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS`, which is far from obvious.
2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS, copied directly from the a clang equivalent section.

In the context of Apple platforms, the predominant purpose of bitcode is App Store submissions, so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities, hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure.

Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.

Rollup merge of #71710 - workingjubilee:jubilee-readd-test, r=nikomatsakis

Test for zero-sized function items not ICEing

Closes #30276.
Again.
Please give rustcake with no icing!

Rollup merge of #71581 - GuillaumeGomez:unify-lints-handling, r=kinnison

Unify lints handling in rustdoc

This is a small cleanup. The goal is to unify a bit things to make the reading simpler.

r? @kinnison

cc @rust-lang/rustdoc

fix canonicalization links

Work around ICEs during cross-compilation

FIXME comment

Auto merge of #72010 - Dylan-DPC:rollup-prdj0pk, r=Dylan-DPC

Rollup of 6 pull requests

Successful merges:

 - #71989 (Use a single enum for the kind of a const context)
 - #71993 (Remove old `util/liveness.rs` module)
 - #71999 (Add myself to mailmap.)
 - #72001 (Adjust cfg(version) to lang team decision)
 - #72007 (Fix some tests failing in `--pass check` mode)
 - #72008 (Add const-generics test)

Failed merges:

r? @ghost

Rollup merge of #72008 - lcnr:patch-3, r=varkor

Add const-generics test

Taken from #71973 as this apparently already compiles.

r? @varkor

Rollup merge of #72007 - petrochenkov:passcheck3, r=RalfJung

Fix some tests failing in `--pass check` mode

r? @RalfJung

Rollup merge of #72001 - mibac138:cfg-version, r=petrochenkov

Adjust cfg(version) to lang team decision

See https://github.com/rust-lang/rust/issues/64796#issuecomment-625474439 for details

r? @petrochenkov who reviewed the original PR (#71314)

Rollup merge of #71999 - crlf0710:mailmap, r=Dylan-DPC

Add myself to mailmap.

Rollup merge of #71993 - ecstatic-morse:cleanup-old-liveness, r=jonas-schievink

Remove old `util/liveness.rs` module

The liveness dataflow analysis now lives in the `dataflow` module, so this one is no longer necessary. I've copied the relevant bits of the module docs for `util::liveness` to `MaybeLiveLocals`. The example in the docs is now a `mir-dataflow` test: https://github.com/rust-lang/rust/blob/a08c47310c7d49cbdc5d7afb38408ba519967ecd/src/test/ui/mir-dataflow/liveness-ptr.rs#L6-L26

The borrow-checker used the same notion of "defs" and "uses", so I've moved it into a submodule. I would have moved it to `util/def_use.rs`, since it seems generally useful, but there's already a slightly [different version](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/util/def_use.rs) of the same abstraction needed for copy propagation.

Rollup merge of #71989 - ecstatic-morse:const-context-enum, r=oli-obk

Use a single enum for the kind of a const context

This adds a `ConstContext` enum to the `rustc_hir` crate and method that can be called via `tcx.hir()` to get the `ConstContext` for a given body owner. This arose from discussion in #71824.

r? @oli-obk

add const-generics test

Fix some tests failing in `--pass check` mode

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

update miri

In particular this includes the change to yield on `spin_loop_hint`, which is needed for https://github.com/rust-lang/rust/pull/71737.
r? @ghost Cc @rust-lang/miri

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

#[allow(unused)]

allow wasm target for rustc-ap-rustc_span

Auto merge of #71992 - Dylan-DPC:rollup-29qjvpe, r=Dylan-DPC

Rollup of 5 pull requests

Successful merges:

 - #70733 (Add Arc::{incr,decr}_strong_count)
 - #71598 (improve Drop documentation)
 - #71783 (Detect errors caused by `async` block in 2015 edition)
 - #71903 (reword "possible candidate" import suggestion)
 - #71960 (Fix E0284 to not use incorrect wording)

Failed merges:

r? @ghost

Add myself to mailmap.

Simplify bitcode embedding - either None or Full

Adjust cfg(version) to lang team decision

Replace `MatchVisitor::check_in_cx` with `MatchVisitor::new_cx`.

The closure isn't necessary.

update miri

Auto merge of #71995 - pietroalbini:ci-windows-detect-latest-python, r=Mark-Simulacrum

[CI] Use the latest Python available on Windows

This PR changes our Windows CI to always use the latest Python interpreter available in the GHA tool cache instead of hardcoding Python 3.7.6. This is needed because occasionally GitHub bumps the installed version, deleting the previous one.

This fixes the current GHA outage we're having. I fully expect the outage to propagate to Azure Pipelines in the coming days if we don't merge this, as both GHA and Azure use the same underlying image. Once the PR is merged we can re-enabled the double-gating.

r? @Mark-Simulacrum

Remove `MatchCheckCtxt::create_and_enter`.

It has a single call site.

ci: use the latest python available on windows

This commit changes our Windows CI to always use the latest Python
interpreter available in the GHA tool cache instead of hardcoding Python
3.7.6. This is needed because occasionally GitHub bumps the installed
version, deleting the previous one.

Incorporate old module docs into `MaybeLiveLocals` docs

Remove old `util/liveness.rs` module

The liveness dataflow analysis now lives in
`librustc_mir/dataflow/impls/liveness.rs`. The borrow-checker has an
abstraction around of "defs" and "uses" that I've made module private. I
would have moved it to `util/def_use.rs`, but there's a slightly
different abstraction used for copy propagation with that name.

Rollup merge of #71960 - estebank:fix-E0284, r=davidtwco

Fix E0284 to not use incorrect wording

Fix #71584, fix #69683.

Rollup merge of #71903 - euclio:reword-possible-better, r=petrochenkov

reword "possible candidate" import suggestion

This suggestion has always read a bit awkwardly to me, particularly the "possible better candidate" variant.

This commit rewords the suggestion to be more concise and mention the kind of the suggested item. There isn't a nice way to label individual suggestions, so I opted to use "items" in the case of multiple suggestions.

Rollup merge of #71783 - estebank:async-block-2015, r=tmandry

Detect errors caused by `async` block in 2015 edition

Fix #67204.

Rollup merge of #71598 - lcnr:drop-docs, r=RalfJung,Mark-Simulacrum

improve Drop documentation

Fixes #36073

This is a continuation of #57449 and most of the work here was done by
the excellent @steveklabnik.

Rollup merge of #70733 - yoshuawuyts:arc-increment-refcount, r=Mark-Simulacrum

Add Arc::{incr,decr}_strong_count

This adds two `unsafe` methods to `Arc`: `incr_strong_count` and `decr_strong_count`. A suggestion to add methods to change the strong count in `Arc` came up in during review in https://github.com/rust-lang/rust/pull/68700#discussion_r396169064, and from asking a few people this seemed like generally useful to have.

References:
- [Motivation from #68700](https://github.com/rust-lang/rust/pull/68700#discussion_r396169064)
- [Real world example in an executor](https://docs.rs/extreme/666.666.666666/src/extreme/lib.rs.html#13)

Use `hir::ConstContext` instead of local enums

Add `hir::ConstContext`

Fix E0284 to not use incorrect wording

Fix #71584, fix #69683.

Auto merge of #71985 - Dylan-DPC:rollup-9ceqump, r=Dylan-DPC

Rollup of 6 pull requests

Successful merges:

 - #71938 (Use trait_object_dummy_self instead of err)
 - #71952 (Add some regression tests)
 - #71959 (tests: Fix warnings in `rust_test_helpers.c`)
 - #71962 (Grammar)
 - #71972 (use hex for pointers in Miri error messages)
 - #71980 (Allow a few warnings.)

Failed merges:

r? @ghost

Rollup merge of #71980 - steveklabnik:warnings-fixes, r=Mark-Simulacrum

Allow a few warnings.

On Windows, these types were causing warnings to be emitted during the
build. These types are allowed to not have idiomatic names, so the
warning should be supressed.

Rollup merge of #71972 - RalfJung:miri-validity-error-refine, r=oli-obk

use hex for pointers in Miri error messages

Also refine vtable error message: distinguish between "drop fn does not point to a function" and "drop fn points to a function with the wrong signature".

Rollup merge of #71962 - jsoref:grammar, r=Dylan-DPC

Grammar

I've split this into individual changes so that people can veto individually. I'm not attached to most of them.

`zeroes` vs. `zeros` is why I took the effort to run this through app.grammarly (which disappointingly didn't even notice).

Rollup merge of #71959 - petrochenkov:chelpers, r=Mark-Simulacrum

tests: Fix warnings in `rust_test_helpers.c`

MSVC is silly and doesn't recognize `assert` as diverging.

Rollup merge of #71952 - JohnTitor:add-tests, r=Dylan-DPC

Add some regression tests

Closes #29988
Closes #34979
Pick up two snippets that have been fixed from #67945 (shouldn't be closed yet!)

Rollup merge of #71938 - mark-i-m:de-abuse-err-4, r=eddyb

Use trait_object_dummy_self instead of err

r? @eddyb

cc #70866.

Add some skip flags

Renamed "undef" stuff to "uninit"

1. InvalidUndefBytes -> InvalidUninitBytes
2. ScalarMaybeUndef -> ScalarMaybeUninit
3. UndefMask -> InitMask

Related issue  #71193

Add Arc::{incr,decr}_strong_count

Fix `strip-priv-imports` pass name in the rustdoc documentation

Add core::future::{pending,ready}

Allow a few warnings.

On Windows, these types were causing warnings to be emitted during the
build. These types are allowed to not have idiomatic names, so the
warning should be supressed.

Auto merge of #71649 - ecstatic-morse:ci-stage0-doc, r=Mark-Simulacrum

Ensure that `./x.py doc --stage 0 src/libstd` works via CI

This was split off from #71645, which recommends that users first try building `libstd` docs with the bootstrap `rustdoc`. This should work in most cases, but will fail if we start using a very recent `rustdoc` feature outside a `#[cfg(not(bootstrap))]`.

It would be very nice to guarantee that `./x.py doc --stage 0 src/libstd` works, since it allows documentation changes to be rendered locally without needing to build the compiler. However, it may put too big a burden on `rustdoc` developers who presumably want to dogfood new features.

rewrite Drop documentation

use hex for pointers in Miri error messages; refine vtable error message

Auto merge of #71925 - ehuss:update-cargo, r=ehuss

Update cargo

7 commits in 258c89644c4587273a3ed3ee9522d2640facba43..f534844c25cacc5e004404cea835ac85e35ca3fd
2020-04-30 21:48:21 +0000 to 2020-05-06 14:39:10 +0000
- Avoid testing git-specific error messages (rust-lang/cargo#8212)
- features: allow activated_features_unverified to communicate not-present (rust-lang/cargo#8194)
- Don't force rustc to do codegen for LTO builds (rust-lang/cargo#8192)
- Hint git-fetch-with-cli on git errors (rust-lang/cargo#8166)
- ¬∃x. ¬y =&gt; ∀x. y (rust-lang/cargo#8205)
- clippy fixes (rust-lang/cargo#8189)
- Rename bitcode-in-rlib flag to embed-bitcode (rust-lang/cargo#8204)

Provide configurable LLVM cmdline section via target spec

The App Store performs certain sanity checks on bitcode, including that
an acceptable set of command line arguments was used when compiling a
given module. For Rust code to be distributed on the app store with
bitcode rustc must pretend to have the same command line arguments.

Force embed-bitcode on non-simulator iOS/tvOS targets

At this time Apple recommends Bitcode be included for iOS apps, and
requires it for tvOS. It is unlikely that a developer would want to
disable bitcode when building for these targets, yet by default it will
not be generated. This presents a papercut for developers on those
platforms.

Introduces a new TargetOption boolean key for specific triples to
indicate that bitcode should be generated, even if cargo attempts to
optimise with -Cembed-bitcode=no.

Reduce `TypedArena` creations in `check_match`.

`check_match` creates a new `TypedArena` for every call to
`create_and_enter`. DHAT tells me that each `TypedArena` typically is
barely used, with typically a single allocation per arena.

This commit moves the `TypedArena` creation outwards a bit, into
`check_match`, and then passes it into `create_and_enter`. This reduces
the number of arenas created by about 4-5x, for a very small perf win.
(Moving the arena creation further outwards is hard because
`check_match` is a query.)

reword "possible candidate" import suggestion

Auto merge of #55617 - oli-obk:stacker, r=nagisa,oli-obk

Prevent compiler stack overflow for deeply recursive code

I was unable to write a test that

1. runs in under 1s
2. overflows on my machine without this patch

The following reproduces the issue, but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`.

```rust
// compile-pass

#![recursion_limit="1000000"]

macro_rules! chain {
    (EE $e:expr) => {$e.sin()};
    (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))};
    (Z $e:expr) => {chain!(RECURSE EE $e)};
    (Y $e:expr) => {chain!(RECURSE Z $e)};
    (X $e:expr) => {chain!(RECURSE Y $e)};
    (A $e:expr) => {chain!(RECURSE X $e)};
    (B $e:expr) => {chain!(RECURSE A $e)};
    (C $e:expr) => {chain!(RECURSE B $e)};
    // causes overflow on x86_64 linux
    // less than 1 second until overflow on test machine
    // after overflow has been fixed, takes 30s to compile :/
    (D $e:expr) => {chain!(RECURSE C $e)};
    (E $e:expr) => {chain!(RECURSE D $e)};
    (F $e:expr) => {chain!(RECURSE E $e)};
    // more than 10 seconds
    (G $e:expr) => {chain!(RECURSE F $e)};
    (H $e:expr) => {chain!(RECURSE G $e)};
    (I $e:expr) => {chain!(RECURSE H $e)};
    (J $e:expr) => {chain!(RECURSE I $e)};
    (K $e:expr) => {chain!(RECURSE J $e)};
    (L $e:expr) => {chain!(RECURSE L $e)};
}

fn main() {
    let x = chain!(D 42.0_f32);
}
```

fixes #55471
fixes #41884
fixes #40161
fixes #34844
fixes #32594

cc @alexcrichton @rust-lang/compiler

I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.

grammar: dealing-with

grammar: simplify to avoid that

grammar: stray comma

grammar: noun not verb

grammar: subject-verb not subject-verb-verb

grammar: disambiguate space-character

grammar: count-agreement default ... is

grammar: which vs that

test: Fix warnings in `rust_test_helpers.c`

Auto merge of #71958 - Dylan-DPC:rollup-woxwt5d, r=Dylan-DPC

Rollup of 5 pull requests

Successful merges:

 - #70908 (Provide suggestions for type parameters missing bounds for associated types)
 - #71731 (Turn off rustc-dev-guide toolstate for now)
 - #71888 (refactor suggest_traits_to_import)
 - #71918 (Rename methods section)
 - #71950 (Miri validation error handling cleanup)

Failed merges:

r? @ghost

Rollup merge of #71950 - RalfJung:try-validation-cleanup, r=oli-obk

Miri validation error handling cleanup

Slightly expand @jumbatm's pattern macro and use it throughout validation. This ensures we never incorrectly swallow `InvalidProgram` errors or ICE when they occur.

Fixes https://github.com/rust-lang/rust/issues/71353
r? @oli-obk

Rollup merge of #71918 - GuillaumeGomez:rename-methods-section, r=Dylan-DPC

Rename methods section

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

It renames the section [methods](https://doc.rust-lang.org/nightly/std/string/struct.String.html#methods) into "Implementations". However, I didn't not update the title in the sidebar considering that it only lists methods under (even though I updated the link of the "methods" to make it point to the "implementations" section.

r? @kinnison

cc @rust-lang/rustdoc

Rollup merge of #71888 - lcnr:refactor-suggest_traits_to_import, r=estebank

refactor suggest_traits_to_import

Rollup merge of #71731 - mark-i-m:guide-toolstate-off-for-now, r=kennytm

Turn off rustc-dev-guide toolstate for now

cc @rust-lang/wg-rustc-dev-guide @rust-lang/infra @ehuss

When we first added toolstate, the intent was to use toolstate to linkcheck PRs so that we would know which PRs break links in the guide (e.g. by moving some definition). However, these days, we are mostly getting 429 errors (too many requests) from github (not sure when this changed), and every day, there seems to be a spurious failure of some other sort. This is all despite efforts to filter out spurious failures.

Getting spurious gh pings is annoying, and we're not actually getting a lot out of this linkcheck beyond what we are getting with our CI on the guide's repo, so I'm proposing to disable this until we can figure out what might be a better path forward.

Rollup merge of #70908 - estebank:suggest-add, r=nikomatsakis

Provide suggestions for type parameters missing bounds for associated types

When implementing the binary operator traits it is easy to forget to restrict the `Output` associated type. `rustc` now accounts for different cases to lead users in the right direction to add the necessary restrictions. The structured suggestions in the following output are new:

```
error: equality constraints are not yet supported in `where` clauses
  --> $DIR/missing-bounds.rs:37:33
   |
LL | impl<B: Add> Add for E<B> where <B as Add>::Output = B {
   |                                 ^^^^^^^^^^^^^^^^^^^^^^ not supported
   |
   = note: see issue #20041 <https://github.com/rust-lang/rust/issues/20041> for more information
help: if `Output` is an associated type you're trying to set, use the associated type binding syntax
   |
LL | impl<B: Add> Add for E<B> where B: Add<Output = B> {
   |                                 ^^^^^^^^^^^^^^^^^

error[E0308]: mismatched types
  --> $DIR/missing-bounds.rs:11:11
   |
7  | impl<B> Add for A<B> where B: Add {
   |      - this type parameter
...
11 |         A(self.0 + rhs.0)
   |           ^^^^^^^^^^^^^^ expected type parameter `B`, found associated type
   |
   = note: expected type parameter `B`
             found associated type `<B as std::ops::Add>::Output`
help: consider further restricting this bound
   |
7  | impl<B> Add for A<B> where B: Add + std::ops::Add<Output = B> {
   |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0369]: cannot add `B` to `B`
  --> $DIR/missing-bounds.rs:31:21
   |
31 |         Self(self.0 + rhs.0)
   |              ------ ^ ----- B
   |              |
   |              B
   |
help: consider restricting type parameter `B`
   |
27 | impl<B: std::ops::Add<Output = B>> Add for D<B> {
   |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

That output is given for the following cases:

```rust
struct A<B>(B);
impl<B> Add for A<B> where B: Add {
    type Output = Self;

    fn add(self, rhs: Self) -> Self {
        A(self.0 + rhs.0) //~ ERROR mismatched types
    }
}

struct D<B>(B);
impl<B> Add for D<B> {
    type Output = Self;

    fn add(self, rhs: Self) -> Self {
        Self(self.0 + rhs.0) //~ ERROR cannot add `B` to `B`
    }
}

struct E<B>(B);
impl<B: Add> Add for E<B> where <B as Add>::Output = B {
    type Output = Self;

    fn add(self, rhs: Self) -> Self {
        Self(self.0 + rhs.0)
    }
}
```

Add some tests for #67945