uniquifying region constraints

[lcnr]

Given a goal like u32: Trait<'a, 'a>, should this be canonicalized to exists<'0> u32: Trait<'0, '0> or exists<'0, '1> u32: Trait<'0, '1>? Using the first variant causes issues in MIR typeck (#27). Going with the second approach will force us to use a semantic lookup for opaque types (#17).

https://rust-lang.zulipchat.com/#narrow/stream/364551-t-types.2Ftrait-system-refactor/topic/mir.20typeck.20and.20relying.20on.20region.20equality

We ended up going back to uniquifying region constraints in rust-lang/rust#114117. This feels like the only way to avoid the ICEs in MIR typeck from #27

[lcnr]

Uniquifying region constraints is also causing hangs as we can otherwise (mostly) cache in all type folders. We've tried to readd the a type-size limit in rust-lang/rust#125507 to eagerly error in these cases instead of getting hangs and later reverted that change as it caused breakage in the wild rust-lang/rust#127670. We therefore potentially have to handle such large types in the trait solver to avoid hangs.

If we don't uniquify, we have to make sure that regions still do not impact behavior. For #27 this could be achieved by supporting OR region constraints. However, we would also be forced to stop preferring trivial candidates over others: https://github.com/rust-lang/rust/blob/08a9ca7c18a30a23a72a43b65be616c9a6a36a5a/compiler/rustc_next_trait_solver/src/solve/mod.rs#L237-L243

If we have one ambiguous candidate and one trivially true candidate which relates two regions, then this trivial true candidate can be preferred if the two regions are known to be the same, but we're unable to do so otherwise.

[lcnr]

we won't uniquify regions as doing so causes hangs, see #127