This is closely related to

• cmd/go: always pass a GoVersion to cmd/vet #65612
  and https://go.dev/cl/567435 (CC @samthanawalla @matloob), in that cmd/go sometimes doesn't pass a language version for a main.go file when it could.

However, in the absence of any -lang flag, I expect cmd/compile to still apply whatever version information it has inferred from the //go:build directives, and it appears not to be doing so. This looks like a compiler bug.

CC @golang/compiler

@bcmills
Just a btw question: it looks the -gcflags=-lang=go1.xy compiler flag is only applied to the seed files being passed to the compiler. Other involved source files in building will not be affected by the flag. Is this the intended design?

In runtime/compiler triage, we think this is a Go command issue? Is that right? Thanks.

I think it is a composite of a cmd/go bug (not passing the -lang flag) and a cmd/compile bug (not using //go:build version hints when -lang is not explicitly set).

The cmd/go bug should be fixed in #65612, so I suggest we focus the investigation in this issue on the cmd/compile side.

Will this be fixed in 1.22.3+?

When no -lang is specified, in general we don't know how to interpret //go:build lines in files because their interpretation may depend on the current -lang version.

cc: @rsc for input.

Is it a good idea to use the version of the go command as the -lang arg?

@go101 Is the top comment wrong? It says got true, expected false for go run main.go, but with Go 1.21 I get false and Go 1.22 I get true. If you think there is a bug in Go 1.22, then did you mean "got false, expected true"?

I mean the //go:build go1.21 line should matter, so that the results should be consistent with Go toolchain 1.21 and 1.22.

I'm just trying to puzzle through this all since I don't know what "gotv 1.22." does either...

gotv is a tool used to switch Go toolchain versions conveniently: https://go101.org/apps-and-libs/gotv.html

gotv 1.22. means using the latest version prefixed by 1.22. It will be expanded to $HOME/.cache/gotv/tag_go1.22.0/bin/go. :)

For future bug reports it would help to use reproduction instructions that are limited to standard tooling.

Here is a clearer reproduction case:

% cd /tmp
% cat x.go
//go:build go1.21

package main

func main() {
	for i, p := 0, (*int)(nil); p == nil; check(p == &i) {
		p = &i
	}
}

func check(b bool) {
	if b {
		println("using old semantics")
	} else {
		println("using new semantics")
	}
}
% GOTOOLCHAIN=go1.21.0 go run x.go
using old semantics
% GOTOOLCHAIN=go1.22.0 go run x.go
using new semantics
% GOTOOLCHAIN=go1.22.0 go run -gcflags=-lang=go1.22 x.go
using old semantics
% 

CL 567435 in progress should fix this. The fix is to just make sure that cmd/go passes -lang to the compiler always.

I looked into changing what the compiler does when -lang is empty, but right now it intentionally ignores the //go:build lines to avoid downgrades, and for good reason (for example see GOROOT/src/internal/types/testdata/check/go1_xx_19.go). If we change the compiler, we risk breaking other uses of the compiler like Bazel. And the go command needs the logic anyway to help cmd/vet, so we might as well just make sure the go command always makes the decision.

Change https://go.dev/cl/567435 mentions this issue: cmd/go: set the GoVersion for files listed on the commandline