rust/compiler/rustc_next_trait_solver/src
Matthias Krüger 9108907a18
Rollup merge of #142806 - compiler-errors:norm-ct-has-ty, r=lcnr,BoxyUwU
Normalize before computing ConstArgHasType goal in new solver

This is a fix for rust-lang/rust#139905. See the description I left in the test.

I chose to fix this by normalizing the type before matching on its `.kind()` in `compute_const_arg_has_type_goal` (since it feels somewhat consistent with how we normalize types before assembling their candidates, for example); however, there are several other solutions that come to mind for fixing this ICE:
1. (this solution)
2. Giving `ConstKind::Error` a proper type, like `ConstKind::Value`, so that consts don't go from failing to passing `ConstArgHasType` goals after normalization (i.e. `UNEVALUATED` would normalize into a `ConstKind::Error(_, bool)` type rather than losing its type altogether).
3. Just suppressing the errors and accepting the fact that goals can go from fail->pass after normalization.

Thoughts? Happy to discuss this fix further.

r? `@BoxyUwU`
2025-06-27 22:13:03 +02:00
..
solve Rollup merge of #142806 - compiler-errors:norm-ct-has-ty, r=lcnr,BoxyUwU 2025-06-27 22:13:03 +02:00
canonicalizer.rs Make connection between Placeholder and Bound a bit more clear in the type abstraction 2025-06-13 17:54:45 +00:00
coherence.rs Do not rely on type_var_origin in OrphanCheckErr::NonLocalInputType 2025-03-20 02:17:14 +00:00
delegate.rs Tweak fast path trait handling 2025-05-29 11:14:36 +00:00
lib.rs Implement lint against direct uses of rustc_type_ir in compiler crates 2025-06-18 16:01:41 +02:00
placeholder.rs Uplift BoundVarReplacer 2025-06-13 17:54:45 +00:00
resolve.rs add additional TypeFlags fast paths 2025-05-26 19:57:48 +00:00