Remove `AccumulateVec` and its uses.

It's basically just a less capable version of `SmallVec`.

FWIW, the only use of `ArrayVec` is now within `HybridIdxSet`.

r? @Mark-Simulacrum

Fix warnings about the `native` target-cpu

This fixes a regression from #53031 where specifying `-C target-cpu=native` is
printing a lot of warnings from LLVM about `native` being an unknown CPU. It
turns out that `native` is indeed an unknown CPU and we have to perform a
mapping to an actual CPU name, but this mapping is only performed in one
location rather than all locations we inform LLVM about the target CPU.

This commit centralizes the mapping of `native` to LLVM's value of the native
CPU, ensuring that all locations we inform LLVM about the `target-cpu` it's
never `native`.

Closes #53322

Miri engine cleanup

* Unify the two maps in memory to store the allocation and its kind together.
* Share the handling of statics between CTFE and miri: The miri engine always
      uses "lazy" `AllocType::Static` when encountering a static.  Acessing that
      static invokes CTFE (no matter the machine).  The machine only has any
      influence when writing to a static, which CTFE outright rejects (but miri
      makes a copy-on-write).
* Add an `AllocId` to by-ref consts so miri can use them as operands without
      making copies.
* Move responsibilities around for the `eval_fn_call` machine hook: The hook
      just has to find the MIR (or entirely take care of everything); pushing the
      new stack frame is taken care of by the miri engine.
* Expose the intrinsics and lang items implemented by CTFE so miri does not
      have to reimplement them.
* Allow Machine to hook into foreign statics (used by miri to get rid of some other hacks).
* Clean up function calling.
* Switch const sanity check to work on operands, not mplaces.
* Move const_eval out of rustc_mir::interpret, to make sure that it does not access private implementation details.

In particular, we can finally make `eval_operand` take `&self`. :-)

Should be merged after https://github.com/rust-lang/rust/pull/53609, across which I will rebase.

It's basically just a less capable version of `SmallVec`.

This fixes a regression from #53031 where specifying `-C target-cpu=native` is
printing a lot of warnings from LLVM about `native` being an unknown CPU. It
turns out that `native` is indeed an unknown CPU and we have to perform a
mapping to an actual CPU name, but this mapping is only performed in one
location rather than all locations we inform LLVM about the target CPU.

This commit centralizes the mapping of `native` to LLVM's value of the native
CPU, ensuring that all locations we inform LLVM about the `target-cpu` it's
never `native`.

Closes #53322

add more Cortex-R targets

This expands on PR #53663 to complete the set of Cortex-R targets and builds
rust-std components for them.

r? @alexcrichton

each extra rust-std component (there's 4 of them) takes about 3 minutes to build
on my local machine. In terms of stability (LLVM codegen bugs) these new targets
should be as stable as the Cortex-M ones (e.g. `thumbv7m-none-eabi`).

If the extra build time is too much we can leave the rust-std components out for
now

closes #53663
cc @paoloteti

Use smaller span for adjustments on block expressions

When returning a mutable reference don't use the entire body of the function as the span for the adjustments at the end.

The error [in this case](https://github.com/rust-lang/rust/compare/master...matthewjasper:hair-spans?expand=1#diff-ecef8b1f15622fb48a803c9b61605c78) is worse, but neither error message is really what we want. I have some ideas on how to get a better error message that will have to wait for a future PR.

NLL: experiment with inverting liveness

I got inspired to see what would happen here.

Fixes #52460

r? @pnkfelix

which does not have as many feature gates enabled.

Restructure hir::map::Node and hir::map::Entry

- Moves `hir::map::Node` to `hir::Node` and removes the `Node*` prefix from its variants.
- Changes `hir::map::Entry` to a struct `hir::map::Entry`.
- Removes the `Node*` prefix from each of `AnnNode`s variants.

r? @EddyB

document the platform-specific behavior of Command::current_dir

See also https://github.com/rust-lang/rust/issues/37868.

Here's my initial wording:

> Note that if the program path is relative (e.g. `"./script.sh"`), the interaction between that path and `current_dir` varies across platforms. Windows currently ignores `current_dir` when locating the program, but Unix-like systems interpret the program path relative to `current_dir`. These implementation details aren't considered stable, and it's recommended to call `canonicalize` to get an absolute program path instead of using relative paths and `current_dir` together.

I'd like to get feedback on:

- _Should_ we consider those details stable? It might be disruptive to change them, regardless of what I can get away with claiming in docs :)
- Is `canonicalize` an appropriate recommendation? As discussed in #37868 above, there are reasons it's not called automatically in the `Command` implementation.

Warn on anon params in 2015 edition

cc #41686 https://github.com/rust-lang/rfcs/pull/2522
cc  @Centril @nikomatsakis

TODO:
- [x] Make sure the tests pass.
- [x] Make sure there is rustfix-able suggestion. Current plan is to just suggest `_ : Foo`
- [x] Add a rustfix ui test.

EDIT: It seems I already did the last two in #48309

move the Pin API into its own module for centralized documentation

This implements the change proposed by @withoutboats in #49150, as suggested by @RalfJung in the review of #53104,
along with the documentation that was originally in it, that was deemed more appropriate in module-level documentation.

r? @RalfJung

resolve suggestions should use `crate::` when enabled

I couldn't find a way to add a specific assertion for the ui test, so the expected output is living under the `crates-in-path.stderr` ui test.

- is this the right place for the test?

fixes #51212