At the bottom of the README in the SourceKit-LSP repo there is a list of features that are supported. These are general features and don't always have a one to one correspondence with the LSP spec. Is there a list anywhere that includes the support available based on the specification messages
eg
completion: ✓
completionResolve: ✓
hover: ✓
signatureHelp: 
declaration: ✓
etc
Not currently, but it would be reasonable to add if you were so inclined.
The reason I ask is because I am working on the new SSWG Swift VSCode extension and I'm wondering what extra information I can extract from the LSP server on top of doing your standard name completion. I'm fairly new to LSP so I am firing various requests at the server just to see what I get back. Sometimes I have success, sometimes I don't. I don't know if this is because I am sending rubbish or the message is not supported.
One thing I was looking at was seeing if I could do test discovery using the DocumentSymbolRequest. I can get a list of classes and member functions for a file from it. The only piece of information I can't get is whether a class inherits from XCTestCase. Is this something that is doable?
I've only just started on this so be prepared over the next few weeks for a barrel load of questions.
1 Like
If you're doing this in code, you could use the "server capabilities" to see what requests we support. It may even depend on language in cases where clangd supports something but we don't have swift support, or vice-versa.
From a quick scan, we implement all the LSP requests listed under "language features" in the 3.16 spec with the following exceptions:
- completionItem/resolve though there is a PR
- textDocument/signatureHelp
- textDocument/declaration
- textDocument/typeDefinition
- textDocument/codeLens, codeLens/*
- textDocument/documentLink, documentLink/resolve
- textDocument/*formatting
- textDocument/rename, textDocument/prepareRename
- textDocument/prepareCallHierachy, callHierarchy/*
- textDocument/linkedEditingRange
- textDocument/moniker
Also keep in mind that many requests implicitly depend on having a build of the package in order to read imported modules, and/or to populate the index.
LSP doesn't currently model class hierarchy in any of its requests, so this would require an extension. There is a proposal to add "type hierarchy" to LSP.
I'm not aware of any work on extending LSP to support test discovery more directly, but that is another alternative. We already have data about unit tests in our source code index, but it's not exposed anywhere in the API. The same index data is used by SwiftPM to power its own test discovery on Linux. The tradeoff here is that it requires the index to be up to date (currently this means it requires a build). You could also combine the index data with syntactic information to get faster (but less accurate) updates to the set of tests until the index is brought up to date.
Another approach would be to get the list of tests from swiftpm's swift test --list-tests (also requires a build). You could then map that back to source locations using the data from documentSymbol.
Thanks for all the info. I was hoping I could avoid needing to run swift test --list-tests. I guess we could use the results from it along with the DocumentSymbolRequest on file save to keep an up to date list.