Skip to content

Commit f297187

Browse files
committed
[CodeCompletion] Remove unresolved type from ParsedExpr during operator completion
When doing operator completion, we re-type-check the sequence expression. If we have an unresolve type already applied to `ParsedExpr`, which is the last element of the sequence, the type checker crashes in `validation-test/IDE/crashers_2_fixed/0008-must-conform-to-literal-protocol.swift`, because there are still inactive constraints in the constraint system when it finishes solving. Previously, we would ignore because we allowed free type variables, which we no longer do since the last commit.
1 parent 1719be1 commit f297187

File tree

1 file changed

+7
-0
lines changed

1 file changed

+7
-0
lines changed

lib/IDE/CodeCompletion.cpp

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6593,6 +6593,13 @@ void CodeCompletionCallbacksImpl::doneParsing() {
65936593
if (isDynamicLookup(*ExprType))
65946594
Lookup.setIsDynamicLookup();
65956595
Lookup.getValueExprCompletions(*ExprType, ReferencedDecl.getDecl());
6596+
/// We set the type of ParsedExpr explicitly above. But we don't want an
6597+
/// unresolved type in our AST when we type check again for operator
6598+
/// completions. Remove the type of the ParsedExpr and see if we can come up
6599+
/// with something more useful based on the the full sequence expression.
6600+
if (ParsedExpr->getType()->is<UnresolvedType>()) {
6601+
ParsedExpr->setType(nullptr);
6602+
}
65966603
Lookup.getOperatorCompletions(ParsedExpr, leadingSequenceExprs);
65976604
Lookup.getPostfixKeywordCompletions(*ExprType, ParsedExpr);
65986605
break;

0 commit comments

Comments
 (0)