This generally seems like the cleaner design because `SourceKitServer` is actually able to semantically inspect the message and decide whether it can be handled concurrently with other requests.
Instead of storing build settings inside the language servers based on update notifications from the build system, always call into the `BuildSystemManager` to get the build settings.
Overall, I think this is a much clearer separation of concerns and will allow us to remove `SourceKitServer.documentToPendingQueue` in a follow-up commit as `SwiftLanguageServer` can always directly call into `BuildSystemManager` to get build settings and we don’t need to wait for the initial notification to receive the first build settings.
This requies `BuildServerBuildSystem` to keep track of the build settings it has received from the BSP server.
`ClangLanguageServer` still caches build settings locally. `ClangLanguageServer` will change to the same pull-based model in a follow-up commit.
This is the prerequisite for making `SourceKitServer` an actor, which will mean that the `handle` methods will be `async`.
The current paradigm of returning from `handle` once we can guarantee that there’s no out-of-order execution and then returning the actual result via the callback that’s attached to `Request` is a little weird still. I am hoping to change this paradigm to return the actual result and have a callback function that `handle` can call to indicate that it’s ready to accept another message while guaranteeing in-order execution, essentially flipping the role of the return value and the closure callback. But that’s something to be done after the entire stack has been asyncificied.
When we switch `SourceKitServer`, `SwiftLanguageServer` etc. to be actors, we can’t rely on them to provide ordering guarantees anymore because Swift concurrency doesn’t provide any ordering guarantees.
What we should thus do, is to handle all messages on a serial queue on the `Connection` level. This queue will be blocked from handling any new messages until a message has been sufficiently handled to avoid out-of-order handling of messages. For sourcekitd, this means that
a request has been sent to sourcekitd and for clangd, this means that we have forwarded the request to clangd.
Note that this serial queue is not the main thread, so we will continue accepting data over stdin, just the handling of those messages is blocked.
The asyncification changes caused some non-deterministic test failures. I believe that some of these are due to race conditions that are the result of the partial transition to actors.
Instead of merging the asyncification piece by piece, I will collect the changes asyncification changes in a branch and then qualify that branch througougly (running CI multiple times) before merging it into `main`.
Instead of storing build settings inside the language servers based on update notifications from the build system, always call into the `BuildSystemManager` to get the build settings.
Overall, I think this is a much clearer separation of concerns and will allow us to remove `SourceKitServer.documentToPendingQueue` in a follow-up commit as `SwiftLanguageServer` can always directly call into `BuildSystemManager` to get build settings and we don’t need to wait for the initial notification to receive the first build settings.
This requies `BuildServerBuildSystem` to keep track of the build settings it has received from the BSP server.
`ClangLanguageServer` still caches build settings locally. `ClangLanguageServer` will change to the same pull-based model in a follow-up commit.
Instead of storing build settings inside the language servers based on update notifications from the build system, always call into the `BuildSystemManager` to get the build settings.
Overall, I think this is a much clearer separation of concerns and will allow us to remove `SourceKitServer.documentToPendingQueue` in a follow-up commit as `SwiftLanguageServer` can always directly call into `BuildSystemManager` to get build settings and we don’t need to wait for the initial notification to receive the first build settings.
This requies `BuildServerBuildSystem` to keep track of the build settings it has received from the BSP server.
`ClangLanguageServer` still caches build settings locally. `ClangLanguageServer` will change to the same pull-based model in a follow-up commit.
This is the prerequisite for making `SourceKitServer` an actor, which will mean that the `handle` methods will be `async`.
The current paradigm of returning from `handle` once we can guarantee that there’s no out-of-order execution and then returning the actual result via the callback that’s attached to `Request` is a little weird still. I am hoping to change this paradigm to return the actual result and have a callback function that `handle` can call to indicate that it’s ready to accept another message while guaranteeing in-order execution, essentially flipping the role of the return value and the closure callback. But that’s something to be done after the entire stack has been asyncificied.
When we switch `SourceKitServer`, `SwiftLanguageServer` etc. to be actors, we can’t rely on them to provide ordering guarantees anymore because Swift concurrency doesn’t provide any ordering guarantees.
What we should thus do, is to handle all messages on a serial queue on the `Connection` level. This queue will be blocked from handling any new messages until a message has been sufficiently handled to avoid out-of-order handling of messages. For sourcekitd, this means that
a request has been sent to sourcekitd and for clangd, this means that we have forwarded the request to clangd.
Note that this serial queue is not the main thread, so we will continue accepting data over stdin, just the handling of those messages is blocked.
We are moving to a better model for TSC's path APIs in apple/swift-tools-support-core#353. The previous API is still available (but deprecated) as much as possible, but since SourceKit-LSP was using `resolveSymlinks` (which is now throwing) quite a bit, there are some changes necessary.
A declaration request is similar to a definition request, except that it is expected to return (potentially) many results across the workspace for a given reference. For example, an inline function or macro may have many declarations in the workspace, but only one "good" or canonical definition. For now, this is only implemented by forwarding the request on to clangd since I'm unfamiliar with a SourceKit query for this.
For languages like Swift that lack such a sharp declaration/definition split, we could potentially use this request to provide navigable metadata on linked definitions. For example, the declaration for a type reference would include all extensions of that type in the workspace.
Add a dependency on TSCBasic for LanguageServerProtocol. This dependency was added recently via an `import` and was updated in Package.swift but was missed in the CMake build.
When converting the URI to a path string, ensure that we convert to the
file system representation. This is important as this ensures that we
are always passing SourceKit the native path string. With this change,
the code completion behaviour for the LSP test suite on Windows is
repaired.
- Add typeHierarchyProvider
- Implement prepareTypeHierarchy request
- Add supertype and subtype request handlers
- Implement supertypes and subtypes request
- Display location and conformance of extensions in type hierarchy
- Include extensions in the type hierarchy
- Include module names in type hierarchy
- 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.
This makes SourceKitServer keep track of multiple workspaces and their handling. It does not include the functionality to determine which workspace a file belongs to.
This makes SourceKitServer keep track of multiple workspaces and their handling. It does not include the functionality to determine which workspace a file belongs to.
This adjusts the sourcekit-lsp build to use static linking for the
internal libraries. It is not currently possible to build
SourceKitLSP.dll as that requires re-exporting the interfaces from the
consumed modules. However, this allows us to reduce the overall size of
the distribution of SourceKit-LSP by ~1 MiB and reduces the
distributed file set. The values here assume partial static linking of
swift-package-manager, which helps reduce the total size.
Before:
228,352 BuildServerProtocol.dll
1,773,056 LanguageServerProtocol.dll
114,688 LanguageServerProtocolJSONRPC.dll
49,152 LSPLogging.dll
262,656 SKCore.dll
54,784 SKSupport.dll
80,896 SKSwiftPMWorkspace.dll
150,528 SourceKitD.dll
645,632 SourceKitLSP.dll
70,144 sourcekit-lsp.exe
3,429,888 bytes
After:
2,416,640 sourcekit-lsp.exe
2,416,640 bytes
This will add an additional link request for dispatch and Foundation
libraries. These are really required on non-Darwin targets, and should
be satisfied either by the library search path or by explicitly
indicating where the dependencies can be found.
