This request is generally useful, not only for tests within SourceKit-LSP but also:
- In editor tests that want to test the integration with SourceKit-LSP
- In code analysis tools that want to gather project information using SourceKit-LSP and need an up-to-date index for that.
Remove the experimental feature guard from `workspace/_synchronize`, consequently rename it to `workspace/synchronize` and only guard the `buildServerUpdates` option on the synchronize request by an experimental feature because its long-term usefulness is still not fully understood yet.
When the client supports it, communicate the structure of tasks that were stared during background indexing or by the build server to the client. If there are multiple operations happening in parallel, this allows the client to display them in separate log tracks instead of interspersing them with the emoji prefixes like we do today.
This can be useful to IDEs that want to perform some additional semantic processing of source files, which requires knowledge of a file’s build settings.
- Clarify that this must only be called with documents that are open in SourceKit-LSP and add a check for that.
- Allow sending `null` to indicate that no SourceKit-LSP document is currently active.
- Cancel preparation tasks for other workspaces that don’t contain the currently active document.
This request allows IDEs to disable SourceKit-LSP’s background indexing functionality when it requires all compute resources for other, more interactive, tasks.
SourceKit-LSP prepares the currently active file for editor functionality and currently infers the currently active document from whichever received the last `TextDocumentRequest`.
If an editor is capable of doing so, it should be able to report the document that the user currently has focused so that SourceKit-LSP does not have to infer this information from other requests.
Also clean up some handling code for experimental capabilities.
VS Code spells file paths with a lowercase drive letter, while the rest of Windows APIs use an uppercase drive letter. Normalize the drive letter spelling to be uppercase.
Fixes#1855
rdar://141001203
When removing the LanguageServerProtocol namespace from types in
ClientCapabilities (#1734), some types inadvertently started shadowing
themselves. This lead to client initialization errors when the
initialization request couldn't be decoded:
```
type mismatch at params.capabilities.textDocument.completion.completionItemKind.valueSet.Index 0 : Expected to decode Dictionary<String, Any> but found number instead.
```
Disambiguating these inner types in ClientCapabilities fixes decoding.
The URI standard RFC 3986 is ambiguous about whether percent encoding and their represented characters are considered equivalent. VS Code considers them equivalent and treats them the same:
```js
vscode.Uri.parse("x://a?b=xxxx%3Dyyyy").toString() -> 'x://a?b%3Dxxxx%3Dyyyy'
vscode.Uri.parse("x://a?b=xxxx%3Dyyyy").toString(/*skipEncoding=*/true) -> 'x://a?b=xxxx=yyyy'
```
This causes issues because SourceKit-LSP's macro expansion URLs encoded by URLComponents use `=` do denote the separation of a key and a value in the outer query. The value of the `parent` key may itself contain query items, which use the escaped form '%3D'. Simplified, such a URL may look like `scheme://host?parent=scheme://host?line%3D2`.
But after running this through VS Code's URI type `=` and `%3D` get canonicalized and are indistinguishable.
To avoid this ambiguity, always percent escape the characters we use to distinguish URL query parameters, producing the following URL: `scheme://host?parent%3Dscheme://host%3Fline%253D2`.
Do one of the following for every `FIXME` or `TODO` comment
- Add an issue that tracks the task
- Remove the comment if we are not planning to address it
As part of its initialization options the client can pass a
textDocument/codeLens object that lists the supported commands the
client can handle.
It is in the form of a dictionary where the key is the lens name
recognized by SourceKit-LSP and the value is the command as recognized
by the client.
```
initializationOptions: {
"textDocument/codeLens": {
supportedCommands: {
"swift.run": "clientCommandName_Run",
"swift.debug": "clientCommandName_Debug",
}
}
}
```
Adds a response to the textDocument/codeLens request that returns two
code lenses on the `@main` attribute of an application.
The LSP documentation breaks out the code lens requests into a
[`Code Lens Request`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_codeLens)
and a
[`Code Lens Resolve Request`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeLens_resolve),
stating this is for performance reasons. However, there is no intensive
work we need to do in order to resolve the commands for a CodeLens;
we know them based on context at the time of discovery. For this reason
we return resolved lenses with Commands for code lens requests.
A missing piece is only returning code lenses if the file resides in an
executable product. To my knoledge Libraries and Plugins can't have an
`@main` entrypoint and so it doesn't make sense to provide these code
lenses in those contexts.
Some guidance is required on how to best determine if the textDocument
in the request is within an executable product.
`testCodeLensRequestWithInvalidProduct` asserts that no lenses are
returned with the `@main` attribute is on a file in a `.executable`, and
is currently failing until this is addressed.
`TriggerReindexRequest` was missing from the list of builtinRequests,
which caused the LSP to respond with a methodNotFound error when it
recieved a `workspace/triggerReindex` request.
-------------------------------------------------------------------------------
This implements an LSP Extension `PeekDocumentsRequest` to let `ExpandMacroCommand` to open the macro expansions in a "peeked" editor window.
For this to work, the client has to pass "workspace/peekDocuments" enabled to `ClientCapabilities.experimental` and the client should handle the `PeekDocumentsRequest` and show the expansions in a "peeked" editor window.
PR to support the above capability in the "Swift for VS Code" Extension: https://github.com/swiftlang/vscode-swift/pull/945
The "Swift for VS Code" extension cannot send the client capability, so it instead passes the same through `initializationOptions` in the `InitializeRequest`.
For editors which doesn't support this capability, `sourcekit-lsp` sends a `ShowDocumentRequest`.
The `ShowDocumentRequest` is updated to show all the macro expansions in a single generated file. Moreover, its folder structure is updated to use hex string of MD5 hash of concatenation of buffer names of expansions.
Fixes https://github.com/swiftlang/vscode-swift/issues/564
Fixes https://github.com/swiftlang/sourcekit-lsp/issues/1498 ( rdar://130207754 )
VS Code does not cancel semantic tokens requests. If a source file gets into a state where an AST build takes very long, this can cause us to wait for the semantic tokens from sourcekitd for a few minutes, effectively blocking all other semantic functionality in that file.
To circumvent this problem (or any other problem where an editor might not be cancelling requests they are no longer interested in) add a maximum request duration for SourceKitD requests, defaulting to 2 minutes.
rdar://130948453
