- Remove the JSONRPC connection kind between `TestSourceKitServer` and `SourceKitServer`
- It wasn’t actually used and the connection abstraction just made things more complicated than they needed to be
- Send requests and notifications to `SourceKitServer` by directly calling into `SourceKitServer.handle` instead of going through a `Connection`. This makes the code a lot easier to understand statically
- Make `TestSourceKitServer` conform to `MessageHandler` instead of going through `TestClient`
- IMO this centralizes all the handling and makes it a lot easier to follow. `TestClient` didn’t do a whole bunch anyway.
- Allow async awaiting of next notifications instead of having to register a `handleNextNotification` handler before expecting the notification to be emitted.
- This allows us to remove quite a few `XCTExpectation`s in test cases
- Change `sendSync` function that sends a request and returns the result to be `async`
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.
Unfortuantely, we have a few potential out-of-order exeuction possibilities while we migrate everything else to also be asyncronous. But those should be low-probability issues that we can fix in follow-up commits, so I think it’s fine for now. All of these places are marked with `FIXME: (async)`
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`.
Unfortuantely, we have a few potential out-of-order exeuction possibilities while we migrate everything else to also be asyncronous. But those should be low-probability issues that we can fix in follow-up commits, so I think it’s fine for now. All of these places are marked with `FIXME: (async)`
I noticed that the initial package loading can take ~5s. It’s good behavior to inform the client that sourcekit-lsp is busy reloading the package, showing the user that semantic functionality might not be ready yet.
https://github.com/apple/sourcekit-lsp/issues/620
rdar://111917300
This replaces many instances of `fatalError` with `XCTFail`. Although
these code paths should not come to pass, there are currently failures
in the test suite on Windows where these trigger. By using `XCTFail`
instead, we allow the tests to continue execution which is helpful for
investigating the current state and make progress towards fixing the
issues.
Instead of having ad-hoc timeout durations in all the test cases, specify a default timeout duration that can be used by tests.
This allows us increase the timeout duration for all tests if we discover that e.g. sourcekitd is slower in CI setups.
rdar://91615376
#481 replaced SourceKit placeholders (like `<#code#>`) by LSP snippets for code actions, which are used to represent SourceKit refactoring and diagnostic Fix-Its. But LSP snippets are only supported for code completion, not for code actions. This results in LSP snippets like ${1:code} being inserted into the editor.
Instead of replacing SourceKit placeholders by LSP placeholders, we should just remove them altogether from the code action response.
rdar://92447079 [#488]
This actually addresses the real issue that was ignored earlier about
pipes on Windows. The FileHandle cannot provide a non-owning file
descriptor (the returned file descriptor would need to be explicitly
`_close`'d by the receiver). Foundation now vends a `_handle` accessor
to the OS primitive handle. Use this to create the dispatch loop for
messaging. We now create the JSONRPCConnection from handles on Windows
which actually should help enable running some of the tests on Windows
as well.
We will be able to split the LSP modules off later. These LSP modules
will provide the ability to write custom LSP servers and clients in
Swift. The sourcekit-lsp repository will build on top of this new
package to provide an LSP implementation that creates a language server
for Swift and C-based-languages.
