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:
commit
9e27377bec
4 changed files with 228 additions and 24 deletions
|
@ -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!(
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue