Showing the list of active requests didn’t turn out to be very useful for debugging. What is more useful, however, is to visualize the requests as the get enqueued and handled in a trace chart. This gives a very intuitive view of which request is blocking another request from getting executed.
Change a l public declarations to the `package` access level, accept for:
- The `LanguageServerProtocol` module
- The `BuildServerProtocol` module
- `InProcessClient.InProcessSourceKitLSPClient`
- `LanguageServerProtocolJSONRPC` (I would like to create a more ergonomic API for this like `InProcessSourceKitLSPClient` in the future, but for now, we’ll leave it public)
Unfortunately, our pattern of marking functions as `@_spi(Testing) public` no longer works with the `package` access level because declarations at the `package` access level cannot be marked as SPI. I have decided to just mark these functions as `package`. Alternatives would be:
- Add an underscore to these functions, like we did for functions exposed for testing before the introduction of `SPI`
- Use `@testable` import in the test targets and mark the methods as `internal`
Resolves#1315
rdar://128295618
We have a few subcommands on sourcekit-lsp that are intended for debugging sourcekit-lsp and that are thus hidden. This moves them all to a `debug` subcommand (eg. `sourcekit-lsp debug run-sourcekitd-request`) and unhides them. That makes them more discoverable for interested users and also helps developers of sourcekit-lsp remember what they are called.
rdar://128443298
