x/tools/go/analysis/passes/stdversion: language vs toolchain version

[dominikh]

In this example

-- go.mod --
module example.com

go 1.23
-- foo.go --
//go:build go1.21

package pkg

import "reflect"

func main() {
	_ = reflect.TypeFor[int]
}

stdversion reports ./foo.go:8:14: reflect.TypeFor requires go1.22 or later (file is go1.21)

I believe that this might be overly strict. Even though the //go:build directive downgrades the language version available in the file, it doesn't change the fact that this file will only be built by a toolchain that is at least verison 1.23, because the module as a whole will only be built by a toolchain that satisfies the go dependency in go.mod.

I thus believe that the standard library available to a file with a build tag is max(file's version, module's version), and not min.

/cc @adonovan

[gabyhelp]

Related Issues

• go/ast, go/build/constraint: support for per-file Go versions using //go:build lines #59033 (closed)
• x/tools/go/analysis/passes/stdversion: spurious reports in files tagged //go:build 1.<old> #67123 (closed)
• doc: mention language downgrading via `//go:build` #61894

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[dominikh]

@adonovan ping, thoughts?

[adonovan]

Hi @dominikh, sorry for the delay. After a long discussion during which both @findleyr and I reversed ourselves, we agree that this is a bug. (Versioning is complex... @timothy-king wrote a talk laying out many aspects of it and how they interact, and I have long been meaning to distill these rules into a handy--or perhaps billboard-sized--flowchart for quick reference.)

The intent of the go1.21 build directive within a go1.23 module is to say: "the language features in this file should be downgraded to the semantics as they were in the go1.21 spec", but of course it will still be compiled and linked against the standard library of go1.23 or later. So this should disable go1.22 for-loop semantics (which could in theory be problematic for existing code), but should not prevent the file from accessing symbols of the go1.23+ library such as reflect.TypeFor.

In principle it may be impossible to use certain features of the go1.Y std library from a file tagged go1.X, where X < Y; for example, calling a generic library function from a source file that is not allowed to use generics. (So don't do that.)

I thus believe that the standard library available to a file with a build tag is max(file's version, module's version), and not min.

Agreed.

@rsc: Have we misremembered something from the long discussion we had when developing stdversion?