Auto merge of #107434 - BoxyUwU:nll_const_equate, r=compiler-errors

emit `ConstEquate` in `TypeRelating<D>`

emitting `ConstEquate` during mir typeck is useful since it can help catch bugs in hir typeck incase our impl of `ConstEquate` is wrong.

doing this did actually catch a bug, when relating `Expr::Call` we `==` the types of all the argument consts which spuriously returns false if the type contains const projections/aliases which causes us to fall through to the `expected_found` error arm.
Generally its an ICE if the `Const`'s `Ty`s arent equal but `ConstKind::Expr` is kind of special since they are sort of like const items that are `const CALL<F: const Fn(...), const N: F>` though we dont actually explicitly represent the `F` type param explicitly in `Expr::Call` so I just made us relate the `Const`'s ty field to avoid getting ICEs from the tests I added and the following existing test:
```rust
// tests/ui/const-generics/generic_const_exprs/different-fn.rs
#![feature(generic_const_exprs)]
#![allow(incomplete_features)]

use std::mem::size_of;
use std::marker::PhantomData;

struct Foo<T>(PhantomData<T>);

fn test<T>() -> [u8; size_of::<T>()] {
    [0; size_of::<Foo<T>>()]
    //~^ ERROR unconstrained generic constant
    //~| ERROR mismatched types
}

fn main() {
    test::<u32>();
}
```
which has us relate two `ConstKind::Value` one for the fn item of `size_of::<Foo<T>>` and one for the fn item of `size_of::<T>()`, these only differ by their `Ty` and if we don't relate the `Ty` we'll end up getting an ICE from the checks that ensure the `ty` fields always match.

In theory `Expr::UnOp` has the same problem so I added a call to `relate` for the ty's, although I was unable to create a repro test.

0 files changed, 0 insertions, 0 deletions