Order-dependent LUB coercion under next solver involving TAIT & `NeverToAny`

[fmease]

Found while playing around with https://godbolt.org/z/sYY6WM8eb which was provided in rust-lang/rfcs#3444 (comment). I have no idea what's going on.

The following code compiles under -Znext-solver (I doubt it should but I've got no clue):

#![feature(type_alias_impl_trait)]

enum Enum {
    Variant,
}

fn main() {
    type Opaque = impl ?Sized;
    let _: Enum = match true {
        false => (loop {}) as Opaque,
        true => Opaque::Variant,
    };
}

However, if you swap the two match arms it'll no longer compile:

#![feature(type_alias_impl_trait)]

enum Enum {
    Variant,
}

fn main() {
    type Opaque = impl ?Sized;
    let _: Enum = match true {
        true => Opaque::Variant,
        false => (loop {}) as Opaque,
    };
}

error[E0599]: no associated item named `Variant` found for type `_` in the current scope
  --> coerce.rs:10:25
   |
10 |         true => Opaque::Variant,
   |                         ^^^^^^^ associated item not found in `_`

Note that under the old solver neither version compiles. Both yield:

error[E0599]: no associated item named `Variant` found for opaque type `Opaque` in the current scope
  --> coerce.rs:11:25
   |
11 |         true => Opaque::Variant,
   |                         ^^^^^^^ associated item not found in `Opaque`

error[E0620]: cast to unsized type: `!` as `Opaque`
  --> coerce.rs:10:18
   |
10 |         false => (loop {}) as Opaque,
   |                  ^^^^^^^^^^^^^^^^^^^
   |
help: consider using a box or reference as appropriate
  --> coerce.rs:10:18
   |
10 |         false => (loop {}) as Opaque,
   |                  ^^^^^^^^^

Meta

rustc -Vv:

rustc 1.93.0-nightly (3d461af2a 2025-11-18)
binary: rustc
commit-hash: 3d461af2a23456a2676aadb13b4253c87bdfe28d
commit-date: 2025-11-18
host: x86_64-unknown-linux-gnu
release: 1.93.0-nightly
LLVM version: 21.1.5

[fmease]

LUB coercion should be commutative & associative, right?

[theemathas]

LUB coercion should be commutative & associative, right?

For commutativity, the current behavior is "no". See #73154

For associativity, the current behavior is also "no". See #148320 (comment)

[fmease]

For commutativity, the current behavior is "no". See #73154

Right but that issue should be fixed by #147565 (assuming the crater run doesn't report huge breakages).
I didn't link that PR because it seemed to only concern fn ptr coercions? I could be mistaken since I've merely skimmed the diff.

[fmease]

#149078 (comment)

Right, fair. Even if those two properties don't hold (in practice) (at the moment), I find it odd that the first example I gave now compiles under the next solver, that doesn't feel intentional. So I'll wait what lcnr or other T-types members have to say about this. This TAIT+NeverToAny example doesn't seem remotely connected to either fn ptr ty coercions (#73154) or deref coercions (#148320 (comment)).