You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add "Go to Interfaces" counterpart of "Go to Implementations" #2037
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.
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"?
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"?
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.
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?
Activity
HighCommander4 commentedon Oct 11, 2024
Does type hierarchy not serve this purpose?
adonovan commentedon Oct 11, 2024
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 commentedon Oct 15, 2024
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.
16bit-ykiko commentedon Oct 17, 2024
Provide additional information. For clangd(C++), you can click the
overrideorfinalkeyword to go to interface of the method.For example:
If trigger
go to definitionat the location ofoverrideandfinal, The cursor will jump toA::foo.adonovan commentedon Oct 22, 2024
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
overrideorfinaltoken, as clangd does?gopls/internal/golang: implementation: report iface/iface relations