Fall back when relating two opaques by substs in MIR typeck

[compiler-errors]

This is certainly one way to fix #100075. Not really confident it's the best way to do it, though.

The root cause of this issue is that during MIR type-check, we end up trying to equate an opaque against the same opaque def-id but with different substs. Because of the way that we replace RPITs during (HIR) typeck with an inference variable, we don't end up emitting a type-checking error, so the delayed MIR bug causes an ICE.

See the src/test/ui/impl-trait/issue-100075-2.rs test below to make that clear -- in that example, we try to equate {impl Sized} substs=[T] and {impl Sized} substs=[Option<T>], which causes an ICE. This new logic will instead cause us to infer {impl Sized} substs=[Option<T>] as the hidden type for {impl Sized} substs=[T], which causes a proper error to be emitted later on when we check that an opaque isn't recursive.

I'm open to closing this in favor of something else. Ideally we'd fix this in typeck, but the thing we do to ensure backwards compatibility with weird RPIT cases makes that difficult. Also open to discussing this further.

[rust-highfive]

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

[compiler-errors]

r? @oli-obk

[oli-obk]

We already have some logic somewhere to detect infinitely recursive opaque types.

Why is this case not handled by opaque_type_cycle_error

[compiler-errors]

@oli-obk: So currently (before this PR), when we equate an opaque w/ substs1 and the same opaque w/ substs2, where substs1 and substs2 can't be equated, results in an error in mir typeck. So we actually don't infer anything for the opaque, so we don't actually see the opaque being cyclical (at least not in the opaque hidden type that mir_borrowck results gives us).

[oli-obk]

Considering opaque_type_cycle_error operates completely on TypeckResults, we could just remove it from wf checking and make it work completely inside the typeck query. That way it would run before mir borrowck's typeck ICEs (which usually doesn't get wfcheck run before)

[compiler-errors]

@oli-obk:
I'm not sure I understand how to do this without having query cycles in the case of mutually recursive opaque types from different items.
Also I don't know how this would work with mutually recursive TAITs either, since we don't necessarily have all the information in a single typeck query to answer whether the TAIT is recursive in case all of the defining usages aren't in one body.

[oli-obk]

I'm not sure I understand how to do this without having query cycles in the case of mutually recursive opaque types from different items.

oof. yea good point.

[oli-obk]

@bors r+

weird unfortunate edge case, but I like the solution. We should investigate whether we should remove all of the (&ty::Opaque(a_def_id, _), &ty::Opaque(b_def_id, _)) if a_def_id == b_def_id match arms and handle this inside register_opaque_type instead.

[bors]

📌 Commit 534426d has been approved by oli-obk

It is now in the queue for this repository.

[oli-obk]

@bors r+

[bors]

📌 Commit 534426d has been approved by oli-obk

It is now in the queue for this repository.