Add protocol conformance and super class details to DocumentSymbol for types

[adam-fowler]

The LSP DocumentSymbol interface includes a details field. Currently SourceKit-LSP leaves this field empty.

For classes, struct and actors would it be possible to include the protocol conformances and super class in this field e.g. MyClass: SuperClass, MyStruct: Sendable, Equatable etc

[ahoppen]

Tracked in Apple’s issue tracker as rdar://123752547

[ahoppen]

It would definitely possible. Do you think it would be useful though? I would think that it produces more noise than value.

[adam-fowler]

It would be useful for me to recognise XCTestCase classes. So I can add test items for new test classes as they are written (and not wait for a compilation). Currently the test update between builds can only add methods to existing test classes.

Also it would be interesting to see how providing them affects the file outline view.

[ahoppen]

I was mostly thinking about the outline view where I think it would just add noise.

For the test explorer, I think we should be relying on workspace/tests and textDocument/tests requests instead of the document symbols request. I’m not entirely sure what you’re doing right now (looking forward to the PR that starts using workspace/tests and textDocument/tests) but if we use workspace/tests and textDocument/tests, the test discovery would be agnostic of XCTest and could also works with swift-testing.

[adam-fowler]

My main concern with relying on workspace/tests and textDocument/tests is they require a build.
By the way the PR for workspace/tests has been merged into main. If you are able to build the extension you can see it working.

[ahoppen]

Oh, I didn’t think about the fact that textDocument/tests uses the index but that you currently want it to be up-to-date even without rebuilding the file.

What I would prefer is that I change textDocument/tests to use the index if it is up-to-date and if it is not, do a syntactic scan in sourcekit-lsp. That way you wouldn’t need to do scraping in the extension. With that in mind: What are the information that you would need? We can structure the textDocument/tests request however we like. Could be something that’s more akin to textDocument/documentSymbol with nested symbols or a flat list like we have right now.

[adam-fowler]

If I had a textDocument/tests request that used a syntactic scan then I could do a request on document save and I wouldn't need to parse the textDocument/documentSymbol response. A flat list would be fine.