Depends on https://github.com/swiftlang/swift/pull/83378
---
Adds support for the LSP signature help request.
> [!NOTE]
> As of https://github.com/swiftlang/swift/pull/83378, SourceKitD still
doesn't separate parameter documentation from the signature
documentation and thus parameters don't have their own separate
documentation. This should just work once SourceKitD implements this
functionality and we'll only need to modify the tests.
The motivation for this is that I noticed that the `workspace/peekDocuments` request only allows the specification of a document to peek but not the location to peek within it. The fix is to change the `location` parameter from `DocumentUri` to `Location`, but this is a protocol-breaking change, so the client needs to communicate that it can support locations in the `workspace/peekDocuments` request.
The client currently communicates that it supports peeking documents by passing `workspace/peekDocuments: true` in the experimental client capabilities. We could just add another option to the experimental client capabilities like `workspace/peekDocuments.supportsLocations` but this seems a little hacky. Instead, what I propose is that we
1. Allow enabling experimental capabilities as `"<capability name>": { "supported": true }`
2. Switch the VS Code Swift extension to enable client capabilities using a dictionary if it discovers that it uses SourceKit-LSP ≥6.3 (older SourceKit-LSP don’t recogize a dictionary as enabling a capability)
3. Expanding the options to `"workspace/peekDocuments": { "supported" true, "supportsLocation": true }` to communicate that location-based peeking is supported
This pattern will also support experimental capability changes like this in the future.
Use cases that might lack because of this are:
1. Using an old Swift 6.3 toolchain that doesn’t support dictionary-based capabilities with the VS Code Swift extension. In that case macro expansion will work in the fallback mode that we have for other editors and active editor tracking (which cancels target preparation when a file is switched) is disabled. I think this is acceptable.
2. If there are other editors that support these experimental capabilities, they will continue to work just fine by passing the boolen value to enable the option. If they want to support one of the options (eg. location-based peeking), they will need to switch to dictinary-based enabling and thus check the SourceKit-LSP version prior to startup. This might be mildly annoying on their side but since the number of client that support these capabilities should be very small (I am not aware of any) and they need to explicitly opt-in to the new behavior, I think this is also acceptable.
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.
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
Improve `CapabilityRegistry` and surrounding code in a couple of ways
- Make `CapabilityRegistry` an actor
- Refactor `CapabilityRegistry` to duplicate less code
- Ensure that `SourceKitServer` reports all capabilities of `SwiftLanguageServer` if the client doesn’t support dynamic capability registration. We were missing this for semantic tokens and inlay hits
- Add a few doc comments
This allows us to cancel the semantic tokens request. It is also the last step to allow us to open and edit documents in syntactic-only mode.
It also means that we no longer need to send a `WorkspaceSemanticTokensRefreshRequest` to the client after sourcekitd has updated its semantic tokens since with the new design the `DocumentSemanticTokensRangeRequest` will simply return the results once it has the updated semantic token.
OSLog is the suggesting logging solution on Apple platforms and we should be using it there, taking advantage of the different log levels and privacy masking.
Switch sourcekit-lsp to use OSLog on Apple platforms and implement a logger that is API-compatible with OSLog for all uses in sourcekit-lsp and which can be used on non-Darwin platforms.
The goal of this commit is to introduce the new logging API. There are still improvements about what we log and we can display more privacy-insensitive information after masking. Those changes will be in follow-up commits.
Add `.swift-format` to the repo and format the repo with `swift-format`.
This commit does not add any automation to enforce formatting of sourcekit-lsp in CI. The goal of this commit is to get the majority of source changes out of the way so that the diff of actually enforcing formatting will have fewer changes or conflicts.
- Use official textDocument/inlayHint request
- Rename InlayHintCategory to InlayHintKind
- Additionally, represent it using an Int, as in the proposed LSP API.
- Add inlay hint client capabilities
- Add inlay hint server capabilities
- Add dynamic registration of inlay hint request
- Rename InlayHintsRequest -> InlayHintRequest
This is to be consistent with the request itself being named in singular
in LSP and the other requests (e.g. DocumentSymbolRequest).
- Forward inlay hint requests to clangd
- Add colon before inlay hints
- Add other properties to InlayHint
- Add InlayHintLabel structures
- Conform InlayHintLabel to ExpressibleByStringX protocols
- Attach TextEdit to inlay hints for committing them
- Add InlayHint.data
- Fix InlayHintTests
We need to include text edits in the expected inlay hints.
Implement rudementary support for `DidChangeWatchedFileNotification` for SwiftPM projects: When a file is added, reload the Swift package to compute build settings for it.
This enables proper semantic functionality added to the project after the LSP server was started.
Resolves SR-15633
This adds support for clangd commands for clients which support
dynamic registration (including VS Code), as well as fixes an
issue which prevented clangd's code actions from working.
Also added a test to ensure the clangd code actions work, as well as regenerated the Linux test main (which was missing some other newly added tests).
- Add LSP types for semantic highlighting
- Limited to clients which support dynamic registration for semantic highlighting
- Requires clangd 11 or later
Using dynamic registration (when supported by the client) allows
us to provide different completion options for ObjC and Swift
files.
We should be able to expand this to other capabilities in the future
(e.g. semantic highlighting, execute command support).
