The basic idea is that a `sourcekit-lsp://swift-macro-expansion` URL should have sufficient information to reconstruct the contents of that macro buffer without relying on any state in SourceKit-LSP. The benefit of not having any cross-request state in SourceKit-LSP is that an editor might can send the `workspace/getReferenceDocument` request at any time and it will succeed independent of the previous requests. Furthermore, we can always get the contents of the macro expansion to form a `DocumentSnapshot`, which can be used to provide semantic functionality inside macro expansion buffers.
To do that, the `sourcekit-lsp:` URL scheme was changed to have a parent instead of a `primary`, which is the URI of the document that the buffer was expanded from. For nested macro expansions, this will be a `sourcekit-lsp://swift-macro-expansion` URL itself.
With that parent, we can reconstruct the macro expansion chain all the way from the primary source file. To avoid sending the same expand macro request to sourcekitd all the time, we introduce `MacroExpansionManager`, which caches the last 10 macro expansions.
`SwiftLanguageService` now has a `latestSnapshot` method that returns the contents of the reference document when asked for a reference document URL and only consults the document manager for other URIs. To support semantic functionality in macro expansion buffers, we need to call that `latestSnapshot` method so we have a document snapshot of the macro expansion buffer for position conversions and pass the following to the sourcekitd requests.
```
keys.sourceFile: snapshot.uri.sourcekitdSourceFile,
keys.primaryFile: snapshot.uri.primaryFile?.pseudoPath,
```
We should consider if there’s a way to make the `latestSnapshot` method on `documentManager` less accessible so that the method which also returns snapshots for reference documents is the one being used by default.
Co-Authored-By: Lokesh T R <lokesh.t.r.official@gmail.com>
As a user makes an edit to a file, these requests are most likely no longer relevant. It also makes sure that a long-running sourcekitd request can't block the entire language server if the client does not cancel all requests. For example, consider the following sequence of requests:
- `textDocument/semanticTokens/full` for document A
- `textDocument/didChange` for document A
- `textDocument/formatting` for document A
If the editor is not cancelling the semantic tokens request on edit (like VS Code does), then the `didChange` notification is blocked on the semantic tokens request finishing. Hence, we also can't run the `textDocument/formatting` request. Cancelling the semantic tokens on the edit fixes the issue.
rdar://133987424
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
An accessor is a child of the corresponding variable, which is why we failed to compute the correct container for them. Look one `childOf` relation further for accessors to fix this.
rdar://129452601
This will log
```
Created workspace at … as SwiftPMBuildSystem …
```
instead of
```
```
Created workspace at … as Optional<BuildSystemIntegration.SwiftPMBuildSystem>
```
```
The SwiftPM build system integration was the only one in its own modules. Merge it into the `BuildSystemIntegration` modules next to eg. the compilation database build system.
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.
Change a l public declarations to the `package` access level, accept for:
- The `LanguageServerProtocol` module
- The `BuildServerProtocol` module
- `InProcessClient.InProcessSourceKitLSPClient`
- `LanguageServerProtocolJSONRPC` (I would like to create a more ergonomic API for this like `InProcessSourceKitLSPClient` in the future, but for now, we’ll leave it public)
Unfortunately, our pattern of marking functions as `@_spi(Testing) public` no longer works with the `package` access level because declarations at the `package` access level cannot be marked as SPI. I have decided to just mark these functions as `package`. Alternatives would be:
- Add an underscore to these functions, like we did for functions exposed for testing before the introduction of `SPI`
- Use `@testable` import in the test targets and mark the methods as `internal`
Resolves#1315
rdar://128295618
Report to clients that the server supports the
`workspace/triggerReindex` request. This lets clients expose this
functionality only if SourceKit-LSP is configured to support it.
fix!: remove `documentManager` property
fix!: remove `documentManager` in constructor
fix: added documentManager as a computed Property
fix: remove old documentmanager resetting step
fix!: get throws instead of crashing server
fix: throw ResponseError instead of NSError
fix: adding try & orLog where necesary
fix: refined orLog usage
style: ran swift-format
fix: document being opened twice
fix(DocumentManager): remove unwanted comments
lint: ran swift format
-------------------------------------------------------------------------------
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 )
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
This allows us to flip the default in the future more easily. It also allows users to disable background indexing when it’s enabled by default.
rdar://130280855
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
The purpose of the different modules wasn’t clearly defined, which lead to inconsistent responsibilities between the different modules. Define each module’s purpose and move a few files between modules to satisfy these definitions.
There are a few more larger changes that will need to be made for a fully consistent module structure. These are FIXMEs in the new Modules.md document and I’ll address them in follow-up PRs.
We need to watch for changes to `Package.resolved` so that we can update the dependency checkouts in `.index-build` when the user runs `swift package update`.
This allows VS Code to detect when sourcekitd has crashed and prompt the user to gather a diagnostic report + file an issue about the crash.
rdar://129678779
Fixes#1476
The key issue here was that we were looking at the symbol occurrence that had the `overrideOf` role and were using this symbol occurrence to also check that it’s a child of one of the receiver types. But if the protocol requirement is satisfied in an extension, we have an implicit symbol occurrence at the location where the protocol requirement is stated but the real declaration’s occurrence is inside the extension. The fix here is to just extract the USR from the `overrideOf` relation and then do another index lookup to find the symbol’s definition.
rdar://129412428
