…arget is Ld64

…rrors; added register prefix

…ring

…storino

Notify when an `I-prioritize` issue is closed or reopened

Companion PR to rust-lang/triagebot#1078, blocked on that PR.
r? ``@spastorino`` cc ``@rust-lang/wg-prioritization``

…no-bundle, r=petrochenkov

Fix handling of +whole-archive native link modifier.

This PR fixes a bug in `add_upstream_native_libraries` that led to the `+whole-archive` modifier being ignored when linking in native libs.

~~Note that the PR does not address the situation when `+whole-archive` is combined with `+bundle`.~~
`@wesleywiser's` commit adds validation code that turns combining `+whole-archive` with `+bundle` into an error.

Fixes rust-lang#88085.

r? `@petrochenkov`
cc `@wesleywiser` `@gcoakes`

S390x inline asm

This adds register definitions and constraint codes for the s390x general and floating point registers necessary for fixing rust-lang#85931; as well as a few tests.

Further testing is needed, but I am a little unsure of what specific tests should be added to `src/test/assembly/asm/s390x.rs` to address this.

Make `-Z gcc-ld=lld` work for Apple targets

`-Z gcc-ld=lld` was introduced in rust-lang#85961. It does not work on Macos because lld needs be either named `ld64` or passed `-flavor darwin` as the first two arguments in order to select the Mach-O flavor. Rust invokes cc (=clang) on Macos for linking which calls `ld` as linker binary and not `ld64`, so just creating an `ld64` binary and modifying the search path with `-B` does not work.

In order to solve this patch does:
* Set the `lld_flavor` for all Apple-derived targets to `LldFlavor::Ld64`. As far as I can see this actually works towards fixing `-Xlinker=rust-lld` as all those targets use the Mach-O object format.
* Copy/hardlink rust-lld to the gcc-ld subdirectory as ld64 next to ld.
* If `-Z gcc-ld=lld` is used and the target lld flavor is Ld64 add `-fuse-ld=/path/to/ld64` to the linker invocation.

Fixes rust-lang#86945.

…atsakis

Handle match statements with non exhaustive variants in closures

This PR ensures that the behavior for match statements with non exhaustive variants is the same inside and outside closures.

If we have a non-exhaustive SingleVariant which is defined in a different crate, then we should handle the case the same way we would handle a MultiVariant: borrow the match discriminant.

Closes rust-lang/project-rfc-2229#59
r? ````@nikomatsakis````

Treat types in unnormalized function signatures as well-formed

Fixes rust-lang#87748

r? ``@nikomatsakis``

…test, r=oli-obk

Add const and static TAIT tests

r? ````@oli-obk````

Related to rust-lang#86727

…e, r=Mark-Simulacrum

add unsized coercion test

we had no tests in our test suite for this case