Fold item bound before checking that they hold
This commit is contained in:
parent
7feb191f18
commit
2f4b7dc047
20 changed files with 246 additions and 115 deletions
|
@ -2026,10 +2026,19 @@ pub(super) fn check_type_bounds<'tcx>(
|
|||
// to its definition type. This should be the param-env we use to *prove* the
|
||||
// predicate too, but we don't do that because of performance issues.
|
||||
// See <https://github.com/rust-lang/rust/pull/117542#issue-1976337685>.
|
||||
let trait_projection_ty = Ty::new_projection(tcx, trait_ty.def_id, rebased_args);
|
||||
let impl_identity_ty = tcx.type_of(impl_ty.def_id).instantiate_identity();
|
||||
let normalize_param_env = param_env_with_gat_bounds(tcx, impl_ty, impl_trait_ref);
|
||||
for mut obligation in util::elaborate(tcx, obligations) {
|
||||
let normalized_predicate =
|
||||
ocx.normalize(&normalize_cause, normalize_param_env, obligation.predicate);
|
||||
let normalized_predicate = if infcx.next_trait_solver() {
|
||||
obligation.predicate.fold_with(&mut ReplaceTy {
|
||||
tcx,
|
||||
from: trait_projection_ty,
|
||||
to: impl_identity_ty,
|
||||
})
|
||||
} else {
|
||||
ocx.normalize(&normalize_cause, normalize_param_env, obligation.predicate)
|
||||
};
|
||||
debug!("compare_projection_bounds: normalized predicate = {:?}", normalized_predicate);
|
||||
obligation.predicate = normalized_predicate;
|
||||
|
||||
|
@ -2050,6 +2059,22 @@ pub(super) fn check_type_bounds<'tcx>(
|
|||
ocx.resolve_regions_and_report_errors(impl_ty_def_id, &outlives_env)
|
||||
}
|
||||
|
||||
struct ReplaceTy<'tcx> {
|
||||
tcx: TyCtxt<'tcx>,
|
||||
from: Ty<'tcx>,
|
||||
to: Ty<'tcx>,
|
||||
}
|
||||
|
||||
impl<'tcx> TypeFolder<TyCtxt<'tcx>> for ReplaceTy<'tcx> {
|
||||
fn interner(&self) -> TyCtxt<'tcx> {
|
||||
self.tcx
|
||||
}
|
||||
|
||||
fn fold_ty(&mut self, ty: Ty<'tcx>) -> Ty<'tcx> {
|
||||
if self.from == ty { self.to } else { ty.super_fold_with(self) }
|
||||
}
|
||||
}
|
||||
|
||||
/// Install projection predicates that allow GATs to project to their own
|
||||
/// definition types. This is not allowed in general in cases of default
|
||||
/// associated types in trait definitions, or when specialization is involved,
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue