For non-Swift symbols, we need to perform an index lookup because the best local declaration will point to a header file but jump-to-definition should prefer the implementation (there's the declaration request to jump to the function's declaration).
rdar://119243893
`extractIndexedOccurences` mostly dealt with how to create a fallback value and we didn’t support fallback values in 3/4 cases. Remove it, simplifying the callers of `extractIndexedOccurances` along the way.
Previously, we would sometimes log errors for example for the `setTrace` notification sent by VS Code. To avoid those logs, add cases for all known requests and notifications to the `TaskMetadata` initializers.
Since asyncifying all the request handling, `Request` only had a few lingering uses. Remove most of them and shrink it down to a type that only contains the request’s parameters and the reply block of the corresponding type.
And while we’re doing this, also move `NotificationType.forLogging` out of the `LanguageServerProtocol` module to remove the dependency from `LanguageServerProtocol` on `LSPLogging`.
Resolves#881Resolves#936
rdar://116705662
rdar://117562587
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
We could get into a race condition in `testAddFile` where the `DidChangeWatchedFilesNotification` would get handled after we try getting completion results that rely on it.
In a real-world use case, this is OK. Completion might still be incorrect until `DidChangeWatchedFilesNotification` gets handled but it will catch up eventually - usually earlier than later because in real-world scenarios the `DidChangeWatchedFilesNotification` and completion request are more than a few milliseconds apart.
In test, however, we need to guarantee deterministic ordering. Introduce a `BarrierRequest` that has `TaskMetadata.globalConfigurationChange` and thus ensures that all notifications and requests before it have finished before returning. We can run this fake request after sending the `DidChangeWatchedFilesNotification` to make sure that it is handled.
An alternative would be to mark `DidChangeWatchedFilesNotification` as `TaskMetadata.globalConfigurationChange`. But I would really like to avoid introducing a global ordering barrier between requests for a notification that is, for example, sent whenever a `.swift` file in the `.build` directory changes (e.g. on every package update).
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
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
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.
