cmd/compile: stenciling fails due to confusion with underlying type through generic function call's call of a method on a generic function

[dfinkel]

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

% go version
go version go1.19 linux/amd64

Also with the tip of the go master branch with GOEXPERIMENT=nounified

% gotip version
go version devel go1.20-7dad1d24b2 Fri Aug 19 16:55:03 2022 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yep, go 1.19 fails unified IR was enabled by default on 2022/08/18 (https://go.dev/cl/422235).

Bisected the compile failure to http://go.dev/cl/385274 (which looks like it might have uncovered an existing bug more than introduced it)

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

go env Output

% go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/david/.cache/go-build"
GOENV="/home/david/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/david/vimeo/go/pkg/mod"
GONOPROXY="github.vimeows.com,go.vimeocloud.com"
GONOSUMDB="github.vimeows.com,go.vimeocloud.com"
GOOS="linux"
GOPATH="/home/david/vimeo/go"
GOPRIVATE="github.vimeows.com,go.vimeocloud.com"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="/usr/bin/gccgo"
GOAMD64="v3"
AR="ar"
CC="x86_64-pc-linux-gnu-gcc"
CXX="x86_64-pc-linux-gnu-g++"
CGO_ENABLED="1"
GOMOD="/home/david/vimeo/go/src/github.vimeows.com/video/starlord/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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3682746773=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I wrote a few interdependent generic types and called a method on one of them from a generic function.

https://go.dev/play/p/FMw2FMd091n

example code

package main

type compKey string

func (s compKey) less(o compKey) bool { return s < o }

type lesser[T comparable] interface {
	comparable
	less(T) bool
}

type lessSet[T lesser[T]] struct{}

func (s lessSet[T]) valLess(a, b T) bool {
	// This call seems to force-method-expression generation
	return a.less(b)
}

type doer[KSB any, KV comparable] struct{}

func (r *doer[KSB, KV]) Do() {}

func doSomething[KT lesser[KT]](keys lessSet[KT]) {
	iter := doer[lessSet[KT], KT]{}
	iter.Do()
}

func main() {

	ks := lessSet[compKey]{}

	doSomething(ks)
}

What did you expect to see?

The code compiles without killing the compiler and exits with status-code 0.

What did you see instead?

With a release version of go 1.19:

% go build .
# foo.spin-2.net/fizzle
./main.go:25:9: internal compiler error: method less on string not found

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new

With gotip built from

% GOEXPERIMENT=nounified gotip build .
# foo.spin-2.net/fizzle
./main.go:25:9: internal compiler error: method less on string not found

goroutine 1 [running]:
runtime/debug.Stack()
        /home/david/sdk/gotip/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0xa6020?, 0xc0?}, {0xd6e1d7, 0x19}, {0xc0000d75b8, 0x2, 0x2})
        /home/david/sdk/gotip/src/cmd/compile/internal/base/print.go:227 +0x1d7
cmd/compile/internal/base.Fatalf(...)
        /home/david/sdk/gotip/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/noder.(*genInst).finalizeSyms(0x140ad40)
        /home/david/sdk/gotip/src/cmd/compile/internal/noder/stencil.go:1861 +0xac5
cmd/compile/internal/noder.(*genInst).buildInstantiations(0x140ad40)
        /home/david/sdk/gotip/src/cmd/compile/internal/noder/stencil.go:70 +0xe7
cmd/compile/internal/noder.BuildInstantiations(...)
        /home/david/sdk/gotip/src/cmd/compile/internal/noder/stencil.go:44
cmd/compile/internal/noder.(*irgen).generate(0xc0000e6000, {0xc000064bb0, 0x2, 0x144da20?})
        /home/david/sdk/gotip/src/cmd/compile/internal/noder/irgen.go:332 +0x445
cmd/compile/internal/noder.check2({0xc000064bb0, 0x2, 0x2})
        /home/david/sdk/gotip/src/cmd/compile/internal/noder/irgen.go:87 +0x14d
cmd/compile/internal/noder.LoadPackage({0xc000022220, 0x2, 0x2})
        /home/david/sdk/gotip/src/cmd/compile/internal/noder/noder.go:82 +0x48f
cmd/compile/internal/gc.Main(0xd8e468)
        /home/david/sdk/gotip/src/cmd/compile/internal/gc/main.go:184 +0xbbd
main.main()
        /home/david/sdk/gotip/src/cmd/compile/main.go:57 +0xdd

(feel free to retitle, I haven't spent enough time digging into the noder implementation to understand the source of the bug)

[cuonglm]

Duplicated of #54225

Your code is compiled now on tip, with Unified IR enabled by default.

[dfinkel]

Thank you. This does appear to be a dup of #54225 (I must not have looked far enough back when checking for open bugs)

Indeed, I did have to disable Unified IR to repro on tip. (and similarly switching to unified IR in go 1.19 does compile successfully as well)

[dfinkel]

Duplicate of #54225