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

corhere · 2024-03-01T19:19:35Z

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

The text was updated successfully, but these errors were encountered:

Jorropo · 2024-03-02T05:13:02Z

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.

go101 · 2024-03-02T06:23:18Z

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 · 2024-03-03T13:23:04Z

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 · 2024-03-06T21:52:51Z

CC @bcmills and @matloob maybe?

bcmills · 2024-03-07T22:08:58Z

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 · 2024-03-07T22:11:53Z

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

mknyszek · 2024-03-07T22:22:56Z

CC @golang/compiler

griesemer · 2024-03-08T00:10:38Z

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 · 2024-03-11T21:18:44Z

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 · 2024-03-11T22:05:48Z

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 · 2024-03-11T22:06:16Z

cc: @findleyr for visibility

gopherbot · 2024-03-12T16:50:54Z

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

… embedded types of imported interfaces Imported interfaces don't have position information for embedded types. When computing the type set of such interfaces, doing a version check may fail because it will rely on the Go version of the current package. We must not do a version check for features of types from imported packages - those types have already been typechecked and are "correct". The version check code does look at packages to avoid such incorrect version checks, but we don't have the package information available in an interface type (divorced from its object). Instead, for now rely on the fact that imported interfaces don't have position information for embedded types: if the position is unknown, don't do a version check. We may want to assert that positions are known in all other cases, but since this is an older release, don't add such additional changes to avoid introducing other bugs. Fixes #66064. Change-Id: I773d57e5410c3d4a911ab3e018b3233c2972b3c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/571075 Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>

griesemer · 2024-03-12T21:15:13Z

Closing as fixed in the 1.21 branch.

gopherbot · 2024-03-13T01:00:05Z

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

cherrymui · 2024-03-13T19:10:54Z

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

cherrymui · 2024-03-15T00:19:58Z

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

gopherbot · 2024-03-15T00:20:34Z

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 · 2024-03-26T19:19:41Z

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 · 2024-03-26T19:36:10Z

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

thanm · 2024-03-26T19:44:11Z

Thanks. I will look into it then...

gopherbot · 2024-03-27T18:45:29Z

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

… embedded types of imported interfaces [This is a re-apply of CL 571075] Imported interfaces don't have position information for embedded types. When computing the type set of such interfaces, doing a version check may fail because it will rely on the Go version of the current package. We must not do a version check for features of types from imported packages - those types have already been typechecked and are "correct". The version check code does look at packages to avoid such incorrect version checks, but we don't have the package information available in an interface type (divorced from its object). Instead, for now rely on the fact that imported interfaces don't have position information for embedded types: if the position is unknown, don't do a version check. We may want to assert that positions are known in all other cases, but since this is an older release, don't add such additional changes to avoid introducing other bugs. Fixes #66326. Updates #66064. Change-Id: I158cf51aa382f85d612ab958ba4b591de1c5fdb2 Reviewed-on: https://go-review.googlesource.com/c/go/+/574736 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

corhere changed the title ~~cmd/compile(?): //go:build file version ignored when calling package "slices" functions (reproduces with 1.21, not 1.22)~~ cmd/compile: //go:build file version ignored when calling package "slices" functions (reproduces with 1.21, not 1.22) Mar 1, 2024

gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Mar 1, 2024

seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 1, 2024

mknyszek changed the title ~~cmd/compile: //go:build file version ignored when calling package "slices" functions (reproduces with 1.21, not 1.22)~~ cmd/go: //go:build file version ignored when calling package "slices" functions (reproduces with 1.21, not 1.22) Mar 6, 2024

mknyszek added GoCommand cmd/go and removed compiler/runtime Issues related to the Go compiler and/or runtime. labels Mar 6, 2024

mknyszek added this to the Backlog milestone Mar 6, 2024

bcmills added compiler/runtime Issues related to the Go compiler and/or runtime. and removed GoCommand cmd/go labels Mar 7, 2024

bcmills changed the title ~~cmd/go: //go:build file version ignored when calling package "slices" functions (reproduces with 1.21, not 1.22)~~ cmd/compile: //go:build file version ignored when using generic function from package "slices" in Go 1.21 Mar 7, 2024

griesemer self-assigned this Mar 8, 2024

griesemer modified the milestones: Backlog, Go1.23 Mar 8, 2024

griesemer mentioned this issue Mar 12, 2024

go/types2, types2: version check (Checker.allowVersion) ignores module version if position information is missing #66274

Closed

griesemer closed this as completed Mar 12, 2024

cherrymui reopened this Mar 13, 2024

gopherbot closed this as completed in 133c8fc Mar 14, 2024

gopherbot mentioned this issue Mar 15, 2024

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

Closed

dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 20, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

corhere commented Mar 1, 2024

Jorropo commented Mar 2, 2024 •

edited

go101 commented Mar 2, 2024

thediveo commented Mar 3, 2024 •

edited

mknyszek commented Mar 6, 2024

bcmills commented Mar 7, 2024

bcmills commented Mar 7, 2024

mknyszek commented Mar 7, 2024

griesemer commented Mar 8, 2024

griesemer commented Mar 11, 2024 •

edited

griesemer commented Mar 11, 2024 •

edited

griesemer commented Mar 11, 2024

gopherbot commented Mar 12, 2024

griesemer commented Mar 12, 2024

gopherbot commented Mar 13, 2024

cherrymui commented Mar 13, 2024

cherrymui commented Mar 15, 2024

gopherbot commented Mar 15, 2024

thanm commented Mar 26, 2024

griesemer commented Mar 26, 2024 •

edited by thanm

thanm commented Mar 26, 2024

gopherbot commented Mar 27, 2024

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

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

Comments

corhere commented Mar 1, 2024

Go version

Output of go env in your module/workspace:

What did you do?

What did you see happen?

What did you expect to see?

Jorropo commented Mar 2, 2024 • edited

go101 commented Mar 2, 2024

thediveo commented Mar 3, 2024 • edited

mknyszek commented Mar 6, 2024

bcmills commented Mar 7, 2024

bcmills commented Mar 7, 2024

mknyszek commented Mar 7, 2024

griesemer commented Mar 8, 2024

griesemer commented Mar 11, 2024 • edited

griesemer commented Mar 11, 2024 • edited

griesemer commented Mar 11, 2024

gopherbot commented Mar 12, 2024

griesemer commented Mar 12, 2024

gopherbot commented Mar 13, 2024

cherrymui commented Mar 13, 2024

cherrymui commented Mar 15, 2024

gopherbot commented Mar 15, 2024

thanm commented Mar 26, 2024

griesemer commented Mar 26, 2024 • edited by thanm

thanm commented Mar 26, 2024

gopherbot commented Mar 27, 2024

Output of `go env` in your module/workspace:

Jorropo commented Mar 2, 2024 •

edited

thediveo commented Mar 3, 2024 •

edited

griesemer commented Mar 11, 2024 •

edited

griesemer commented Mar 11, 2024 •

edited

griesemer commented Mar 26, 2024 •

edited by thanm