Move the global PersistentParserState from
the CompilerInstance to the source file that code
completion is operating on, only hooking up the
state when it's needed. This will help make it
easier to requestify source file parsing.
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
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.
TypeChecker sometimes (e.g. property wrappers) inserts implicit decls
(e.g. 'PatternBindingDecl's and 'VarDecl's) between decls in the AST.
This used to confuse 'getEquivalentDeclContextFromSourceFile()'. It
canceled fast-completion, caused crashes, or completed in a wrong
context.
Ignore implicit decls in the AST so that we can find the correct decl
context.
rdar://problem/58665268
For example, if stdlib is not found, CompilerInstance simply returns
before creating PersistentParserState. In such cases, completion should
just return empty result.
Previously, it caused SourceKit crash.
rdar://problem/58663066
'getEquivalentDeclContextFromSourceFile()' didn't work for accessors
because DeclContext hierarchy and AST hierarhy are not the same.
AST hierarchy:
(TypeDecl or SourceFile) > AbstractStorageDecl > AccessorDecl
DeclContext hierarchy:
(TypeDecl or SourceFile) > AccessorDecl
Handle them specially.
rdar://problem/58632889
in all SourceKit requests.
This validation may call many stat(2). Since we don't expect system files
are edited. Disable it for SourceKit requests. Even if they are edited,
manual builds can validates and updates them.
rdar://problem/58550697
This validation may call many `stat(2)`. Since we don't expect system
files are edited. Disable it for code completion, even if they are
edited, they are validated when the user manually build the project.
rdar://problem/58550697
For each fast completion, the memory grows for the source buffer and the
AST of the function body in memory. They are kept until the next slow
completion.
To mitigate the memory consumption per completion, use sliced source
text which is actually required for the second pass.
rdar://problem/58119719
if fast-completion is enabled. So they have higher chance to use the cached
completion instance.
If it's disabled, don't block, use an ephemeral instance so we can peform
multiple completions simultaneously.
To controls the lifetime of CompilerInstance within CompletionIntance.
- Prevent from using the same CompilerInstance from multiple completion
requests
- Separate the stacktrace between "fast" and "normal" completions
- Further code consolidation between various completion-like requests
- Introduce ide::CompletionInstance to manage CompilerInstance
- `CompletionInstance` vends the cached CompilerInstance when:
-- The compiler arguments (i.e. CompilerInvocation) has has not changed
-- The primary file is the same
-- The completion happens inside function bodies in both previous and
current completion
-- The interface hash of the primary file has not changed
- Otherwise, it vends a fresh CompilerInstance and cache it for the next
completion
rdar://problem/20787086
