Auto merge of #127404 - compiler-errors:rpitit-entailment-false-positive, r=oli-obk

Don't try to label `ObligationCauseCode::CompareImplItem` for an RPITIT, since it has no name

The old (current) trait solver has a limitation that when a where clause in param-env must be normalized using the same where clause, then we get spurious errors in `normalize_param_env_or_error`. I don't think there's an issue tracking it, but it's the root cause for many of the "fixed-by-next-solver" labeled issues.

Specifically, these errors may occur when checking predicate entailment of the GAT that comes out of desugaring RPITITs. Since we use `ObligationCauseCode::CompareImplItem` for these predicates, we try calling `item_name` on an RPITIT which fails, since the RPITIT has no name.

We simply suppress this logic when we're reporting a predicate entailment error for an RPITIT. RPITITs should never have predicate entailment errors, *by construction*, but they may due to this bug in the old solver.

Addresses the ICE in #127331, though doesn't fix the underlying issue (which is fundamental to the old solver).

r? types
This commit is contained in:
bors 2024-07-07 03:22:12 +00:00
commit 9e27377bec
4 changed files with 228 additions and 24 deletions

View file

@ -3472,6 +3472,10 @@ impl<'a, 'tcx> TypeErrCtxt<'a, 'tcx> {
)
});
}
// Suppress `compare_type_predicate_entailment` errors for RPITITs, since they
// should be implied by the parent method.
ObligationCauseCode::CompareImplItem { trait_item_def_id, .. }
if tcx.is_impl_trait_in_trait(trait_item_def_id) => {}
ObligationCauseCode::CompareImplItem { trait_item_def_id, kind, .. } => {
let item_name = tcx.item_name(trait_item_def_id);
let msg = format!(