While the semantic intent of a OnceCell/OnceLock is that it can only be written
to once (upon init), the fact of the matter is that both these types offer a
`take(&mut self) -> Option<T>` mechanism that, when successful, resets the cell
to its initial state, thereby technically allowing it to be written to again.

Despite the fact that this can only happen with a mutable reference (generally
only used during the construction of the OnceCell/OnceLock), it would be
incorrect to say that the type itself as a whole categorically prevents being
initialized or written to more than once (since it is possible to imagine an
identical type only without the `take()` method that actually fulfills that
contract).

To clarify, change "that cannot be.." to "that nominally cannot.." and add a
note to OnceCell about what can be done with an `&mut Self` reference.

…g you see on the page.

…ny, "Arm".

… are unused, just the number of entries is checked.

The indices will be used in a follow-up commit

…, r=ehuss

Add tracking issue and unstable book page for `"vectorcall"` ABI

Originally added in 2015 by rust-lang#30567, the Windows `"vectorcall"` ABI didn't have a tracking issue until now.

Tracking issue: rust-lang#124485

Change pedantically incorrect OnceCell/OnceLock wording

While the semantic intent of a OnceCell/OnceLock is that it can only be written to once (upon init), the fact of the matter is that both these types offer a `take(&mut self) -> Option<T>` mechanism that, when successful, resets the cell to its initial state, thereby [technically allowing it to be written to again](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=415c023a6ae1ef35f371a2d3bb1aa735)

Despite the fact that this can only happen with a mutable reference (generally only used during the construction of the OnceCell/OnceLock), it would be incorrect to say that the type itself as a whole *categorically* prevents being initialized or written to more than once (since it is possible to imagine an identical type only without the `take()` method that actually fulfills that contract).

To clarify, change "that cannot be.." to "that nominally cannot.." and add a note to OnceCell about what can be done with an `&mut Self` reference.

```@rustbot``` label +A-rustdocs

…, r=BoxyUwU

Avoid follow-up errors if the number of generic parameters already doesn't match

fixes rust-lang#125604

best reviewed commit-by-commit

…huss

ARM Target Docs Update

Updates the ARM target docs, drawing more attention to the `arm-none-eabi` target group by placing all targets *within* that group as a sub-list in the Table of Contents.

Also updates the `armv4t-none-eabi` page (maintainer signoff: I'm that target's maintainer) to clarify that the page covers the arm version and the thumb version of the target, but that the target group page has the full info because there's nothing really specific to say for those targets.

Align `Term` methods with `GenericArg` methods, add `Term::expect_*`

* `Term::ty` -> `Term::as_type`.
* `Term::ct` -> `Term::as_const`.
* Adds `Term::expect_type` and `Term::expect_const`, and uses them in favor of `.ty().unwrap()`, etc.

I could also shorten these to `as_ty` and then do `GenericArg::as_ty` as well, but I do think the `as_` is important to signal that this is a conversion method, and not a getter, like `Const::ty` is.

r? types

…=petrochenkov

Handle no values cfgs with `--print=check-cfg`

This PR fix a bug with `--print=check-cfg`, where no values cfgs where not printed since we only printed cfgs that had at least one values.

The representation I choose is `CFG=`, since it doesn't correspond to any valid config, it also IMO nicely complements the `values()` (to indicate no values). Representing the absence of value by the absence of the value.

So for `cfg(feature, values())` we would print `feature=`.

I also added the missing tracking issue number in the doc.

r? ```@petrochenkov```

…ket-impls, r=GuillaumeGomez

rustdoc: add a regression test for a former blanket impl synthesis ICE

Fixes rust-lang#119792 (also passes in rust-lang#125907 in case you were wondering).

r? rustdoc

Remove stray "this"