- Mangles (T0, T1) as tuple<T0, T1>, possibly unblocking rust-lang#70052 "Update hashbrown to 0.8.0"
- Prettifies Rust tuples similar to VS2017's std::tuple
- Improves debuginfo test coverage

PDB debug information doesn't appear to be emitted for basic types.
By defining u32 as a typedef for unsigned __int32 when targeting MSVC,
we allow CDB and other debuggers to recognize "u32" as a type/expression.

This in turn unblocks rust-lang#70052 "Update hashbrown to 0.8.0" by
allowing $T1 ..= $T3 to resolve, which would otherwise fail to resolve
when builtin types fail to parse.

…rks into own file

…_` benches, and clean up stray semicolon

When cross-compiling, the LLVM build system recurses to build tools
that need to run on the host system. However, since we pass cmake defines
to set the compiler and target, LLVM still compiles these tools for the
target system, rather than the host. The tools then fail to execute
during the LLVM build.

This change sets defines for the tools that need to run on the
host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build
does not attempt to build them, and instead relies on the tools already built.

If compiling with clang-cl, this change also adds the `--target` option
to specify the target triple. MSVC compilers do not require this, since there
is a separate compiler binary for cross-compilation.

As of rust-lang#73564, the --eh-frame-hdr flag is unconditionally
passed to linkers on many platforms.  The illumos link editor does not
currently support this flag.

The linker machinery in the Rust toolchain currently seems to use the
(potentially cross-compiled) target to choose linker flags, rather than
looking at what might be running on the build system.  Disabling the
flag for all illumos/Solaris targets seems like the best we can do for
now without more serious surgery.

Use `matches!` instead of old `if let`

This to fix rust-lang#74081.

Stabilize `transmute` in constants and statics but not const fn

cc rust-lang#53605 (leaving issue open so we can add `transmute` to `const fn` later)

Previous attempt: rust-lang#64011

r? @RalfJung

cc @rust-lang/wg-const-eval

…manieu

debuginfo:  Mangle tuples to be natvis friendly, typedef basic types

These changes are meant to unblock rust-lang#70052 "Update hashbrown to 0.8.0" by allowing the use of `tuple<u64, u64>` as a .natvis expression in MSVC style debuggers (MSVC, WinDbg, CDB, etc.)

* f8eb81b does the actual mangling of `(u64, u64)` -> `tuple<u64, 64>`
* 24a728a allows `u64` to resolve (fixing `$T1` / `$T2` when used to visualize `HashMap<u64, u64, ...>`)

Optimize is_ascii for str and [u8].

This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while, so I just did it.

Benchmarks comparing before/after look like:

```
test ascii::long_readonly::is_ascii_slice_iter_all              ... bench:         174 ns/iter (+/- 79) = 40172 MB/s
test ascii::long_readonly::is_ascii_slice_libcore               ... bench:          16 ns/iter (+/- 5) = 436875 MB/s
test ascii::medium_readonly::is_ascii_slice_iter_all            ... bench:          12 ns/iter (+/- 3) = 2666 MB/s
test ascii::medium_readonly::is_ascii_slice_libcore             ... bench:           2 ns/iter (+/- 0) = 16000 MB/s
test ascii::short_readonly::is_ascii_slice_iter_all             ... bench:           3 ns/iter (+/- 0) = 2333 MB/s
test ascii::short_readonly::is_ascii_slice_libcore              ... bench:           4 ns/iter (+/- 0) = 1750 MB/s
```

(Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores)

Where `is_ascii_slice_iter_all` is the old version, and `is_ascii_slice_libcore` is the new.

I tried to document the code well, so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now, I tried to `debug_assert` all the safety invariants I'm depending on. (Of course, none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such).

Anyway, thanks. Let me know if you have questions/desired changes.

Fix cross compilation of LLVM to aarch64 Windows targets

When cross-compiling, the LLVM build system recurses to build tools that need to run on the host system. However, since we pass cmake defines to set the compiler and target, LLVM still compiles these tools for the target system, rather than the host. The tools then fail to execute during the LLVM build.

This change sets defines for the tools that need to run on the host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build does not attempt to build them, and instead relies on the tools already built.

If compiling with clang-cl, adds the `--target` option to specify the target triple. MSVC compilers do not require this, since there is a separate compiler binary for each cross-compilation target.

Related issue: rust-lang#72881
Requires LLVM change: rust-lang/llvm-project#67

…-fix, r=petrochenkov

linker: illumos ld does not support --eh-frame-hdr

As of rust-lang#73564, the --eh-frame-hdr flag is unconditionally
passed to linkers on many platforms.  The illumos link editor does not
currently support this flag.

The linker machinery in the Rust toolchain currently seems to use the
(potentially cross-compiled) target to choose linker flags, rather than
looking at what might be running on the build system.  Disabling the
flag for all illumos/Solaris targets seems like the best we can do for
now without more serious surgery.

…s, r=petrochenkov

Add a help to use `in_band_lifetimes` in nightly

Fixes rust-lang#73775

Reword incorrect `self` token suggestion

Minor refactor for rustc_resolve diagnostics match

Use `matches!` instead of old `if let`

Fix rust-lang#74081 and add the test case from rust-lang#74236

update miri

This incorporates rust-lang/miri#1474. [Last time](rust-lang#74146) that change caused trouble but I fixed xargo since then and [now it should work](rust-lang#74146 (comment)).

Cc @rust-lang/miri r? @ghost