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.
We have a hack where we use the ParsedDecl as the DeclContext,
to handle completion during function signature parsing, which
happens before the FuncDecl has been created.
While fixing this properly would require a bigger change to the
parser and AST, for now we just check if the ParsedDecl is a
child context of CurDeclContext, and only use it then.
Complete generic parameters and their members inside generic where
clauses on structs, classes, enums, extensions, typealiases, funcs,
subscripts and inits.
Still not handled correctly are associatedtypes.
rdar://problem/20582394
`FreeTypeVariableBinding::GenericParameters` mode allowed to bind
all free type variables with fresh generic parameter types, which
is incorrect (at least) if there are multiple generic solutions
present, because such parameters couldn't be compared.
This mode was used for code completion, which is now switched to use
`FreeTypeVariableBinding::UnresolvedType` instead.
This doesn't give particularly useful information yet (i.e. Self isn't
listed, see rdar://problem/31981641 ), but it does stop the completion
code from just directly crashing.
Fixes rdar://problem/31981486.
Swift 3 supported limited argument destructuring when it comes to
declaring (trailing) closures. Such behavior has been changed by
SE-0110. This patch aims to provide better error message as well
as fix-it (if structure of the expected and actual arguments matches)
to make the migration easier and disambiguate some of the common
mistakes.
Resolves: SR-4738, SR-4745, rdar://problem/31892961.
When performing a name lookup from inside of a protocol
or extension, skip directly to the source file context
when we are done visiting the protocol or extension.
Otherwise, if we have invalid code where the protocol
or extension is nested inside another type, we might
find a member whose type contains generic parameters
of the outer type; these parameters will not resolve,
since we do not model protocols or extensions nested
inside generic contexts (yet?).
This supercedes an earlier workaround for a similar
issue; the new workaround fixes more crashes.
This is needed to avoid crasher regressions with an
upcoming patch.
The unfixed ones were discovered by fuzzing. I have fixes for most
of them in an in-progress PR.
One that was already fixed is just a regression test I'm adding.
