Completion can end up calling into pre-checking multiple times in
certain cases, make sure we don't attempt to fold a SequenceExpr
multiple times since its original AST is in a broken state
post-folding. Instead, just return the already-folded expression.
rdar://133717866
The logic here for completion wasn't actually
helping things since it would result in adding the
var overload to the system, which would result
in an ErrorType binding. We could turn the ErrorType
into a placeholder when resolving the overload,
but the simpler solution is to just allow CSGen
to turn the reference into a PlaceholderType. This
matches what we do for regular solving, and fixes
a crash with an IUO completion.
rdar://89369091
To compute the expected type of a call pattern (which is the return type of the function if that call pattern is being used), we called `getTypeForCompletion` for the entire call, in the same way that we do for the code completion token. However, this pattern does not generally work. For the code completion token it worked because the code completion expression doesn’t have an inherent type and it inherits the type solely from its context. Calls, however, have an inherent return type and that type gets assigned as the `typeForCompletion`.
Implement targeted checks for the two most common cases where an expected type exists: If the call that we suggest call patterns for is itself an argument to another function or if it is used in a place that has a contextual type in the constraint system (eg. a variable binding or a `return` statement). This means that we no longer return `Convertible` for call patterns in some more complex scenarios. But given that this information was computed based on incorrect results and that in those cases all call patterns had a `Convertible` type relation, I think that’s acceptable. Fixing this would require recording more information in the constraints system, which is out-of-scope for now.
When completing in cases like `bar(arg: foo(|, option: 1)`, we don’t know if `option` belongs to the call to `foo` or `bar`. Be defensive and also suggest the signature.
This removes the distinction between argument completions and postfix expr paren completions, which was meaningless since solver-based completion.
It then determines whether to suggest the entire function call pattern (with all argument labels) or only a single argument based on whether there are any existing arguments in the call.
For this to work properly, we need to improve parser recovery a little bit so that it parsers arguments after the code completion token properly.
This should make call pattern heuristics obsolete.
rdar://84809503
`getLoc` does not necesarrily return the start location of the location (e.g. for `a.b().c()` it returns the location of `c` because that’s the location of the call). But we used the location from `getLoc` as the start location of the synthesized `buildExpression` call. In the added test case, this means that the `buildExpression` call only contained `everlay() {}` and not the code completion token. We thus infered that we could skip it the entire `MyStack {}.pnTabGesture {}.everlay() {}` call for code completion, which isn’t correct.
rdar://120798355
The following issues no longer reproduce on `main` and had reduced reproducers. Add them to the test suite.
- SR-12977
- SR-14691
- SR-15113
- rdar://63063279
- rdar://64227741
- rdar://69813796
- rdar://85609548
