We used to compute the mangled name in other cases, but document structure is
a syntactic request and can't guarantee that the class/protocol we're getting
the mangled name of is valid in any way so it often breaks assumptions in the
mangler and causes it to crash. It's not clear if the runtime_name is actually
being used anymore, so this change restricts reporting it to just the cases
where we don't need to mangle.
rdar://problem/40956377
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
Add a global -module-cache-path option to `sourcekitd-test` and
`complete-test` and have lit provide the default module cache in its
substitutions. Previously many tests have explicitly provided the
`%mcp_opt` option, but this is easy to forget when writing new tests.
The module cache is inserted into the compiler arguments at the
beginning so that it's still possible for a test to override it with a
per-test cache if desired.
rdar://58752842
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
SwiftSourceInfo files provide source location information for decls coming from
loaded modules. For most IDE use cases it either has an undesirable impact on
performance with no benefit (code completion), results in stale locations being
used instead of more up-to-date indexer locations (cursor info), or has no
observable effect (live diagnostics, which are filtered to just those with a
location in the primary file).
For non-IDE clients of SourceKit though, cursor info providing declaration
locations for symbols from other modules is useful, so add a global
configuration option (and a new request to set it) to control whether
.swiftsourceinfo files are loaded or not based on use case (they are loaded by
default).
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.
USRs generated for the index store and sourcekit requests for invalid decls are
best-effort – we don't need to guarantee they can be de- or re-mangled.
The quoting of the sed commands was creating problems in my Windows
installation. I am unsure if the implementation of sed.exe is different
or the cmd.exe is different.
In order to avoid problems in different machines, replace the piped sed
commands into only one python script. This should be multiplatform and
should execute the same in any of them. It also remove a lot of the
extra quoting and escaping, and avoids 5 processes for only just one.
It looks like we recently started binding extensions to their nominals in order
to continue to compute access levels via ValueDecl::getFormalAccess() after an
assertion was added to enforce that bindExtensions had been called before
anything tried to call ExtensionDecl::getBoundNominal() - which
getFormalAccess() depends on. Sourcekitd's syntactic requests are made on every
keypress in the editor though, so we shouldn't do any name binding (which may
require module loading) to keep them as fast as possible.
This patch restores the old inferAccessLevel() functions we used prior to the
switch to ValueDecl::getFormalAccess() (plus a few fixes) that does as much as
it can syntactically, without any name binding, and simply doesn't report the
access level in cases where it couldn't be computed without name-binding.
This also fixes an assertion hit we were getting trying to bind extensions in
inactive ifconfig clauses, which ASTScope doesn't support.
Resolves rdar://problem/57202584
It was being used purely to get the name of the type context for a diagnostic
message. SourceKit's syntactic-only requests were hitting an assertion when
this diagnostic was triggered because they don't set up a type checker.
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.
