cmd/go: go vet reports error: `impossible type assertion: no type can implement both... for generic interface`

[thomascoquet]

What version of Go are you using (go version)?

1.18beta1

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/thomascoquet/.cache/go-build"
GOENV="/home/thomascoquet/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/thomascoquet/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/thomascoquet/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/thomascoquet/sdk/go1.18beta1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/thomascoquet/sdk/go1.18beta1/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18beta1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/thomascoquet/Work/gobug/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build724234361=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I am using a generic interface the following way:

package gogenerics

import "fmt"

type Float interface {
	float32 | float64
}

type Doer[T Float] interface {
	Do() T
}

func Specialize[T Float](v Doer[T]) {
	switch v.(type) {
	case Doer[float32]:
		fmt.Println("float32!")
	case Doer[float64]:
		fmt.Println("float64!")
	}
}

What did you expect to see?

No error message.

What did you see instead?

When building or using go test ./..., I have the following message:

impossible type assertion: no type can implement both gogenerics.Doer[T] and gogenerics.Doer[float32] (conflicting types for Do method)

The error message also appears in VSCode (with the syntax highlighter using gopls with generics enabled).

I must emphasize that this code works perfectly well if imported from other modules ; the only isssue is when using the module "from itself".

[ianlancetaylor]

CC @griesemer @findleyr

I agree that it doesn't seem like this code should have an error.

[griesemer]

I can only reproduce this with go vet. The compilers and type checkers don't have a problem with this code. Temporary work-around: to run (any) tests, you can use go test -vet=off ./... .

[griesemer]

cc: @findleyr

[findleyr]

Yes, this looks like a problem with x/tools/go/analysis/passes/ifaceassert.

Thank you for filing. We will investigate.

[timothy-king]

I can confirm that I can reproduce with gotip test ./... at head (go1.18-50869f377fd).

ATM ifaceassert is essentially just delegating the decision for whether in a cast from V to U if V is an implementation of U to (go/types).MissingMethod. Here V is example.com/m.Doer[T] and U is example.com/m.Doer[float64]. Either this MissingMethod needs to be extended or we need to modify the detection logic in ifaceassert.

In this context, I think what we want to know is whether there does not exist a type instantiations s.t. V is an implementation of U. @griesemer and @findleyr how feasible is this to check?

Here is an example to showcase that we care about both potentially being type parameters.

func Specialize2[T Float, U Float](v Doer[T]) {
	switch v.(type) {
	case Doer[U]:
		fmt.Println("same!")
	}
}

A quick-n-dirty solution is to not check interfaces that contain any type parameters in ifaceassert. Thoughts?

Code: https://cs.opensource.google/go/x/tools/+/refs/tags/v0.1.8:go/analysis/passes/ifaceassert/ifaceassert.go;l=54