Rollup merge of #121745 - compiler-errors:refining-impl-trait-deeply-norm, r=lcnr

Deeply normalize obligations in `refining_impl_trait`

We somewhat awkwardly use semantic comparison when checking the `refining_impl_trait` lint. This relies on us being able to normalize bounds eagerly to avoid cases where an unnormalized alias is not considered equal to a normalized alias. Since `normalize` in the new solver is a noop, let's use `deeply_normalize` instead.

r? lcnr

cc ``@tmandry,`` this should fix your bug lol

1 files changed, 9 insertions, 5 deletions

diff --git a/compiler/rustc_hir_analysis/src/check/compare_impl_item/refine.rs b/compiler/rustc_hir_analysis/src/check/compare_impl_item/refine.rs
index b5e69b8e376..29dc434ab45 100644
--- a/compiler/rustc_hir_analysis/src/check/compare_impl_item/refine.rs
+++ b/compiler/rustc_hir_analysis/src/check/compare_impl_item/refine.rs
@@ -136,11 +136,15 @@ pub(super) fn check_refining_return_position_impl_trait_in_trait<'tcx>(
     // 1. Project the RPITIT projections from the trait to the opaques on the impl,
     //    which means that they don't need to be mapped manually.
     //
-    // 2. Project any other projections that show up in the bound. That makes sure that
-    //    we don't consider `tests/ui/async-await/in-trait/async-associated-types.rs`
-    //    to be refining.
-    let (trait_bounds, impl_bounds) =
-        ocx.normalize(&ObligationCause::dummy(), param_env, (trait_bounds, impl_bounds));
+    // 2. Deeply normalize any other projections that show up in the bound. That makes sure
+    //    that we don't consider `tests/ui/async-await/in-trait/async-associated-types.rs`
+    //    or `tests/ui/impl-trait/in-trait/refine-normalize.rs` to be refining.
+    let Ok((trait_bounds, impl_bounds)) =
+        ocx.deeply_normalize(&ObligationCause::dummy(), param_env, (trait_bounds, impl_bounds))
+    else {
+        tcx.dcx().delayed_bug("encountered errors when checking RPITIT refinement (selection)");
+        return;
+    };
 
     // Since we've normalized things, we need to resolve regions, since we'll
     // possibly have introduced region vars during projection. We don't expect