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.