@@ -6694,6 +6694,10 @@ bool ConstraintSystem::repairFailures(
66946694 }
66956695
66966696 case ConstraintLocator::Condition: {
6697+ // If the condition is already a hole, we're done.
6698+ if (lhs->isPlaceholder())
6699+ return true;
6700+
66976701 if (repairViaOptionalUnwrap(*this, lhs, rhs, matchKind, conversionsOrFixes,
66986702 locator))
66996703 return true;
@@ -11604,22 +11608,11 @@ ConstraintSystem::SolutionKind ConstraintSystem::simplifyMemberConstraint(
1160411608 // `key path` constraint can't be retired until all components
1160511609 // are simplified.
1160611610 addTypeVariableConstraintsToWorkList(memberTypeVar);
11607- } else if (isa<Expr *>(locator->getAnchor()) &&
11608- !getSemanticsProvidingParentExpr(
11609- getAsExpr(locator->getAnchor()))) {
11610- // If there are no contextual expressions that could provide
11611- // a type for the member type variable, let's default it to
11612- // a placeholder eagerly so it could be propagated to the
11613- // pattern if necessary.
11614- recordTypeVariablesAsHoles(memberTypeVar);
11615- } else if (locator->isLastElement<LocatorPathElt::PatternMatch>()) {
11616- // Let's handle member patterns specifically because they use
11617- // equality instead of argument application constraint, so allowing
11618- // them to bind member could mean missing valid hole positions in
11619- // the pattern.
11620- recordTypeVariablesAsHoles(memberTypeVar);
1162111611 } else {
11622- recordPotentialHole(memberTypeVar);
11612+ // Eagerly turn the member type variable into a hole since we know
11613+ // this is where the issue is and we've recorded a fix for it. This
11614+ // avoids producing unnecessary holes for e.g generic parameters.
11615+ recordTypeVariablesAsHoles(memberTypeVar);
1162311616 }
1162411617 }
1162511618
0 commit comments