go/types, types2: monomorphization check is too conservative for method declarations

[JasonMing]

Go version

go version go1.27rc1 darwin/arm64

Output of go env in your module/workspace:

AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE='on'
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN='/Users/xxx/go/bin'
GOCACHE='/Users/xxx/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/xxx/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/hd/kktxntgs1fbf1k91l62nfb6m0000gn/T/go-build682996315=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/xxx/example/go.mod'
GOMODCACHE='/Users/xxx/go/pkg/mod'
GOOS='darwin'
GOPACKAGESDRIVER=''
GOPATH='/Users/xxx/go'
GOROOT='/Users/xxx/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.27rc1.darwin-arm64'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/xxx/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/xxx/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.27rc1.darwin-arm64/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.27rc1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I tried to compile this minimal program:

example_test.go

package p

type A[T any]struct{}

func (a A[T]) M() A[[]T] {
	panic("TODO")
}

func F[T any](a A[T]) A[[]T] {
	panic("TODO")
}

func TestFoo(t *testing.T) {
	A[string]{}.M() // Bad
	F(A[string]{})  // OK
}

Run:

go test ./...

The top-level function F compiles if the method M is removed.
The failure only appears when the same return type is used as the result of the generic method.

What did you see happen?

./example_test.go:7:8: instantiation cycle:
	./example_test.go:9:21: T instantiated as []T

What did you expect to see?

I expected the method to compile, or for the restriction to be documented as an intentional limitation of generic methods.

The method result type appears finite and statically knowable, and the equivalent top-level generic function compiles.
From the accepted generic methods proposal, concrete generic method calls are statically resolved, so this looks like the monomorphization cycle check may be treating the receiver type parameter as recursively instantiated when it appears inside the result type.

If this is an intended restriction, it would help to document why a generic method cannot return the receiver generic type instantiated with a type derived from the receiver type parameter, while an equivalent top-level generic function can.

Relevant background links:

• spec: generic methods for Go #77273
• cmd/compile: endless compilation for code that cannot be monomorphised #48018

[gabyhelp]

Related Issues

• cmd/compile: generic method returning parameterized self-type causes "instantiation cycle" when return type wraps receiver type parameter #80109 (closed)
• cmd/compile: instantiation cycle in closure function created by method of generic type #50215 (closed)
• cmd/compile: instantiation cycle error in method #65366 (closed)
• cmd/compile: compiler failing for generic code #50841 (closed)
• cmd/compile: recursive generic interface instantiation error #65362 (closed)
• cmd/compile: infer generic type based on the function return type #54791 (closed)
• go/types, types2: bad error message for cycles through type instantiation #74725
• cmd/compile: cannot use generic type alias as method receiver #77249
• cmd/compile: stenciling fails due to confusion with underlying type through generic function call's call of a method on a generic function #54552 (closed)
• go/types, cmd/compile: panic hashing a generic instantiation whose type argument is a recursive alias, with split declarations #80150 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[dr2chase]

Tentatively a release blocker till we know more.

[mrkfrmn]

Thanks for reporting. To be clear, there are no generic methods in the example above — M does not declare its own type parameters and is hence an ordinary method on a generic type. We can even put this example into the Go 1.26 playground (which does not syntactically support generic methods) and get the same result. In other words, I don't think this has much to do with Go 1.27. Please correct me if I have misinterpreted you.

I think these cases are a bit different. To illustrate, we can walk through some examples.

Let's focus on a function instantiation:

package main

type A[P any] struct{}

func f[P any]() A[*P] {
	panic(42)
}

func main() {
	f[int]()
}

Which we can monomorphize by hand. A similar program using declared types could be:

package main

type A1 struct {}

func f1() A1 {
	panic(42)
}

func main() {
	f1()
}

Let's now focus on the method instantiation:

package main

type A[P any] struct{}

func (A[P]) m() A[*P] {
	panic(42)
}

func main() {
	A[int]{}.m()
}

Which we cannot monomorphize by hand. A similar program using declared types could be:

package main

type A1 struct{}

func (A1) m() A2 {
	panic(42)
}

type A2 struct {}

func (A2) m() A3 {
	panic(42)
}

// ...and so on infinitely

func main() {
	A1{}.m()
}