I'm Fredrik, a CS student from Northern Germany at the University of Kiel and am currently in my final year of my bachelor studies.
I have worked on side projects in a variety of languages, including Swift and Rust, and on language servers (Kotlin, Curry, Koka) and would be very interested in exploring ideas on how to improve SourceKit-LSP, specifically with regard to the mentioned inline type hints. Using SourceKit-LSP on Linux has been a very enjoyable experience and I would love to help making it better.
Specifically, I could imagine
Integrating inline hints in a variety of places, including variable bindings, closure parameters and call chains, similar to rust-analyzer
Providing code lenses or quick fixes for applying these type hints
Exploring similar features, like evaluation code lenses (as demonstrated by the Haskell language server)
Any thoughts on this? Which areas would you suggest to look into as part of a potential GSoC project?
that’s quite some experience, you’ve got with LSP already. I’m impressed.
Regarding code lenses: What kind of quick actions are you thinking about? We already have support for the fix-its provided by the compiler. Are you suggesting Quick Fixes to commit the types provided by the inline type hints to the source code?
The evaluation code lenses in Haskell look really exciting to me – I hadn’t seen that feature before. I think that in conjunction with the inline type hints it’s a little bit too much work for the duration of GSoC though (unless you think otherwise). But as a separate project, I think it would be great.
For 2021 there is increased flexibility in the planning for the milestones - students have 10 weeks to complete their 175 hour project. This opens it up for the student and mentor to decide together how they want to break up the project. Some folks may choose to stick to a 17-18 hour a week schedule with their students, others may factor in a couple of breaks during the program (for student and mentor) and some may have students focus 30 hours a week on their project so they wrap up in 6 weeks. […]
On an organizational note: If you are unsure whether to submit a proposal for the code evaluation code lenses or for the inline type hints, I would encourage you to submit both.
Any resources you would suggest looking into to better understand how the compiler interfaces with the language server? Would a feature like inline type hints require changes on the SourceKit side too or does it already provide all of the necessary information (e.g. for other LSP features like Hover)?
I haven’t looked into it in too much detail yet, but I don’t think changes to sourcekitd will be necessary.
SourceKit-LSP's hover request (for Swift) is implemented here and uses an internal CursorInfo request to to sourcekitd (to which it communicates using XPC, implemented here). I just checked and the cursor info request should also return the type, which we can display in the editor.
I hope, this gives you a place to start. If you would like more information, please let me know.
Another to consider is CollectExpressionType (example use via sourcekitd-test) which gives types for all expressions in bulk, while CursorInfo only handles identifiers.