cmd/compile: //go:build file version ignored when using generic function from package "slices" in Go 1.21

[corhere]

Go version

go version go1.21.7 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.7'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/go/src/repro/go.mod'
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 -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build936666295=/tmp/go-build -gno-record-gcc-switches'

What did you do?

https://go.dev/play/p/-yiceeveEDz?v=goprev

Details

//go:build go1.21

package main

import "slices"

func main() {
	_ = slices.Clone([]string{})
}
-- go.mod --
module play.ground

go 1.16

What did you see happen?

Go 1.21:

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

Go build failed.

Go 1.22:

Program exited.

What did you expect to see?

I expect the program to type-check successfully on Go 1.21, same as it does with Go 1.22.

This issue is making it impossible to use packages in non-module repositories which use the slices or maps packages with Go modules as the synthesized go.mod file has an implied language version of go1.16.

• Likely related to 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) #64759

[Jorropo]

Does this has anything to do with slices ?
I mean, in general I don't think we adapt -lang based on build tags and anything trying to use newer language features behind build tags wouldn't work.

That looks like a Go 2 proposal to me.

[zigo101]

The priority of //go:build should be higher than the go directive in go,mod file. So both should compile and run okay.

It is true that this is a "slices" unrelated problem.

[thediveo]

That looks like a Go 2 proposal to me.

Why? I lack the insight, so please help me out.

In any case, I've run into this because of Docker dependencies. What basically happens is that there are always non-mod indirect dependencies. If the Go 1 toolchain breaks than this is a severe issue when not being able to use the existing code.

You can't update the whole world ... or can you?

[mknyszek]

CC @bcmills and @matloob maybe?

[bcmills]

This looks like a cmd/compile issue to me: it's not clear to me whether this is working as designed, but at the very least the error message should be clearer. The user code isn't explicitly embedding the type anywhere.

[bcmills]

Actually, was respecting per-file Go versions a feature itself added in 1.22?

[mknyszek]

CC @golang/compiler

[griesemer]

The error is coming from the type checker. Go 1.21 did introduce the ability to upgrade the language version per file, so I would expect this to work. Investigating.

[griesemer]

Related to #64759 which addressed another aspect of the same problem. In that issue, we had missing position information for embedded elements of interfaces in the same package. In this issue we have missing position information for an imported type.

[griesemer]

Analysis: During type-checking, the method

func (t *Interface) Empty() bool { return t.typeSet().IsAll() }

is invoked which calls Interface.typeSet. That function determines the type set and in order to do so, checks language version compatibility in some cases (here for the implicitly embedded interface element ~[]string). To check the version correctly, we need to know the respective file, and in order to know the file, we need to know the position of the embedding. There's no explicit position provided to the type set computation, and we don't appear to have a (stored) embedding position in this case and then the version check fails in Go 1.21. The same problem exists in Go 1.22, but the version check has changed (Checker.allowVersion) and in fact may have a separate bug (it simply ignores the file information if there's no position), which hides this issue in Go 1.22.

Furthermore, because the type in question here is imported, we don't have position information in the first place for embedded elements. In fact we shouldn't do a version check at all in this case.

[griesemer]

cc: @findleyr for visibility

[gopherbot]

Change https://go.dev/cl/571075 mentions this issue: [release-branch.go1.21] go/types, types2: don't do version checks for embedded types of imported interfaces

[griesemer]

Closing as fixed in the 1.21 branch.

[gopherbot]

Change https://go.dev/cl/571137 mentions this issue: go/types, types2: don't do version checks for embedded types of imported interfaces

[cherrymui]

Reopened. CL reverted. Will re-submit later. Thanks.

[cherrymui]

@gopherbot please backport this to Go 1.21 release. This causes build failure for valid Go code. We'll re-apply CL 571075.

[gopherbot]

Backport issue(s) opened: #66326 (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.

[thanm]

Hi @griesemer what is the status of this bug with respect to fixes on the release branches? Are there any CLs that need to be submitted? Saw comment by @cherrymui about how there was a revert, so wanted to check (wearing my release interrupts hat). Thanks.

[griesemer]

I don't know what the status is at the moment. @cherrymui mentioned that she will re-submit.

[thanm]

Thanks. I will look into it then...

[gopherbot]

Change https://go.dev/cl/574736 mentions this issue: [release-branch.go1.21] go/types, types2: don't do version checks for embedded types of imported interfaces