-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Closed
Labels
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.gopls/genericsIssues related to gopls' support for genericsIssues related to gopls' support for generics
Milestone
Description
Even some of the most basic scenarios of 'implementations' are not working at all with generics, for example when the concrete and interface types are both generalized over [T any]
and are defined within the same file:
xtools$ cat d/d.go
package d
type Collection[T any] interface {
Push(T) error
Pop() (*T, bool)
}
type C[T any] struct{}
func (C[T]) Push(t T) error { return nil }
func (C[T]) Pop() (*T, bool) {
var t T
return &t, true
}
var _ Collection[int] = C[int]{}
xtools$ go run ./gopls implementation ./d/d.go:#120 # within "Push" concrete method identifier
xtools$
This is not a recent regression:
xtools$ ./gopls-v0.11.0 implementation ./d/d.go:#120
xtools$
A similar lack of results is obtained by querying the Push
abstract method, or the Collection interface, or the C concrete type.
(This test case was a further reduction of the one described in https://youtrack.jetbrains.com/issue/GO-12702/Go-to-Declaration-Implementation-not-available-for-generics-interfaces, referenced by golang/vscode-go#2711.)
Sortren, ravsii and ganezh
Metadata
Metadata
Assignees
Labels
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.gopls/genericsIssues related to gopls' support for genericsIssues related to gopls' support for generics