e.g. Playground.
A single file script is like a single function body; the interface of
the file does not affect any other files.
So when a completion happens in a single file script, re-parse the whole
file. But we are still be able to reuse imported modules.
rdar://problem/58378157
When a “separately imported overlay” is added to a SourceFile, two things happen:
1. The direct import of the underlying module is removed from getImports*() by default. It is only visible if the caller passes ImportFilterKind:: ShadowedBySeparateOverlay. This means that non-module-scoped lookups will search _OverlayModule before searching its re-export UnderlyingModule, allowing it to shadow underlying declarations.
2. When you ask for lookupInModule() to look in the underlying module in that source file, it looks in the overlays instead. This means that UnderlyingModule.foo() can find declarations in _OverlayModule.
There were changes due to the StringRef to std::string conversion, changes
in the Debug Info DIBuilder::createModule API, and a drop in the using for
PointerUnion4 since PointerUnion is now a variadic template and will do in its
place.
The SyntaxModel walker would end up visiting the attributes attached to a
PatternBindingDecl twice if it contained more than one VarDecl, hitting the
below assertion on the second visit because the tokens corresponding to the
attribute had already been consumed the first time around:
```
Assertion failed: (0 && "Attribute's TokenNodes already consumed?"), function
handleSpecialDeclAttribute
```
It would also hit the same assertion for attributes on an EnumCaseDecl, but even
when it only had a single child EnumElementDecl. This because when we visited
the EnumCaseDecl and pushed its structure node, we'd consume and emit any tokens
before it's start position. This meant that when we tried to process the
attributes attached to the child EnumElementDecl its tokens had already been
consumed, triggering the assertion.
In both cases the attributes syntactically attach to the parent
PatternBindingDecl or EnumCaseDecl, but in the AST they're accessed via their
child VarDecls or EnumElementDecls.
Resolves rdar://problem/53747546
Now
* NotApplicable: The result is not relevant for type relation (e.g.
keywords, and overloads)
* Unknown: the relation was not calculated (e.g. cached results), or the
context type is unknown.
* Invalid: The result type is invalid for this context (i.e. 'Void' for
non-'Void' context)
* Unrelated: The result type has no relation to the context type
* Convertible: The result type is convertible to the context type
* Identical: The result type is identical to the context type
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.
Instead of interleaving typechecking and parsing
for SIL files, first parse the file for Swift
decls by skipping over any intermixed SIL decls.
Then we can perform type checking, and finally SIL
parsing where we now skip over Swift decls.
This is an intermediate step to requestifying the
parsing of a source file for its Swift decls.
