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
deleted OpenInterfaceRequest.swift and moved GeneratedInterfaceDetails to LanguageService.swift
replaced usages by passing its members as parameters directly, refactored usage of TextDocumentIdentifier to DocumentURI
removed from Messages.builtinRequests
removed from SwiftInterfaceTests
removed from Documentation/`LSP Extensions.md`
removed from Sources/LanguageServerProtocol/CMakeLists.txt
The idea here is to unify the different ways in which we can currently set options on SourceKit-LSP in a scalable way: Environment variables, command line arguments to `sourcekit-lsp` and initialization options.
The idea is that a user can define a `~/.sourcekit-lsp/.sourcekit-lsp` file (we store logs in `~/.sourcekit-lsp/logs` on non-Darwin platforms), which will be used as the default configuration for all SourceKit-LSP instances. They can also place a `.sourcekit-lsp` file in the root of a workspace to configure SourceKit-LSP for that project specifically, eg. setting arguments that need to be passed to `swift build` for that project and which thus also need to be set on SourceKit-LSP.
For compatibility reasons, I’m mapping the existing command line options into the new options structure for now. I hope to delete the command line arguments in the future and solely rely on `.sourcekit-lsp` configuration files.
Environment variable will be migrated to `.sourcekit-lsp` in a follow-up commit.
clangd uses a completely different semantic token legend than SourceKit-LSP (it doesn’t even adhere to the ordering of the pre-defined token types) but we were passing index offsets from clangd through assuming that clangd uses the same legend, which was incorrect.
When retrieving semantic tokens from clangd, translate the semantic tokens from clangd’s legend to SourceKit-LSP’s legend.
rdar://129895062
Users should not need to rely on this request. The index should always be updated automatically in the background. Having to invoke this request manes there is a bug in SourceKit-LSP's automatic re-indexing. It does, however, offer a workaround to re-index files when such a bug occurs where otherwise there would be no workaround.
rdar://127476221
Resolves#1263
------
Simplify `SemanticRefactoring` with new `Refactoring` protocol to handle sourcekitd requests
Create and implement `ExpandMacroCommand` while temporarily storing generated expansions.
Create test case `testFreestandingMacroExpansion`
Manually inject `ExpandMacroCommand` into `retrieveRefactorCodeActions` upon an "Inline Macro" from sourcekitd
Address Review Comments
Mark `@_spi(Testing) public` for `MacroExpansionEdit`
Address Review Comments
Create separate directory for each buffer with its name, containing a generated file named as the source file along with position range
Fixed generated macro expansion file extension not recognised, by switching to file names which don't contain fragments
Address Review Comments
Wrap the entire feature under `ExperimentalFeatures`
Address Review Comments
Make Swift Lint Pass
Fix Windows Build not passing
- Rename methods to highlight that we’re talking about generated interfaces here, not `.swiftinterface` files
- Don’t open the generated interface in `documentManager`. Opening documents in `documentManager` should only be done by the `textDocument/didOpen` notification from the LSP client. Otherwise we might indefinitely keep the document in the document manager
- After getting the generated interface from sourcekitd, close the document in sourcekitd again. We don’t provide semantic functionality in the generated interface yet, so we can’t interact with the generated interface path. Before, we left it open in sourcekitd indefinitely.
- A couple of code simplifications.
Fixes#878
rdar://116705653
This was causing a non-deterministic test failure: When target preparation finishes while a diagnostic request is in progress, it will re-open the document, which calls `DiagnosticReportManager.removeItemsFromCache` for that document’s URI. With the old implementation, we would thus cancel the diagnostics sourcekitd request and return a cancelled error to the diagnostics LSP request.
While doing this, I also realized that there was a race condition: Document re-opening would happen outside of the SourceKit-LSP message handling queue and could thus run concurrently to any other request. This means that a sourcekitd request could run after `reopenDocument` had closed the document but before it was opened again. Introduce an internal reopen request that can be handled on the main message handling queue and thus doesn’t have this problem
If the editor has support for this LSP extension, it can create a separate output view for the index log.
For example, in VS Code, we could have one output view for the standard LSP logging (which are the messages between VS Code and SourceKit-LSP if verbose logging is enabled in VS Code) and a separate log that shows information about background indexing.
rdar://128572032
We weren’t logging requests sent to a `TestSourceKitLSPClient` because we were assuming that `JSONRPCConnection` logs those requests in `SourceKitLSPServer`. But no logging happens in `LocalConnection`, which `TestSourceKitLSPClient` uses.
Since `LangaugeServerProtcol` can’t depend on `LSPLogging`, move the type to `LSPTestsSupport`.
When the semantic index is out-of-date, we currently purely rely on the syntactic index to discover tests and completely ignore data from the semantic index. This may lead to confusing behavior. For example if you have
```
class MightInheritFromXCTestCaseOrNot {}
class MyClass: MightInheritFromXCTestCaseOrNot {
func testStuff() {}
}
```
Then we don’t return any tests when the semantic index is up-to-date. But once the file is modified (either on disk or in-memory), we purely rely on the syntactic index, which reports `testStuff` as a test method. After a build / background indexing finishes, the test method disappears again.
We can mitigate this problem as follows: If we have stale semantic index data for the test file, for every test method found by the syntactic index, check if we have an entry for this method in the semantic index. If we do, but that entry is not marked as a test class/method, we know that the semantic index knows about this method but decided that it’s not a test method for some reason. So we should ignore it.
rdar://126492948
For example when trying to go-to-definition to `filter` on `Array`, we get a USR `s:s14_ArrayProtocolPsE6filterySay7ElementQzGSbAEKXEKF::SYNTHESIZED::s:Sa`. We were trying to look it up in the index, which failed because synthesized extension methods are not indexed.
Instead, consult the `module` and `groupName` that `sourcekitd` returns in the cursor info request to decide which module to jump to.
rdar://126240558
This allows us to return swift-testing tests within a single document. It does not look for swift-testing tests workspace-wide (the `workspace/tests` request), which will be a follow-up PR.
