This hooks up call argument position completion to the typeCheckForCodeCompletion API to generate completions from all the solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any).
Co-authored-by: Nathan Hawes <nathan.john.hawes@gmail.com>
In 2eeff365b1 I forgot to copy key path component types when applying a solution to the constraint system. That caused a crash in key path code completion.
Fixes rdar://81118700 [SR-14979]
We weren’t setting the code completion token status correctly when parsing patterns with code completion tokens.
Because of this, in the added test case, the `searchSubject` gets added as a member of `Foo` twice - once in the first pass and once in the second pass, causing an assertion failure.
Fixes rdar://80575116 [SR-14687]
Upon encountering an ErrorExpr, we were previously
bailing from the walk. However, for multi-statement
closures, that could result in us missing some
variable references required to connect to the
closure to its enclosing context. Make sure to
continue walking to catch those cases.
SR-14709
rdar://78781677
In code completion we might call `preCheckExpression` twice - once for the first pass and once for the second pass. This is fine since `preCheckExpression` idempotent, so don't assert if we are in code completion mode.
Fixes rdar://79136653 [SR-14755]
To describe fine grained priorities.
Introduce 'CodeCompletionFlair' that is a set of more descriptive flags for
prioritizing completion items. This aims to replace '
SemanticContextKind::ExpressionSpecific' which was a "catch all"
prioritization flag.
Remove the `TypeCheckExprFlags::AllowUnresolvedTypeVariables` flag, fixing another occurance of rdar://76686564 (https://github.com/apple/swift/pull/37309)
This does not break anything in the test suite, so I think the removal of the flag is fine.
Resolves rdar://76686564 and rdar://77659417
According to Pavel, we want to eliminate allowing unresolved variables as much as possible. Removing this flag doesn’t break any test cases (at least not in a meaningful way) and fixes a crasher, so it seems reasonable to remove it.
Fixes rdar://76686564
Because we are completing inside a result builder, we are never calling into `typeCheckExpression` and thus never call into `typeCheckForCodeCompletion` before `fallbackTypeCheck` (SR-14601).
This works fine in most cases, but in the added test case, we are hitting an assertion because the specifiers are not correctly erased from the `ClosureExpr` before re-typechecking for completion. Erasing them before fixes the test case until the underlying issue described above is fixed.
Fixes rdar://76710904 [SR-14494]
When completing within an InOutExpr like `&foo.<complete>`, we were forming a
CodeCompletionExpr with a base when parsing the content of the InOutExpr and
storing it in CodeCompletionCallbacksImpl::CodeCompleteTokenExpr. When the
result of that parse contained a code completion though, we were dropping the
sub-expression completely and forming an empty code completion result in place
of the inout expression, which resulted in later code inserting a code
completion expression with no base into the AST. The solver based completion
was later asking for the type of the code completion and its base using the
expression stored in CodeCompletionCallbacksImpl::CodeCompleteTokenExpr, but
that never ended up in the AST so we hit an assertion about the expression not
have a type in the formed solutions.
Resolves rdar://75366814
If completing the initialization of a variable that’s wrapped in a generic, unbound property wrapper, the expression's type is an `UnboundGenericType`. AFAICT that’s expected and the correct type to assign.
We hit the first assertion failure by trying to retrieve that type's substitution map. `UnboundGenericType`s were not handled here, so we crashed. AFAICT we can't get any substitutions out of an unbound generic type, so we should just continue looking into the parent type.
We hit the second assertion when trying to retrieve the property wrapper’s backing type, which is null (becuase it couldn't be resolved). However, we haven’t emitted a diagnostic because the variable declaration is perfectly valid. Hence I’m removing the assertion.
Fixes rdar://64141399
Checking for staticness is not enough because top-level decls count as
non-static yet do not have a sufficient curry level to satisfy this
check. Make sure we're looking for decls that reside inside of types.
rdar://75299825, SR-14327
receive {
switch <HERE>
}
In the current Parser implementation, if there's a error in 'switch'
subject, the 'SwitchStmt' is not placed in the parsed AST.
When the type checker searches AST node at the location, it used to find
'receive { ... }' because that is the *innermost* node in the AST that
contains the loc. But the decl context is the closure. This behavior used
to cause crashes because 'receive { ... }' is re-typechecked.
For solution, when finding the innermost AST node, clear the found node
in parent context before walking into brace statement.
rdar://problem/69246891
Avoid re-typechecking for nested closures. For example:
Something {
Other {
#^COMPLETE^#
}
}
If 'Something' is successfully type checked but 'Other' is failed, the
outer closure has type, but the inner closure doesn't. In such state,
when the type of 'Other' is requested, the outer closure used to be
re-typechecked. That may cause crash because it may contain expressions
CSGen doesn't expect.
rdar://problem/69246891
Code completion performs 'typeCheckASTNodeAtLoc()' which ignores
'StmtChecker::ActiveLabeledStmts'. Since this is not necessary for code
completions, skip an assertion to verify the correctness of ASTScope.
rdar://problem/67102611
- Handle cases where getArgumentLabelLocs().size() == 0
- Add some assertions to verify invariants
- Explicit handling of 'llvm::Optional' for 'getUnlabeledTrailingClosureIndex()'
- Avoid walking into nodes after the removing happens
rdar://problem/65556791
Rather than attempting to temporarily insert decls
into the last source file, just create a new module
and source file and carry across the imports from
the last module. This matches how the REPL deals
with new lines of input.
When typesSatisfyConstraint() is called with 'openArchetypes=true',
archetypes are substituted with type variables. If they have
conformances, they used to hit assertion in
'MakeAbstractConformanceForGenericType::operator()'.
Adjust the assetion to accept 'TypeVariableType'.
rdar://problem/56834798
If a completion happens in an 'PatternBindingInitializer' context for
'TypedPattern' without any 'VarDecl', e.g.:
let _: Int = <COMPLETION>
it crashes because 'typeCheckPatternBinding()' requires that the
'TypedPattern' has the type.
rdar://problem/52105899
We set the type of ParamDecls when applying solutions in the normal path, but
sometimes code completion will type check an expression inside a closure without
checking the outer expression. In this case, we may have inferred a type for
the ParamDecl, but we don't write it back.
Instead, just look at the DeclRefExpr's type.
Fixes <rdar://problem/42098113>.
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:
i. Build temporary binary/postfix expression
ii. 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
