Handle recursive TAIT item bounds

[amirHdev]

fixes rust-lang/trait-system-refactor-initiative#288

Avoiding normalizing the exact opaque instance currently being checked while continuing to normalize unrelated aliases and it also adds a small fast path in SolverRelating after resolving inference variables inside non-rigid aliases if both sides are identical we skip creating an unnecessary normalization goal

the next revision of the regression failed with item does not constrain Foo::{opaque#0} while the current solver accepts it

[rustbot]

r? @khyperia

rustbot has assigned @khyperia.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 19 candidates

[khyperia]

sorry, I'm not quite confident enough with t-types yet to know if this is the right approach or not

r? types

[oli-obk]

I don't know enough about the next solver's opaque type handling yet to review this properly. My gut feeling on reading the diff is that the changes are solving the problem in a very brute force way, which may be the required way, but I'd basically need to debug this from scratch to understand it.

Can you explain a bit about how you got to this solution? Just looking at logs and checking where things start going wrong?

The fast path should probably be a separate commit and ideally have some (local is fine) benchmarks showing it's necessary at all

r? @lcnr

[lcnr]

My gut feeling on reading the diff is that the changes are solving the problem in a very brute force way, which may be the required way, but I'd basically need to debug this from scratch to understand it.

Can you explain a bit about how you got to this solution? Just looking at logs and checking where things start going wrong?

yeah, I am very worried about adding special cases or different paths to the behavior of the trait solver without a clear reason for why it is necessary and correct. I don't think this issue is particularly important to fix right now as to my knowledge it does not block stabilization and does not cause breakage to stable code in the wild here.

You could look into why exactly your PR changes things. I would expect this to be a larger underlying issue related to cyclic reasoning and maybe it should actually not be a productive cycle