Skip to content

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

Open

Description

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.

Activity

  1. HighCommander4 commented on Oct 11, 2024

    @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?

  2. adonovan commented on Oct 11, 2024

    @adonovan
    Author

    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.

  3. dbaeumer commented on Oct 15, 2024

    @dbaeumer
    Member

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

  4. 16bit-ykiko commented on Oct 17, 2024

    @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.

  5. adonovan commented on Oct 22, 2024

    @adonovan
    Author

    Dirk Bäumer (@dbaeumer) I agree with Nathan Ridge (@HighCommander4) that the upwards direction should be handled by a type hierarchy request. Alan Donovan (@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions