bors 068161ea48 Auto merge of #107940 - BoxyUwU:const_ty_assertion_use_semantic_equality, r=compiler-errors ... use semantic equality for const param type equality assertion Fixes #107898 See added test for what caused this ICE --- The current in assertion in `relate.rs` is rather inadequate when keeping in mind future expansions to const generics: - it will ICE when there are infer vars in a projection in a const param ty - it will spurriously return false when either ty has infer vars because of using `==` instead of `infcx.at(..).eq` - i am also unsure if it would be possible with `adt_const_params` to craft a situation where the const param type is not wf causing `normalize_erasing_regions` to `bug!` when we would have emitted a diagnostic. This impl feels pretty Not Great to me although i am not sure what a better idea would be. - We have to have the logic behind a query because neither `relate.rs` or `combine.rs` have access to trait solving machinery (without evaluating nested obligations this assert will become _far_ less useful under lazy norm, which consts are already doing) - `relate.rs` does not have access to canonicalization machinery which is necessary in order to have types potentially containing infer vars in query arguments. We could possible add a method to `TypeRelation` to do this assertion rather than a query but to avoid implementing the same logic over and over we'd probably end up with the logic in a free function somewhere in `rustc_trait_selection` _anyway_ so I don't think that would be much better. We could also just remove this assertion, it should not actually be necessary for it to be present. It has caught some bugs in the past though so if possible I would like to keep it. r? `@compiler-errors`		2023-02-15 05:17:58 +00:00
..
src	Auto merge of #107940 - BoxyUwU:const_ty_assertion_use_semantic_equality, r=compiler-errors	2023-02-15 05:17:58 +00:00
Cargo.toml	Multiple candidates with same response is not ambiguous	2023-02-10 00:35:25 +00:00