Development plan for the remaining LSP features

Hello everyone!

Today, I was studying the LSP's specification of the SourceKit-LSP's currently missing features - specifically refactoring and formatting-related requests, as I'm interested in being able to contribute to the development of these features. For that, I took a look at how Xcode/sourcekitd currently deals with them and traced a mental plan.

However, I was concerned that simply hooking sourcekitd requests might not be the way that the Swift team visualized SourceKit-LSP, specially since tools like SwiftSyntax are becoming more powerful as time goes by - with earlier mentions that the LSP might use it as well in the future.

This feeling prompted the creation of this thread, so I wanted to ask: Are there any public plans on how to approach the development of the LSP's remaining features in this current stage of development? Should we keep it simple with sourcekitd or should we already work towards integration with the other Swift tools, when applicable?

1 Like

For refactoring, I think it would be best to expose the existing sourcekitd functionality for local refactoring. Swift-syntax does not have a semantic model yet and is unlikely to get one in the immediate future, so most (all?) of the existing refactorings are not implementable in pure Swift anyway. Note that global rename is very different from the other refactorings, and I suggest leaving that one alone for now. My intention is to port our existing implementation and tests when I get to it.

For formatting, sourcekitd only has indentation today and I think it's a dead end to add anything more there. I'd like to see a first-class swift formatter built on top of swift syntax, and we would integrate with that.

If you're looking for something to contribute to that's self-contained, I'd recommend looking at the local refactorings.

Nothing yet, but I'd like to write something up. Just haven't had time yet.

"It depends" :laughing:

Thanks for all this info Ben! I have a newbie question:

Is the reason to leave it alone because global renaming depends on the progress of background indexing / the index database?

Not specifically. The design is a complicated in order to support the live renaming that Xcode does, and it would be hard to get it all right without that context. I have the advantage of having already implemented it, that’s all.