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
Fixes code-completion crash in validateExtension().
When code completion happens, it tries to validate decl contexts. If
it's in an extension in inactivec conditional block, the extension
haven't been bound to nominal type. That used to cause crash because its
GenericParams hasn't been set.
rdar://problem/45275782
https://bugs.swift.org/browse/SR-9001
There is an invariant that SignatureConformances should have the same
size as the number of conformance requirements in the signature.
Previously, since unsatisfied requirements weren't reflected in it,
that caused a crash.
rdar://problem/43625800
`CS.solve()` with `FreeTypeVariableBinding::Disallow` still may emit
unresolved type. e.g. `DeclRefExpr` to decl with unresolved type.
https://bugs.swift.org/browse/SR-8568
rdar://problem/43433253
Unresolved type attached to expressions may fail re-typechecking.
Also, disallow unresolved type in typeCheckCompletionSequence(). It doesn't
provide useful completions to developers.
rdar://problem/41224316
Existence of semantic expr (`getSemanticExpr()`) prevents ASTWalker
walking into the *original* sub expressions which may cause
re-typechecking failure. For example,
`ConstraintGenerator::visitArrayExpr()` assumes we already visited its
elements, but that's not the case if the semantic expr exists.
rdar://problem/42639255
Since constraint solver has been improved to diagnose more problems
via "fixes", sometimes applying fixes might lead to producing solutions
which are completely ambiguous when compared to each other, and/or are
incomparable, which leads to `findBestSolutions` erasing all of them
while trying to compute best "partial" solution, which is incorrect.
Resolves: rdar://problem/42678836
Fix ASTVerifier error for end location of 'IfConfigDecl'.
Previously, for:
```
#if
// something
<COMPLETE>
```
End location of the dummy body of 'TopLevelCodeDecl' was at the eof, but the
end loc of the 'IfConfigDecl' was at the code-completion token. That
caused the ASTVerifier error "invalid IfConfigStmt end location".
https://bugs.swift.org/browse/SR-2364
rdar://problem/41217187
Although backtick is a kind of trivia piece, Token::getCommentRange doesn't
take it into account. Invalid Token::getCommentRange used to cause
compiler crash.
rdar://problem/42492793
https://bugs.swift.org/browse/SR-8315
