For instance:
--
let globalVar = {
func something(arg: Int) -> Int {
#^HERE^#
}
return something(12)
}()
--
We want to consider this as a top-level completion, not a function body
completion.
rdar://problem/60838686
Pass '-fbuild-session-timestamp' and '-fmodules-validate-once-per-build-sessio'
to ClangImporter so that module validation happens only once for the
SourceKit lifetime.
rdar://problem/59567281
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
In fast-completion, a function body can be replaced with another function
body parsed from a new buffer. In such cases, during typechecking the
expressions in the *new* function body, a source location range check in
UnqualifiedLookup didn't work well because they are not from the same
buffer.
This patch workaround it by skipping the source range checks and returns
'success' in such cases.
rdar://problem/58881999
If a CC token is right after the '{' we still don't know it's an implicit
getter or a start of a accessor block. Previously, the parser used to
parse it as an accessor block, but it prevents fast-completion kicks in.
Instead handle it as a part of function body parsing so the
fast-completion works.
rdar://problem/58851121
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
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
This adjusts the tests for the difference between line endings on
different platforms. Windows uses CRLF while most Unicies use LF. This
was exposed during the update to the new LLVM snapshot.
To check if the completion is happening in the AFD body.
Otherwise, local variables are sometimes not suggested because the body
and its range is from another file.
rdar://problem/58175106
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
Using \0 as a representation of the cursor position is a implementation
detail and is done by SourceKit. Client including complete-test should
not do it.
This inserted test used to be treated as EOF in compiler so the code
after the completion position is completely ignored.
The VFS tests were using Unix absolute paths, which does not play well
when Windows see them as relative to the current drive letter.
By using the temporal directory, both Windows and Unix can use the same
paths and avoid the problem.
Additionally, a couple of inputs have to be transformed into the native
path format, because sourcekitd-test compares the inputs as strings, and
they need to match exactly. So the source file and the name of the VFS
entries are transformed into native using the helper from LLVM support.
- Use `performParseAndResolveImportsOnly()` to invoke the frontend
- Do `bindExtensions()` in `ide::typeCheckContextUntil()`
- Typecheck preceding `TopLevelCodeDecl`s only if the compleiton is in
a `TopLevelCodeDecl`
- Other related tweaks
rdar://problem/56636747
This seems more correct than OtherModule, and means they're treated as
low-priority results for the session-based completion APIs. With default
options that means won't be shown in global completion results but will be
once there's some matching filter text. It also sorts them below any symbols
that actually come from other modules, which is desirable, since most symbols
don't need to be module qualified.
The SemanticContextKind change doesn't seem to affect Xcode's handling of the
results.
There were some changes to completion results because AST mutations that were
made while diagnosing are no longer happening.
This patch 1) changes expression type checking to allow unresolved types when
solving constraint systems, so we get a solution and apply its types in more
cases, and 2) fixes a parsing issue where we would drop a ternary expression
completely if the code completion point was in its true branch.
When filtering, make sure the FileCheck sees only the filtered results
and not accidentally pick up the unfiltered output from the initial
"open" request.
