bjoernager/rust
bjoernager/rust
1
Fork 0
Code Issues Pull requests Activity

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

Browse source 
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
This commit is contained in:
Jacob Pratt 2024-02-29 05:25:28 -05:00 • committed by GitHub
commit 23351388d0
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 38 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

14
compiler/rustc_hir_analysis/src/check/compare_impl_item/refine.rs
View file

@ -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