In order to make range-shifting for semantic highlighting testable,
disable returning semantic information during an "open" request. This
has no real value anyway, since it only happens very rarely, and it
makes testing range shifting impossible to do deterministically.
rdar://problem/66386179
When performing an insertion (replacement length = 0) inside an existing
annotation, we were forming a closed range instead of a half-open range,
causing us to shift the effected token instead of throwing it out. There
were also no tests for this functionality, so add a bunch of annotations
tests.
One area thing that is not tested is what if there have been multiple
edits since the tokens were created. This is difficult to engineer,
because right now making an edit immediately removes the semantic tokens
and returns them. It could happen if the AST build takes longer than the
edits, but there is no way to guarantee that in the current API.
rdar://65748892
Return type in the closure signature is often redundant when expanding
placeholders, because the type of the clossures are usually inferred
from the context (i.e. calling function), users don't need to write the
return type explicitly.
They are not only redundant, but also sometimes harmful when the return
type is a generic parameter or its requirement. Actually, there is no
correct spelling in such cases.
So omit the return type and the parentheses around the parameter clause.
rdar://problem/63607976
Do not remove semantic annotations, so that if a client sends multiple
magic replacetext 0, 0, "" requests they will all return the same
result. This makes sourcekitd more robust around providing semantic
highlighting if the editor may make multiple queries for document
update.
rdar://64904029
Single-expression closures have always been traversed differently
from multi-statement closures. The former were traversed as if the
expression was their only child, skipping the BraceStmt and implicit
return, while the later was traversed as a normal BraceStmt.
Unify on the latter treatment, so that traversal
There are a few places where we unintentionally relied on this
expression-as-child behavior. Clean those up to work with arbitrary
closures, which is an overall simplification in the logic.
Currently when parsing a SourceFile, the parser
gets handed pointers so that it can write the
interface hash and collected tokens directly into
the file. It can also call `setSyntaxRoot` at
the end of parsing to set the syntax tree.
In preparation for the removal of
`performParseOnly`, this commit formalizes these
values as outputs of `ParseSourceFileRequest`,
ensuring that the file gets parsed when the
interface hash, collected tokens, or syntax tree
is queried.
Since placeholder expansion works with a single placeholder, which is
somewhat at odds with multiple-trailing closures, we eagerly attempt to
expand all consecutive placeholders of closure type. That is, if the API
has multiple closure parameters at the end, expanding any one of them
will transform all of them to the new syntax.
Example
```
foo(a: <#T##()->()#>, b: <#T##()->()#>)
```
expanding *either* parameter will produce the following:
```
foo {
<#code#>
} b: {
<#code#>
}
```
(caveat: the indentation is not part of placeholder expansion, but it's
added here for clarity)
At least for now we do not attempt to corral an existing closure into
the new syntax, so for
```
foo(a: { bar() }, b: <#T##()->()#>)
```
The exansion will be
```
foo(a: { bar() }) {
<#code#>
}
```
as it was before.
rdar://59688632
Now that we no longer perform whole-file type
checking for code completion, the ASTVerifier is
no longer expecting fully semantically valid AST.
As such, we no longer need to emit an error to
force it to be more lax with its checks.
Remove the `EvaluateConditionals` flags from the
parser, and instead query the source file.
This commit also changes ParserUnit such that it
doesn't evaluate #if conditions by default, as
none of its clients appear to require it. The
only client that wasn't explicitly disabling #if
evaluation and is processing the resulting AST is
swift-indent, so this commit also adds a test to
ensure it continues to work correctly with #if
decls.
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
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
Patch up all the places that are making a syntactic judgement about the
isInvalid() bit in a ValueDecl. They may continue to use that query,
but most guard themselves on whether the interface type has been set.
Specifically, if the document was re-opened, we would drop the reference
and the call to readSemanticInfo could use-after-free the array of
diagnostics. This manifested as a very rare crash while testing
sourcekit-lsp.
Ensure that lazy parsing of the members of nominal type definitions
and extensions is handled through a request. Most of the effort here
is in establishing a new request zone for parser requests.
Some requests are implemented in lib/Sema/, even if they don't require a
LazyResolver. Be sure to register their request functions in SourceKit so
that these requests can be kicked off when needed.
Propagates the VFS to the SemanticInfo that gets used when then
original editor.open is syntactic only.
Removes unnecessary filesystem arg (get filesystem from class field
instead).
Adds test for the VFS being propagated into the SemanticInfo.
Refactors test/SourceKit/CursorInfo/injected_vfs.swift to use
-print-raw-response for all its tests, for consistency.
The invocation options are not an appropriate place to put this state,
since it can change between requests. This moves it to the editor
document, allowing us to change the specific VFS instance without
causing a rebuild (unless the contents/timestamps for a dependency
change).
Update the PlaceholderFinder ASTWalker to walk into the clauses of
IfConfigDecls. It wasn't previously, resulting in any placeholders there not
being expanded.
Also update CallExprFinder (used to determine if expansions should use trailing
closure syntax) to walk into inactive if-config clauses. Previously it only
walked into active regions, so expansions never used trailing closure syntax in
inactive regions.
Resolves rdar://problem/51995648
In addition to brace statements (previously handled), several other
statements allow a trailing closure (return, yield, throw). Also fix the
handling of statements nested within expressions for closures - both
single-expression bodies and brace statements.
This also fixes a particular regression caused by single-expression
function bodies where we would fail to expand to a trailing closure when
a function body only contained a single expression.
rdar://50227500
Ensure the various entity walkers handle the implicit subscript
reference correctly (usually by ignoring it) and fall through to the
underlying declarations.
rdar://49028895
When building the implicit subscript expression, set the "implicit" bit
correctly and pass it through in the indexer so that we get implicit
refernces to the subscript. This would be useful for e.g. searching for
all uses of the dynamic subscript.