[CodeCompletion] Rework getOperatorCompletions()

[rintaro]

In postfix completion, for operator completion, we do:

1. Type check the operand without applying it, but set the resolved type to the root of the expression.
2. For each possible operators:
   1. Build temporary binary/postfix expression
   2. Perform type checking to see whether the operator is applicable

This could be very slow especially if the operand is complex.

• Introduce ReusePrecheckedType option to constraint system. With this option, CSGen respects pre-stored types in expressions and doesn't take its sub-expressions into account.

  • Improve type checking performance because type variables aren't generated for sub-expressions of LHS (45511835)
  • Guarantee that the operand is not modified by the type checker because expression walkers in CSGen doesn't walk into the operand.

• Introduce TypeChecker::findLHS() to find LHS for a infix operator from pre-folded expression. We used to foldSequence() temporary SequenceExpr and find 'CodeCompletionExpr' for each attempt.

  • No need to flatten folded expression after initial type-checking.
  • Save memory of temporary BinaryExpr which used to be allocated by foldSequence().
  • Improve accuracy of the completion. foldSequence() recovers invalid combination of operators by left associative manner (with diagnostics). This used to cause false-positive results. For instance, a == b <HERE> used to suggest == operator. findLHS() returns nullptr for such invalid combination.

rdar://problem/45511835
https://bugs.swift.org/browse/SR-9061

[rintaro]

@swift-ci Please smoke test

[xedin]

LGTM! But I wonder if it's possible to avoid dummy expression, instead generate constraints only for Apply + RHS and just cache types of the left-hand side in the constraint system (because that sub-tree is already type-checked), since you are already using solve that doesn't call ExprRewriter this might be simpler solution for the problem at hand.

[rintaro]

@xedin Thanks! I updated PR. Added constraint system flag ReusePrecheckedType to reuse LHS type and not to take its subexpressions into account. What do you think?

[rintaro]

@swift-ci Please smoke test

[xedin]

Yeah, I think new approach makes sense! One more thing - I think it would be fair to assert that expressions don't have types with type variables in them, because solver isn't supposed to set types like that to AST.

[rintaro]

@xedin Thanks!

it would be fair to assert that expressions don't have types with type variables in them

Sorry to ask a dumb question but what is "them" do you mean? input LHS?

[xedin]

Ah no problem! I mean expressions should always either have a valid type (including error) or unresolved type, because CSGen never sets types on expressions directly anymore, but rather uses a separate cache associated with each constraint system to hold intermisiate types with type variables.

[rintaro]

Thanks for the explanation. I added assertion in CSGen.
@swift-ci Please smoke test