x/tools/gopls: type constraint discrepancy between go compiler and gopls

[marekscholle]

Working on Go project In VSCode, I noticed gopls reports a problem which is ok for the compiler.

I extracted a minimal example as follows:

Suppose we have a project with packages foo (file foo.go) and bar (file bar.go).

The package foo exports type constraint A:

// foo.go
package foo

type A comparable

The package bar consumes the constraint A as

// bar.go
package bar

// import "foo"

func F[T foo.A](a T, b T) bool {
	return a == b
}

Since the constraint A "inherits" from comparable, the expression a == b is well defined: T is constrained by A which is comparable, hence == is available for values of type T. The compiler is happy with the code.

But VSCode reports a == b as the problem:

invalid operation: a == b (incomparable types in type set)

In editor,

Two observations:

• if the constraint type A comparable is defined in the package bar, it's ok for gopls – it's an cross-package problem
• if the constraint is defined as type A = comparable ie. as typedef (not "newtype") in package foo, it's also ok

[hyangah]

I guess this is an issue in go/types.
The problem is reproducible with gopls built with go1.21rc3 and gopls v0.13.0-pre.2.

cc @findleyr @griesemer @adonovan

[findleyr]

Based on the description, I suspect an issue with export/import.

I will take a look with urgency. It would be good to fix this for v0.13.0.

[findleyr]

Based on the description, I suspect an issue with export/import.

Confirmed. If I turn off export data, the problem goes away.

[findleyr]

So, the problem is that named type forwarding breaks the relationship between the builtin comparable and the underlying of A. That is to say: the resulting type A has an underlying that is the empty interface, with the hidden comparable bit set.

Note that type A interface{comparable} is effectively the same type, but doesn't have this problem, because the comparable bit is encoded as the explicitly embedded comparable type.

Fixing this is a bit tricky, because there is no way to access or set the comparable bit explicitly in the go/types API. The only thing we can do is recognize this specific case by checking for pointer equality between A.Underlying() and types.Universe.Lookup("comparable").Underlying(). Feels a bit dirty, but should work.

This will require careful review, so won't make the v0.13.0 release. Moving to v0.13.1.

[findleyr]

Also meant to say: thanks for the careful issue report! It made tracking this down much easier.

[marekscholle]

Thanks for providing the workaround type A interface{comparable} – it worked for me :)

[marekscholle]

Thanks for providing the workaround type A interface{comparable} – it worked for me :)

[findleyr]

Since this is relatively unlikely, and has a simple workaround, punting to gopls@v0.14.0.