Add Implementations CodeLens Support

[Tabonx]

Description

It would be great if SourceKit-LSP could support showing the number of implementations as a CodeLens above protocols and methods. This feature would improve navigation and code understanding.

[ahoppen]

Just to clarify: What do you mean by Implementations here? Function implementations that satisfy a protocol requirement?

[Tabonx]

Yes, I think so. Maybe the right word would be conformances in Swift.

For example, when I have:

protocol Greetable {
    func greet(_ name: String)
}

struct Person: Greetable {
    func greet(_ name: String) {
        print("hello: \(name)")
    }
}

The LSP would show references (I’m not sure what the exact term is) for the protocol and its methods/variables:

// 1 Conformance (Person)
protocol Greetable {
    // 1 Conformance / implementation (Person.greet)
    func greet(_ name: String)
}

struct Person: Greetable {
    func greet(_ name: String) {
        print("hello: \(name)")
    }
}

[ahoppen]

We should have the information about this in the index (the overrideOf relationship). I’ve never really worked with code lenses much and there isn’t really any documentation in the LSP spec what they are intended for. Do you know if other LSP servers use code lenses for functionality like that?

[Tabonx]

C# LSP has this feature. It looks like this

[ahoppen]

Interesting. What happens if you click on the code lens? 11 references sounds more like there are 11 places where this is called instead of how many functions override/implement this.

[Tabonx]

Sorry, I just realized it’s not from the C# LSP, but from Rider, which is what I had in mind. When you click on it, it basically opens the same list as "Go to References" or "Go to Implementations"

[ahoppen]

If you want to see references, you can invoke it from the context menu or your editor’s equivalent. I don’t see a lot of value in taking up valuable screen space to give you shortcuts to add buttons for these. What do you think?

[Tabonx]

I personally don't use this, but I really don't see why it shouldn't be an option for people who do. VS Code has a global setting that can disable all code lenses (editor.codeLens), which users can toggle depending on whether they want to use this feature.

This is what is in the LSP spec:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeLens

A code lens represents a command that should be shown along with source text, like the number of references, a way to run tests, etc.

However, I could not find any way for the client to tell the server which code lenses it wants to show. For example, if there are two lenses, one for implementations and one for references, the user has no way, according to the LSP spec, to disable just one of them. Other LSPs seem to work around this by using InitializeParams.initializationOptions to pass configuration to the server about which code lenses to use, among other things.

Rust Analyzer has a detailed section about what it supports passing to initializationOptions:
https://rust-analyzer.github.io/book/configuration

[rintaro]

I like CodeLens. It's useful for getting an overview of which functions are used a lot (or not).