Needs some checking over and some tests have altered that need sanity checking, but overall this is starting to get somewhere now.

- Firstly get all the information about generics matching out of the HIR
- Secondly the labelling for the function is more coherent now
- Lastly a few error message improvements

As described in the code, this extends just beyond a 64bit reg, but
isn't a round number, so it triggers some edge cases in the cast ABI.

This would trigger a `Size::sub: 0 - 8 would result in negative size` abort,
if `data.last_offset > offset`.

This is almost hilariously easy to trigger (https://godbolt.org/z/8rbv57xET):

```rust
#[repr(C)]
pub struct DoubleFloat {
    f: f64,
    g: f32,
}

#[no_mangle]
pub extern "C" fn foo(x: DoubleFloat) {}
```

Tests for this will be covered by the cast-target-abi.rs test added in a later commit.

special case that's not present in Clang

Making the methods consistent doesn't require much justification. It's
required for us to generate correct code.

The special case was present near the end of `CastTarget::llvm_type`, and
resulted in the final integer component of the ABI type being shrunk to
the smallest integer that fits.

You can see this in action here (https://godbolt.org/z/Pe73cr91d),
where, for a struct with 5 u16 elements, rustc generates
`{ i64, i16 }`, while Clang generates `[2 x i64]`.

This special case was added a long time ago, when the function was
originally written [1]. That commit consolidated logic from many
backends, and in some of the code it deleted, sparc64 [2] and
powerpc64 [3] had similar special cases.

However, looking at Clang today, it doesn't have this special case for
sparc64 (https://godbolt.org/z/YaafvYWdf) or powerpc64
(https://godbolt.org/z/5c3YePTje), so this change just removes it.

[1]: rust-lang@f0636b6#diff-183c4dadf10704bd1f521b71f71d89bf755c9603a93f894d66c03bb1effc6021R231
[2]: rust-lang@f0636b6#diff-2d8f87ea6db6d7f0a6fbeb1d5549adc07e93331278d951a1e051a40f92914436L163-L166
[3]: rust-lang@f0636b6#diff-88af4a9df9ead503a5c7774a0455d270dea3ba60e9b0ec1ce550b4c53d3bce3bL172-L175

Previously, we did this slightly incorrectly for return values, and
didn't do it at all for arguments.

Tests added in cast-target-abi.rs, covering the single element, array,
and prefix cases in `CastTarget::llvm_type`, and the Rust-is-larger/smaller
cases in the Rust<->ABI copying code.

ffi-out-of-bounds-loads.rs was overhauled to be runnable on any
platform. Its alignment also increases due to the removal of a `min` in
the previous commit; this was probably an insufficient workaround for
this issue or similar. The higher alignment is fine, since the alloca is
actually aligned to 8 bytes, as the test checks now confirm.

This reverts commit 41c6fa8.

It is commonly used.

…errors

Better reporting on generic argument mismatchs

This allows better reporting as per issue rust-lang#116615 .

If you have a function:
```
fn foo(a: T, b: T) {}
```
and call it like so:
```
foo(1, 2.)
```
it'll give improved error reported similar to the following:
```
error[E0308]: mismatched types
 --> generic-mismatch-reporting-issue-116615.rs:6:12
  |
6 |     foo(1, 2.);
  |     --- -  ^^ expected integer, found floating-point number
  |     |   |
  |     |   expected argument `b` to be an integer because that argument needs to match the type of this parameter
  |     arguments to this function are incorrect
  |
note: function defined here
 --> generic-mismatch-reporting-issue-116615.rs:1:4
  |
1 | fn foo<T>(a: T, b: T) {}
  |    ^^^ -  ----  ----
  |        |  |     |
  |        |  |     this parameter needs to match the integer type of `a`
  |        |  `b` needs to match the type of this parameter
  |        `a` and `b` all reference this parameter T
```

Open question, do we need to worry about error message translation into other languages? Not sure what the status of that is in Rust.

NB: Needs some checking over and some tests have altered that need sanity checking, but overall this is starting to get somewhere now. Will take out of draft PR status when this has been done, raising now to allow feedback at this stage, probably 90% ready.

…rors

Fix some unsoundness with PassMode::Cast ABI

Fixes rust-lang#122617

Reviewable commit-by-commit. More info in each commit message.

Rename `expose_addr` to `expose_provenance`

`expose_addr` is a bad name, an address is just a number and cannot be exposed. The operation is actually about the provenance of the pointer.

This PR thus changes the name of the method to `expose_provenance` without changing its return type. There is sufficient precedence for returning a useful value from an operation that does something else without the name indicating such, e.g. [`Option::insert`](https://doc.rust-lang.org/nightly/std/option/enum.Option.html#method.insert) and [`MaybeUninit::write`](https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#method.write).

Returning the address is merely convenient, not a fundamental part of the operation. This is implied by the fact that integers do not have provenance since
```rust
let addr = ptr.addr();
ptr.expose_provenance();
let new = ptr::with_exposed_provenance(addr);
```
must behave exactly like
```rust
let addr = ptr.expose_provenance();
let new = ptr::with_exposed_provenance(addr);
```
as the result of `ptr.expose_provenance()` and `ptr.addr()` is the same integer. Therefore, this PR removes the `#[must_use]` annotation on the function and updates the documentation to reflect the important part.

~~An alternative name would be `expose_provenance`. I'm not at all opposed to that, but it makes a stronger implication than we might want that the provenance of the pointer returned by `ptr::with_exposed_provenance`[^1] is the same as that what was exposed, which is not yet specified as such IIUC. IMHO `expose` does not make that connection.~~

A previous version of this PR suggested `expose` as name, libs-api [decided on](rust-lang#122964 (comment)) `expose_provenance` to keep the symmetry with `with_exposed_provenance`.

CC `@RalfJung`
r? libs-api

[^1]: I'm using the new name for `from_exposed_addr` suggested by rust-lang#122935 here.

Move some tests

r? `@petrochenkov`

pattern analysis: fix union handling

Little known fact: rust supports union patterns. Exhaustiveness handles them soundly but reports nonsensical missing patterns. This PR fixes the reported patterns and documents what we're doing.

r? `@compiler-errors`

…xes-2, r=petrochenkov

More postfix match fixes

These affect diagnostics only, as far as I can tell. I'm too lazy to come up with UI tests, but I could be convinced otherwise.

Specifically, I think changing the precedence computation actually doesn't change anything, but tweaking `contains_exterior_struct_lit` does mean that some diagnostics will begin parenthesizing `S {}.match {}`.

…-errors

rustc_index: Add a `ZERO` constant to index types

It is commonly used.

Fix target name in NetBSD platform-support doc

NetBSD platform-support doc currently mentions `amd64-unknown-netbsd`, but it is not a valid target name (the correct name is `x86_64-unknown-netbsd`).

https://github.com/rust-lang/rust/blob/ceab6128fa48a616bfd3e3adf4bc80133b8ee223/src/doc/rustc/src/platform-support/netbsd.md?plain=1#L16

```console
$ rustc --print target-list | grep netbsd
aarch64-unknown-netbsd
aarch64_be-unknown-netbsd
armv6-unknown-netbsd-eabihf
armv7-unknown-netbsd-eabihf
i586-unknown-netbsd
i686-unknown-netbsd
mipsel-unknown-netbsd
powerpc-unknown-netbsd
riscv64gc-unknown-netbsd
sparc64-unknown-netbsd
x86_64-unknown-netbsd
```