We can't mix them with candidates below them, but we can mix them with
candidates above.

Fixes rust-lang#126573

Co-authored-by: Oli Scherer <[email protected]>

…compatible lifetimes

Currently the docs show e.g.

    {transmute(0xfffeffffffffffffffffffffffffffff): f128}

for f128 constants. This should fix that to instead use apfloat for
printing, as is done for `f32` and `f64`.

…r-errors

Test that opaque types can't have themselves as a hidden type with incompatible lifetimes

fixes rust-lang#122876

This PR used to add extra logic to prevent those cases, but after rust-lang#113169 this is implicitly rejected, because such usages are not defining.

…field, r=jackh726

Suggest removing unused tuple fields if they are the last fields

Fixes rust-lang#124556

We now check if dead/unused fields are the last fields of the tuple and suggest their removal instead of suggesting them to be changed to `()`.

…=jieyouxu

Migrate `bin-emit-no-symbols` `run-make` test to `rmake`

Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

try-job: x86_64-msvc
try-job: armhf-gnu

…, r=matthewjasper

match lowering: expand or-candidates mixed with candidates above

This PR tweaks match lowering of or-patterns. Consider this:
```rust
match (x, y) {
    (1, true) => 1,
    (2, false) => 2,
    (1 | 2, true | false) => 3,
    (3 | 4, true | false) => 4,
    _ => 5,
}
```
One might hope that this can be compiled to a single `SwitchInt` on `x` followed by some boolean checks. Before this PR, we compile this to 3 `SwitchInt`s on `x`, because an arm that contains more than one or-pattern was compiled on its own. This PR groups branch `3` with the two branches above, getting us down to 2 `SwitchInt`s on `x`.

We can't in general expand or-patterns freely, because this interacts poorly with another optimization we do: or-pattern simplification. When an or-pattern doesn't involve bindings, we branch the success paths of all its alternatives to the same block. The drawback is that in a case like:
```rust
match (1, true) {
    (1 | 2, false) => unreachable!(),
    (2, _) => unreachable!(),
    _ => {}
}
```
if we used a single `SwitchInt`, by the time we test `false` we don't know whether we came from the `1` case or the `2` case, so we don't know where to go if `false` doesn't match.

Hence the limitation: we can process or-pattern alternatives alongside candidates that precede it, but not candidates that follow it. (Unless the or-pattern is the only remaining match pair of its candidate, in which case we can process it alongside whatever).

This PR allows the processing of or-pattern alternatives alongside candidates that precede it. One benefit is that we now process or-patterns in a single place in `mod.rs`.

r? ``@matthewjasper``

…drop-glue, r=oli-obk

Make async drop code more consistent with regular drop code

Fixes rust-lang#126573

Relates to rust-lang#126482

r? ````@petrochenkov````

…jackh726

Make pretty printing for `f16` and `f128` consistent

Currently the docs show e.g.

    {transmute(0xfffeffffffffffffffffffffffffffff): f128}

for f128 constants. This should fix that to instead use apfloat for printing, as is done for `f32` and `f64`.

…r-errors

rustc_type_ir: Omit some struct fields from Debug output

r? compiler-errors or compiler