- 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.

This patch avoids undefined behavior by linking different object files.
Also this would it could be propagated properly to LTO.

See https://reviews.llvm.org/D52322 and https://reviews.llvm.org/D52323.

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, ...>`)

Add support for storing code model to LLVM module IR

This patch avoids undefined behavior by linking different object files.
Also this would it could be propagated properly to LTO.

See https://reviews.llvm.org/D52322 and https://reviews.llvm.org/D52323.

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