It’s not entire clear why we have a fallback value if no document service can serve a request and I checked that VS Code behaves if we return empty results for jump to definition or if we return an error. To simplify the codebase, we should just throw an error here and remove the `fallback` parameter from `handleRequest`.
Resolves#862
rdar://116703662
When receiving a `CancellationNotification`, we cancel the task that handles the request with that ID.
This will cause `cancel_notification` to be sent to sourcekitd or a `CancellationNotification` to be sent to `clangd`, which ultimately cancels the request.
rdar://117492860
With this change, opening and editing a document no longer causes a non-cancellable AST build. Instead, all semantic information is retrieved via requests that can be cancelled (after we implement cancellation).
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.
Instead of listening for document updates sent from `sourcekitd` and sending a `PublishDiagnosticsNotification` based on the `sourcekitd` notification, wait for a little while and then execute an internal `DocumentDiagnosticsRequest` to load diagnostics and send them to the client.
This has two advantages:
- It unifies the two diagnostic implementations
- It removes the need to keep track of semantic diagnostics in `SwiftLanguageServer`
- It gets us one step closed to opening and editing documents in `syntactic_only` mode. The only thing that is left now are semantic tokens.
Instead of just having barriers and non-barriers, this allows `AsyncQueue` to track dependencies between tasks at a more fine-grained level.
For example, we can now specify that requests that affect one document only depend on edits to that same document and are not blocked by edits to any other document. As a consequence, a busy `sourcekitd` will not block requests from `clangd` to be executed and vice versa.
Resolves#875
rdar://116705652
Each `sourcekitd` uses a single, global code completion session but we were managing code completion sessions on the `SwiftLanguageServer` level. This had two issues:
- Code completion is considered non-blocking on `SourceKitServer` and thus we could execute two concurrent code completion requests, which would conflict with each other.
- You could have multiple `SwiftLanguageServer`s that each have a connection to `sourcekitd` but share the same `sourcekitd` state. This shouldn't happen in the real world but does happen if we create multiple `SourceKitServer` instances in tests.
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.
Storing the semantic tokens inside `Document` was an anti-pattern because the semantic tokens only applied to Swift and were also being updated while the document contents themselves stayed constant.
Instead, we should store the semantic tokens in a separate `SemanticTokensManager` that only exists in the `SwiftLanguageServer` and has the sole responsibility of tracking semantic tokens.
This allows us to use Swift concurrency to await the computation of the SwiftSyntax tree for a given document instead of having to poll for its creation.
