Add "Go to Interfaces" counterpart of "Go to Implementations"

[adonovan]

Background: The "Go to Implementations" feature of VS Code, which corresponds to the textDocument/implementation LSP request, is defined to return all the concrete implementations of a given interface or abstract type. In other words, the query is inherently "downwards" with respect to the type hierarchy.

The corresponding "upwards" query is equally useful. In some LSP servers, such as gopls for Go, the behavior of this feature depends on the concreteness of the queried type. If it's an interface, the response includes types that may be assigned to it: concrete and interface types with equal or greater methods sets. If it's a concrete type, the response includes only interfaces to which the queried type may be assigned. This unfortunately leaves the user with no way to ask the question "what are the superinterfaces of this interface?", or, in Java terms, "what are the superclasses of this abstract class"? In Java there is at least the option to traverse the implements relation, which is explicitly declared, but in Go there is no syntactic relationship between implements-related types, making tooling even more important.

Proposal: we propose to add a corresponding "Go to Interfaces" (or perhaps "supertypes") feature to VS Code that would make a similar textDocument/implementation query with opposite directionality. At the LSP protocol level, this would be indicated by an optional upwards boolean in the textDocument/implementation request indicating that the direction of the query is reversed from the usual downwards behavior represented by null or false.

[HighCommander4]

This unfortunately leaves the user with no way to ask the question "what are the superinterfaces of this interface?", or, in Java terms, "what are the superclasses of this abstract class"?

Does type hierarchy not serve this purpose?

[adonovan]

This unfortunately leaves the user with no way to ask the question "what are the superinterfaces of this interface?", or, in Java terms, "what are the superclasses of this abstract class"?

Does type hierarchy not serve this purpose?

Good point. Gopls doesn't implement that operation, but perhaps it should.

Nonetheless, it wouldn't really undermine the motivation for this feature. For the same reasons VS Code has distinct operations for "Go to definition" and "Go to References" with keybindings for rapid navigation, similar control would be beneficial for quickly navigating types.

[dbaeumer]

I agree with @HighCommander4 that the upwards direction should be handled by a type hierarchy request. @adonovan can you give that a try and see how it goes.

[16bit-ykiko]

Provide additional information. For clangd(C++), you can click the override or final keyword to go to interface of the method.

For example:

struct A {
    virtual void foo() = 0;
};

struct B : A {
    void foo() override {}
};

struct C : A {
    void foo() final {}
};

If trigger go to definition at the location of override and final, The cursor will jump to A::foo.

[adonovan]

@dbaeumer I agree with @HighCommander4 that the upwards direction should be handled by a type hierarchy request. @adonovan can you give that a try and see how it goes.

Not easily, because gopls doesn't implement Type Hierarchy. Unlike every other conceivable feature, no one seems to have requested it yet, oddly; and it is unfortunately not trivial to implement because it requires some subtle changes to our filesystem-based workspace index.

But why the asymmetry? Why should a downward query from an interface have its own command, but not an upward query from a concrete type--necessitating such hacks as inferring the direction of the query from the concreteness of the initial type, as gopls does, or from the adjacent override or final token, as clangd does?