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

corhere · 2023-12-15T20:59:27Z

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)

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

mdempsky · 2023-12-15T21:14:15Z

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 · 2023-12-19T22:21:00Z

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 · 2023-12-20T02:07:33Z

@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 · 2023-12-20T02:15:49Z

@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 · 2023-12-21T23:13:28Z

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 · 2024-01-10T21:57:41Z

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 · 2024-01-10T23:14:26Z

@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 · 2024-01-10T23:26:12Z

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

gopherbot · 2024-01-10T23:51:13Z

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

griesemer · 2024-01-10T23:53:54Z

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 · 2024-01-10T23:55:34Z

@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 · 2024-01-10T23:56:07Z

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.

Accurate position information for embedded types in interfaces is crucial to identify the corresponding source file, and with that the Go language version associated with that file. (The position information is also important for proper error messages.) Before this CL, the position information for embedded types was discarded after type set computation, in the assumption that it was not needed anymore. However, substitutions that update the interface may lead to repeated type set computations which then won't have the correct position information. This CL does preserve the position information for embedded types until the end of type checking (cleanup phase), and also copy the position information during a substitution of the interface. The respective bug (#64759) doesn't seem to appear in 1.22 (most likely because it's hidden by some of the changes made with respect to the file version logic), but the existing code is still wrong. The backport of this code to 1.21 and 1.20 fixes the issue in those releases. For #64759. Change-Id: I80f4004c9d79cb02eac6739c324c477706615102 Reviewed-on: https://go-review.googlesource.com/c/go/+/555296 Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com>

gopherbot · 2024-01-11T18:29:00Z

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 · 2024-01-11T19:16:47Z

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 · 2024-01-11T19:20:16Z

This was fixed at tip (1.22).

… interface embeddings Accurate position information for embedded types in interfaces is crucial to identify the corresponding source file, and with that the Go language version associated with that file. (The position information is also important for proper error messages.) Before this CL, the position information for embedded types was discarded after type set computation, in the assumption that it was not needed anymore. However, substitutions that update the interface may lead to repeated type set computations which then won't have the correct position information. This CL does preserve the position information for embedded types until the end of type checking (cleanup phase), and also copy the position information during a substitution of the interface. The respective bug (#64759) doesn't seem to appear in 1.22 (most likely because it's hidden by some of the changes made with respect to the file version logic), but the existing code is still wrong. The backport of this code to 1.21 and 1.20 fixes the issue in those releases. For #64759. Fixes #65053. Change-Id: I80f4004c9d79cb02eac6739c324c477706615102 Reviewed-on: https://go-review.googlesource.com/c/go/+/555296 Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/555415 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

Accurate position information for embedded types in interfaces is crucial to identify the corresponding source file, and with that the Go language version associated with that file. (The position information is also important for proper error messages.) Before this CL, the position information for embedded types was discarded after type set computation, in the assumption that it was not needed anymore. However, substitutions that update the interface may lead to repeated type set computations which then won't have the correct position information. This CL does preserve the position information for embedded types until the end of type checking (cleanup phase), and also copy the position information during a substitution of the interface. The respective bug (golang#64759) doesn't seem to appear in 1.22 (most likely because it's hidden by some of the changes made with respect to the file version logic), but the existing code is still wrong. The backport of this code to 1.21 and 1.20 fixes the issue in those releases. For golang#64759. Change-Id: I80f4004c9d79cb02eac6739c324c477706615102 Reviewed-on: https://go-review.googlesource.com/c/go/+/555296 Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com>

Avoid golang/go#64759 Signed-off-by: Rob Murray <rob.murray@docker.com>

Avoid golang/go#64759 Co-authored-by: Bjorn Neergaard <bjorn.neergaard@docker.com> Signed-off-by: Rob Murray <rob.murray@docker.com>

gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Dec 15, 2023

corhere mentioned this issue Dec 15, 2023

[WIP] implement module compatibility check moby/moby#46941

Draft

mdempsky added the NeedsFix The path to resolution is known, but the work has not been done. label Dec 15, 2023

griesemer closed this as completed Dec 19, 2023

griesemer removed the NeedsFix The path to resolution is known, but the work has not been done. label Dec 19, 2023

corhere changed the title ~~cmd/compile: //go:build file version ignored when calling generic fn which has related type params~~ [go1.21] cmd/compile: //go:build file version ignored when calling generic fn which has related type params [1.21 only] Dec 20, 2023

corhere changed the title ~~[go1.21] cmd/compile: //go:build file version ignored when calling generic fn which has related type params [1.21 only]~~ cmd/compile: //go:build file version ignored when calling generic fn which has related type params [1.21 only] Dec 20, 2023

griesemer reopened this Dec 20, 2023

griesemer self-assigned this Dec 20, 2023

griesemer added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Dec 20, 2023

griesemer added this to the Go1.22 milestone Dec 20, 2023

griesemer added the NeedsFix The path to resolution is known, but the work has not been done. label Dec 21, 2023

gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Dec 21, 2023

thaJeztah mentioned this issue Jan 3, 2024

daemon: work around go1.21 compiler bug moby/moby#47020

Merged

dmitshur changed the title ~~cmd/compile: //go:build file version ignored when calling generic fn which has related type params [1.21 only]~~ 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) Jan 10, 2024

griesemer closed this as completed Jan 11, 2024

robmry added a commit to robmry/moby that referenced this issue Feb 29, 2024

Replace uses of slices.Clone()

bcc0ad7

Avoid golang/go#64759 Signed-off-by: Rob Murray <rob.murray@docker.com>

thaJeztah mentioned this issue Mar 1, 2024

Remove slices.Clone() calls to avoid Go bug moby/moby#47477

Merged

robmry added a commit to robmry/moby that referenced this issue Mar 1, 2024

Replace uses of slices.Clone()

8ff6ce5

Avoid golang/go#64759 Co-authored-by: Bjorn Neergaard <bjorn.neergaard@docker.com> Signed-off-by: Rob Murray <rob.murray@docker.com>

robmry added a commit to robmry/moby that referenced this issue Mar 1, 2024

Replace uses of slices.Clone()

91d9307

Avoid golang/go#64759 Co-authored-by: Bjorn Neergaard <bjorn.neergaard@docker.com> Signed-off-by: Rob Murray <rob.murray@docker.com>

robmry added a commit to robmry/moby that referenced this issue Mar 1, 2024

Replace uses of slices.Clone()

8bbdc45

Avoid golang/go#64759 Co-authored-by: Bjorn Neergaard <bjorn.neergaard@docker.com> Signed-off-by: Rob Murray <rob.murray@docker.com>

corhere mentioned this issue Mar 1, 2024

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

Closed

Dzejrou pushed a commit to Dzejrou/moby that referenced this issue Mar 5, 2024

Replace uses of slices.Clone()

3ed2ed8

Avoid golang/go#64759 Co-authored-by: Bjorn Neergaard <bjorn.neergaard@docker.com> Signed-off-by: Rob Murray <rob.murray@docker.com>

Dzejrou pushed a commit to Dzejrou/moby that referenced this issue Mar 5, 2024

Replace uses of slices.Clone()

5ae01e2

Avoid golang/go#64759 Co-authored-by: Bjorn Neergaard <bjorn.neergaard@docker.com> Signed-off-by: Rob Murray <rob.murray@docker.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

corhere commented Dec 15, 2023

mdempsky commented Dec 15, 2023

griesemer commented Dec 19, 2023

corhere commented Dec 20, 2023

griesemer commented Dec 20, 2023

griesemer commented Dec 21, 2023 •

edited

gopherbot commented Jan 10, 2024

dmitshur commented Jan 10, 2024

gopherbot commented Jan 10, 2024

gopherbot commented Jan 10, 2024

griesemer commented Jan 10, 2024

griesemer commented Jan 10, 2024

gopherbot commented Jan 10, 2024

gopherbot commented Jan 11, 2024

griesemer commented Jan 11, 2024

griesemer commented Jan 11, 2024

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

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

Comments

corhere commented Dec 15, 2023

Go version

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

What did you do?

What did you expect to see?

What did you see instead?

mdempsky commented Dec 15, 2023

griesemer commented Dec 19, 2023

corhere commented Dec 20, 2023

griesemer commented Dec 20, 2023

griesemer commented Dec 21, 2023 • edited

gopherbot commented Jan 10, 2024

dmitshur commented Jan 10, 2024

gopherbot commented Jan 10, 2024

gopherbot commented Jan 10, 2024

griesemer commented Jan 10, 2024

griesemer commented Jan 10, 2024

gopherbot commented Jan 10, 2024

gopherbot commented Jan 11, 2024

griesemer commented Jan 11, 2024

griesemer commented Jan 11, 2024

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

griesemer commented Dec 21, 2023 •

edited