cmd/compile: //go:build file version ignored when calling generic fn which has related type params (reproduces with 1.21 and 1.20, not at tip)

[corhere]

Go version

go version go1.21.5 darwin/amd64

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

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/Users/corysnider/Library/Caches/go-build'
GOENV='/Users/corysnider/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Volumes/Workspace/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Volumes/Workspace'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/Cellar/go/1.21.5/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/Cellar/go/1.21.5/libexec/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.21.5'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/8p/tzn5bkn967vfgttpr2d2kpjm0000gq/T/go-build2320458225=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

$ cat repro.go
//go:build go1.18

package repro

func genericfn[S ~[]E, E any](s S) S {
	return s
}

func do() []string {
	return genericfn([]string{})
}
$ go tool compile -lang=go1.16 repro.go

What did you expect to see?

Compilation succeeds. It succeeds with go version devel go1.22-b60bf8f8e1 Fri Dec 15 19:35:21 2023 +0000 darwin/amd64.

What did you see instead?

embedding interface element ~[]string requires go1.18 or later (-lang was set to go1.16; check go.mod)

[mdempsky]

This looks like a typechecker issue. My understanding of 804d786's commit message is that this should be valid. (Not sure if there's more permanent documentation describing the expected behavior here; for example, I don't see any mention of the backwards compatibility logic for M >= 21 at https://pkg.go.dev/cmd/go. /cc @rsc)

/cc @griesemer @findleyr

[griesemer]

I cannot reproduce this. With

$ go version
go version go1.22rc1 darwin/amd64

and x.go:

$ cat x.go
//go:build go1.18

package repro

func genericfn[S ~[]E, E any](s S) S {
	return s
}

func do() []string {
	return genericfn([]string{})
}

compilation succeeds:

$ go tool compile -lang=go1.16 x.go
$

To double-check, I added a print statement in the relevant code section, and it does indeed select go1.18 for that file.

Please verify that you are indeed using a new compiler version.
I'm going to close this for now. Feel free to re-open if you have additional evidence, thanks.

[corhere]

@griesemer I know that Go 1.22 is not affected. I said as much in the issue report. The issue is reproducible on Go 1.21.5.

[griesemer]

@corhere Ah. Apologies for not reading more carefully.

Hm, the relevant code didn't exist for 1.21.5 I believe. Not sure if we can easily/should backport.

Reopening, to determine next steps.

[griesemer]

Confirming that this issue exists for go1.21.5.
It appears that we don't have correct position information when computing a type set and then the type checker doesn't use the file-specific version information. This is definitely a bug.

Smaller reproducer source code:

//go:build go1.18
package p

func f[S ~[]E, E any](S) {}

func _() {
	f([]string{})
}

[gopherbot]

Change https://go.dev/cl/555275 mentions this issue: [release-branch.go1.21] go/types, types2: don't lose position info of interface embeddings

[dmitshur]

@griesemer This appears to reproduce with Go 1.20.13 as well, is that right?

If so, our backport policy is to support last two Go versions equally (see here). Will the backport CL you've prepared work on release-branch.go1.20 as well? Please see https://go.dev/wiki/MinorReleases for information on the backport process. Specifically, this issue is in the Go1.22 milestone, but you should ask gopherbot to create tracking backport issues, which will then be reviewed. Thanks.

[gopherbot]

Change https://go.dev/cl/555295 mentions this issue: go/types, types2: don't lose position info of interface embeddings

[gopherbot]

Change https://go.dev/cl/555296 mentions this issue: go/types, types2: don't lose position info of interface embeddings

[griesemer]

We will fix this issue in the 1.22 branch (the code is incorrect there as well, though the issue seems to be masked) and then backport.

[griesemer]

@gopherbot Please consider this for backport to 1.21 and 1.20, this causes a compilation failure for code that chooses to select a future Go version in one of its source files.

[gopherbot]

Backport issue(s) opened: #65052 (for 1.20), #65053 (for 1.21).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[gopherbot]

Change https://go.dev/cl/555415 mentions this issue: [release-branch.go1.21] go/types, types2: don't lose position info of interface embeddings

[griesemer]

Forward-compatibility (specifically, the ability to have a go:build line indicate a Go version that is younger than the Go version used in the .mod file) was introduced with Go 1.21.

The fix for this issue does not need to (and cannot) be backported to 1.20.

[griesemer]

This was fixed at tip (1.22).