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`.
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.
Remove `settings(for:)` from the BuildSystem API in favor of the change callback
- With the `settings(for:)` method removed, we instead block on a
callback from the `BuildSystemManager` which itself handles
the primary build system callback in conjunction with the fallback
system
- We queue up notifications / requests that reference documents
until we receive the callback.
- Remove language from FileBuildSettings as it is no longer needed,
Swift-specific working dir fixes are now in SwiftCompileCommand
- registerForChangeNotifications should inform its delegate
asynchronously instead of immediately
When testing the sourcekit-lsp binary, it is handy to be able to force
requests to be handled synchronously. This only affects the protocol
layer, not the implementation. This option is hidden from the help text
and should only be used for testing/debugging.
