Rollup merge of #120378 - lcnr:normalize-ast, r=compiler-errors

always normalize `LoweredTy` in the new solver

I currently expect us to stop using alias bound candidates of normalizable aliases due to https://github.com/rust-lang/trait-system-refactor-initiative/issues/77 by landing https://github.com/rust-lang/rust/pull/119744. At this point it mostly doesn't matter whether we eagerly normalize (and replace with infer vars in case of ambiguity). cc #113473 previous attempt

The infer var replacement for ambiguous projections can in very rare cases:
- weaken inference https://github.com/rust-lang/trait-system-refactor-initiative/issues/81
- strengthen inference https://github.com/rust-lang/trait-system-refactor-initiative/issues/7

I do not expect this impact on inference to significantly affect real crates.

r? ``@compiler-errors``

1 files changed, 9 insertions, 1 deletions

diff --git a/compiler/rustc_hir_typeck/src/fn_ctxt/mod.rs b/compiler/rustc_hir_typeck/src/fn_ctxt/mod.rs
index 18f547be2a7..449de631f5a 100644
--- a/compiler/rustc_hir_typeck/src/fn_ctxt/mod.rs
+++ b/compiler/rustc_hir_typeck/src/fn_ctxt/mod.rs
@@ -369,6 +369,14 @@ pub struct LoweredTy<'tcx> {
 
 impl<'tcx> LoweredTy<'tcx> {
     pub fn from_raw(fcx: &FnCtxt<'_, 'tcx>, span: Span, raw: Ty<'tcx>) -> LoweredTy<'tcx> {
-        LoweredTy { raw, normalized: fcx.normalize(span, raw) }
+        // FIXME(-Znext-solver): We're still figuring out how to best handle
+        // normalization and this doesn't feel too great. We should look at this
+        // code again before stabilizing it.
+        let normalized = if fcx.next_trait_solver() {
+            fcx.try_structurally_resolve_type(span, raw)
+        } else {
+            fcx.normalize(span, raw)
+        };
+        LoweredTy { raw, normalized }
     }
 }