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
- Analyze the type of the literal in the context
- If ':' is missing in the literal, treat the expression as a key
expression
- If the parent expression is TupleExpr, analyze the context type of the
tuple first, then return the element type of the position
rdar://problem/57096392
'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
in override completion. As per SE-0244:
> Associated type inference can only infer an opaque result type for a
> non-generic requirement, because the opaque type is parameterized by
> the function's own generic arguments
instead of AssociatedTypeDecl::getInherited() when checking if the
return type should be suggested as "opaque result type" in override
completion.
AssociatedTypeDecl::getInherited() is not serialized. So if the protocol
is declared in a module, it was never suggested as 'some' result.
rdar://problem/57245073
This reverts commit e805fe486e, which reverted
the change earlier. The problem was caused due to a simultaneous change to some
code by the PR with parsing and printing for Clang function types (#28737)
and the PR which introduced Located<T> (#28643).
This commit also includes a small change to make sure the intersecting region
is fixed: the change is limited to using the fields of Located<T> in the
`tryParseClangType` lambda.
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
Well, this does nothing. It just set the parser position twice and calls
the consumer's 'handleResults()' without any reason.
It seems it was intended to be a "fallback" completion, but it was never
implemented properly. So just remove it for now.
rdar://problem/58102910
In fast completion scenario, 'AbstractFunctionDecl' may have the body
from the different file than the decl itself. Thay may confuses source
range checking.
As a workaround, always look into decls regardless of the range. This
should not regress the speed of the searching much because
statements/expressions (including nested function bodies) in the decl
is still skipped if it's outside the range.
rdar://problem/58098222
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
