The deployment target environment variable is OS-specific, and if you're
in a place where you're asking `rustc` for the deployment target, you're
likely to also wanna know the environment variable.

The old name and comment suggest that this parser is only used for options
beginning with `no-`, which is mostly true but not entirely true.

Passing an explicit boolean value (`on`, `off` etc.) appears to work, but
actually puts the compiler into an unintended state where unstable _options_
are still forbidden, but unstable values of _some_ stable options are allowed.

When writing a constant name incorrectly in a pattern, the pattern will be identified as a new binding. We look for consts in the current crate, consts that where imported in the current crate and for local `let` bindings in case someone got them confused with `const`s.

```
error: unreachable pattern
  --> $DIR/const-with-typo-in-pattern-binding.rs:30:9
   |
LL |         GOOOD => {}
   |         ----- matches any value
LL |
LL |         _ => {}
   |         ^ no value can reach this
   |
help: you might have meant to pattern match against the value of similarly named constant `GOOD` instead of introducing a new catch-all binding
   |
LL |         GOOD => {}
   |         ~~~~
```

Fix rust-lang#132582.

For the code pattern reported in
<rust-lang#133272>,

```rs
impl Foo {
   fn fun() {
        let S { ref Self } = todo!();
   }
}
```

<rust-lang#121208> converted this to a
`span_bug` from a `span_delayed_bug` because this specific self-ctor
code pattern lacked test coverage. It turns out this can be hit but we
just lacked test coverage, so change it back to a `span_delayed_bug` and
add a target tested case.

This also incorporates a number of other changes and fixes which would
normally have been part of the automatic update, but which were blocked
from landing because of the changes required to support shipping a crate
as part of the chapter, along with those changes.

With the insertion of a new chapter 17 on async and await to _The Rust
Programming Language_, references in compiler output to later chapters
need to be updated to avoid confusing users. Redirects exist so that
users who click old links will end up in the right place anyway, but
this way users will be directed to the right URL in the first place.

This makes it possible to test an mdbook which has dependencies other
than the direct crate for the book itself, e.g. the `trpl` crate used in
_The Rust Programming Language_.

Since TRPL now depends on a `trpl` crate, the test needs to be able to
build that crate to run mdbook against it, and also to invoke mdbook
with `--library-path` in that case. Use the support for that flag added
to `rustbook` in the previous change to invoke it with the path to the
dependencies it will need to run `rustdoc` tests which reference `trpl`.

Co-authored-by: Onur Özkan <[email protected]>

…ption "-X32_64" for AIX.

Without this change:

    $ ./x test --set build.vendor=true src/doc/book
    # (lots of output)
    error: failed to select a version for the requirement `futures = "^0.3"` (locked to 0.3.30)
    candidate versions found which didn't match: 0.3.31, 0.3.27
    location searched: directory source `/Users/chris/dev/rust-lang/rust/vendor` (which is replacing registry `crates-io`)
    required by package `trpl v0.2.0 (/Users/chris/dev/rust-lang/rust/src/doc/book/packages/trpl)`
    perhaps a crate was updated and forgotten to be re-vendored?
    Build completed unsuccessfully in 0:01:19

With this change:

    $ ./x test --set build.vendor=true src/doc/book
    # (lots of build output)
    Testing stage1 mdbook src/doc/book (aarch64-apple-darwin)
        finished in 86.949 seconds
    Build completed successfully in 0:04:05

Is available since libc 0.2.162

distinguish overflow and unimplemented in Step::steps_between

Update TRPL to add new Chapter 17: Async and Await

- Add support to `rustbook` to pass through the `-L`/`--library-path` flag to `mdbook` so that references to the `trpl` crate
- Build the `trpl` crate as part of the book tests. Make it straightforward to add other such book dependencies in the future if needed by implementing that in a fairly general way.
- Update the submodule for the book to pull in the new chapter on async and await, as well as a number of other fixes. This will happen organically/automatically in a week, too, but this lets me group this change with the next one:
- Update the compiler messages which reference the existing chapters 17–20, which are now chapters 18-21. There are only two, both previously referencing chapter 18.
- Update the UI tests which reference the compiler message outputs.

Stop being so bail-y in candidate assembly

A conceptual follow-up to rust-lang#132084. We gotta stop bailing so much when there are errors; it's both unnecessary, leads to weird knock-on errors, and it's messing up the vibes lol

…Nadrieril

Detect const in pattern with typo

When writing a constant name incorrectly in a pattern, the pattern will be identified as a new binding. We look for consts in the current crate, consts that where imported in the current crate and for local `let` bindings in case someone got them confused with `const`s.

```
error: unreachable pattern
  --> $DIR/const-with-typo-in-pattern-binding.rs:30:9
   |
LL |         GOOOD => {}
   |         ----- matches any value
LL |
LL |         _ => {}
   |         ^ no value can reach this
   |
help: you might have meant to pattern match against the value of similarly named constant `GOOD` instead of introducing a new catch-all binding
   |
LL |         GOOD => {}
   |         ~~~~
```

Fix rust-lang#132582.

…v-var, r=davidtwco

Print name of env var in `--print=deployment-target`

The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example.

Behaviour before this PR:
```console
$ rustc --print=deployment-target --target=aarch64-apple-darwin
deployment_target=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
deployment_target=1.0
```

Behaviour after this PR:
```console
$ rustc --print=deployment-target --target=aarch64-apple-darwin
MACOSX_DEPLOYMENT_TARGET=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
XROS_DEPLOYMENT_TARGET=1.0
```

My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this:
- https://github.com/PyO3/maturin/blob/b292ef69349f2a56cb8ab1b59fda0be3d3b9f138/src/build_context.rs#L1199-L1220
- https://github.com/rust-lang/cc-rs/blob/daab9244b03e244c4f2511944870d719c443f61f/src/lib.rs#L3422-L3426

`maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](rust-lang/cc-rs#848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](rust-lang/cc-rs#901) [reverted](rust-lang/cc-rs#943) in `v1.0.85`.

So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine.

``@BlackHoleFox`` wdyt?

``@rustbot`` label O-apple
r? compiler

…dtwco,wesleywiser

aarch64 softfloat target: always pass floats in int registers

This is a part of rust-lang#131058: on softfloat aarch64 targets, the float registers may be unavailable. And yet, LLVM will happily use them to pass float types if the corresponding target features are enabled. That's a problem as it means enabling/disabling `neon` instructions can change the ABI.

Other targets have a `soft-float` target feature that forces the use of the soft-float ABI no matter whether float registers are enabled or not; aarch64 has nothing like that.

So we follow the aarch64 [softfloat ABI](rust-lang#131058 (comment)) and treat floats like integers for `extern "C"` functions. For the "Rust" ABI, we do the same for scalars, and then just do something reasonable for ScalarPair that avoids the pointer indirection.

Cc `@workingjubilee`

…, r=jieyouxu

Don't allow `-Zunstable-options` to take a value

Passing an explicit boolean value (`-Zunstable-options=on`, `off` etc.) sometimes appears to work, but actually puts the compiler into an unintended state where unstable _options_ are still forbidden, but unstable values of _some_ stable options are allowed.

This is a result of `-Zunstable-options` being checked in multiple different places, in slightly different ways. Fixing the checks in `config::nightly_options` to understand boolean values would be non-trivial, so for now it's easier to make things consistent by forbidding values in the `-Z` parser.

---

There were a few uses of this in tests, which happened to work because they were tests of unstable values.

…errors

[AIX] Add option -X32_64 to the "strip" command

The AIX `strip` utility requires option `-X` to specify the object mode. This patch adds the `-X32_64` option to the `strip` command so that it can handle both 32-bit and 64-bit objects. The parameter `option` of function `strip_symbols_with_external_utility`, previously a single string, has been changed to `options`, an array of string slices, to accommodate multiple `strip` options.

…iler-errors

Minimally constify `Add`

* This PR removes the requirement for `impl const` to have a const stability attribute. cc ``@RalfJung`` I believe you mentioned that it would make much more sense to require `const_trait`s to have const stability instead. I agree with that sentiment but I don't think that is _required_ for a small scale experimentation like this PR. rust-lang/project-const-traits#16 should definitely be prioritized in the future, but removing the impl check should be good for now as all callers need `const_trait_impl` enabled for any const impl to work.
* This PR is intentionally minimal as constifying other traits can become more complicated (`PartialEq`, for example, would run into requiring implementing it for `str` as that is used in matches, which runs into the implementation for slice equality which uses specialization)

Per the reasons above, anyone who is interested in making traits `const` in the standard library are **strongly encouraged** to reach out to us on the [Zulip channel](https://rust-lang.zulipchat.com/#narrow/channel/419616-t-compiler.2Fproject-const-traits) before proceeding with the work.

cc ``@rust-lang/project-const-traits``

I believe there is prior approval from libs that we can experiment, so

r? project-const-traits

…anieu

re-export `is_loongarch_feature_detected`

r? `@Amanieu`

…-errors

Re-delay a resolve `bug` related to `Self`-ctor in patterns

For the code pattern reported in <rust-lang#133272>,

```rs
impl Foo {
   fn fun() {
        let S { ref Self } = todo!();
   }
}
```

<rust-lang#121208> converted this to a `span_bug` from a `span_delayed_bug` because this specific self-ctor code pattern lacked test coverage. It turns out this can be hit but we just lacked test coverage, so change it back to a `span_delayed_bug` and add a targeted test case.

Follow-up to rust-lang#121208, cc ``@nnethercote`` (very good exercise to expose our test coverage gaps).
Fixes rust-lang#133272.

…g-neg, r=workingjubilee

Add code example for `wrapping_neg` method for signed integers

With this example, we make it obvious that `wrapping_neg` works both ways (neg to pos and pos to neg).

r? `@workingjubilee`

Use arc4random of libc for RTEMS target

Switch to the `arc4random` from libc. It is available since libc 0.2.162