x/tools/gopls: 'implementations' doesn't work with generics

[adonovan]

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

[linjunhao1997]

I think this is urgently needed

[fangjh13]

I would like to know how the progress is going, it's really needed.

[adonovan]

I would like to know how the progress is going, it's really needed.

No progress, sorry. Haven't even designed the algorithm yet. But let's make it a priority for 0.13.

[ajsqr]

Hello, is a fix for this planned in the upcoming release ?

[Solverj]

I'm also currently googling / gpting / searching, atm I have to make tests on a struct to verify that I've created structs according to generic interface in neovim.

[adonovan]

Hello, is a fix for this planned in the upcoming release ?

Unfortunately no, but likely the following one.

[HarishHary]

Hello any progress on this one?

[adonovan]

Still no progress yet, sorry.

The problem is a little trickier than it may appear because of the design of the index (database) used to radically optimize gopls v0.15. The indexed design means that the problem of testing implements(T, I), where I is an interface, cannot be done by making queries on the type-checker data structures for T and I since we no longer have them. Instead, the problem is mapped onto the domain of sets of strings, each representing a single method, so that the query becomes a string subset test. This works well for non-generic methods, which can each be mapped to a special string called a fingerprint; but we have not yet had time to develop a theory for fingerprinting generic methods, so they would need to fall back to using the type-checker, undoing the benefits of the gopls v0.15 redesign. Of course there are various short-cuts we could apply for common and simple cases, but our current focus is on better support for refactoring, so unfortunately this is not going to happen in the next several months.

[gopherbot]

Change https://go.dev/cl/634197 mentions this issue: gopls/internal/cache/methodsets: support generics in Implementations

[gopherbot]

Change https://go.dev/cl/634597 mentions this issue: internal/typeparams: delete GenericAssignableTo

[gopherbot]

Change https://go.dev/cl/634596 mentions this issue: gopls/internal/golang: Implementations: support generics

[DingYuan0118]

Hello, half year passed. Any progress on this one?

[adonovan]

Yes! Run go install golang.org/x/tools/gopls@master and let us know how this feature works for you.

[DingYuan0118]

Thanks for the quick response.

And I have got a question. I found that the Goland IDE already have a similar func like

Is there any difference between it and gopls?

[DingYuan0118]

reports

/Users/.../go/go1.23.4/bin/go install golang.org/x/tools/gopls@master
go: golang.org/x/tools/gopls@master (in golang.org/x/tools/[email protected]):
        The go.mod file for the module providing named packages contains one or
        more replace directives. It must not contain directives that would cause
        it to be interpreted differently than if it were the main module.

[adonovan]

Is there any difference between it and gopls?

I don't use goland, so I can't answer that question. I am sure the feature is similar in the broad strokes (connecting interfaces with implementations), but it may differ in the details. For example, gopls only reports package-level types from other packages, so a type such as type T struct { io.Reader } appearing with in a function will not be found be a query for implementations of io.Reader. Also, gopls' matching algorithm for generic types and instantiations is not perfectly accurate.

/Users/.../go/go1.23.4/bin/go install golang.org/x/tools/gopls@master ... [errors]

Ah, sorry about that, our go.mod file uses a replace directive so you can't go install direct from master, only tagged releases.

You'll need to git clone https://go.googlesource.com/tools and then cd gopls and go install.

[DingYuan0118]

It works good for this demo.

But our project can not upgrade go version so quickly and still use go1.19. So it is a little painful that I can not use this feature...

[adonovan]

But our project can not upgrade go version so quickly and still use go1.19. So it is a little painful that I can not use this feature...

go1.19? That's very old: gopls v0.15 dropped support for go1.19 last April. You should find a way to upgrade your project.