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>.
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
While trying to diagnose the problem with previously type-checked
sub-expression, use its type-checked variant as a source of type
information, instead of transferring from its original constraint system,
because if expression was type-checked successfully it would
have all of the required information in AST, and that doesn't
rely on associated constraint system being present.
Resolves: rdar://problem/42056741
Parser didn't capture correct context when code completion
was attempted on typealias' right-hand side which, if there are
generic parameters present, would result in a crash. These
changes make it so completion gets a correct declaration
context in aforementioned case and typealias declaration is marked
invalid because it doesn't have a proper type.
Resolves: rdar://problem/39909829
Otherwise, when the horrible ExprCleanser comes along, it will set
the interface type of the ParamDecl to nullptr. However there is
no way to clear the 'validation started' bit, so the next time
validateDecl() is called on this ParamDecl we will just return,
causing crashes downstream when callers expect it to already have
an interface type set.
Fixes <rdar://problem/38189778> and possibly some instances of
<rdar://problem/36434823>.
In one place we were calling hasError() and in another directly checking
for ErrorType; if we had a type containing an ErrorType as a structural
component, we would hit an assertion.
