[GSoC 2021] Inline type hints for SourceKit-LSP

Hi @ahoppen,

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?

7 Likes

Hi Frederick,

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.

Viele Grüße (:wink::de:)
– Alex

1 Like

Yes, quick fixes for committing the inferred type were what I meant, which would be similar to what rust-analyzer does.

Thanks for the info, this is the first time I'm applying for GSoC, so I was a bit unsure of what the expected scope of the proposal would be. :slight_smile:

1 Like

Yes, quick fixes for committing the inferred type were what I meant, which would be similar to what rust-analyzer does.

Sounds like a nice bonus to the type annotations.

Thanks for the info, this is the first time I'm applying for GSoC, so I was a bit unsure of what the expected scope of the proposal would be. :slight_smile:

The project is supposed to be ~175 hours, although I couldn’t really find that information anywhere on the Student Guide pages. From What is Google Summer of Code? | Google Summer of Code Guides

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.

That sounds like a good idea, thanks!

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.

1 Like