The changes in #945 changed the dependencies but did not correct them in
the CMakeLists.txt resulting in a broken build. Resynchronise the
dependencies across Package.swift and CMake.
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.
Basically everything will be decoded as ClangWorkspaceSettings, even if it has nothing to
do wit hit, yielding for example:
```
clangd(LanguageServerProtocol.ClangWorkspaceSettings(compilationDatabasePath: nil, compilationDatabaseChanges: nil))
```
This breaks at least my case of using WorkspaceSettingsChange. This patch adds a - maybe bandaid - fix for that.
Furthermore I removed one Test, as it - AFAIU - broke the invariant that none of the attributes
of ClangWorkspaceSettings may be nil.
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
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
