cmd/vet: consider reporting invalid/ignored Go versions in build tags

[griesemer]

Files may specify their own Go language version via a build tag. For instance:

//go:build go1.22

indicates that this file requires Go language version 1.22.

If the language version in the build tag contains dot-release information, say it's "go1.22.1", it is invalid.
The compiler simply ignores the version (it doesn't use, say "go1.22").

It seems (to me) that this shouldn't be silently ignored as it might be very confusing for users. go vet might be the right tool to report an error. Alternatively, the compiler could report an error, but generally, the compiler doesn't complain about errors in (pragma and build) comments.

[timothy-king]

go/analysis/passes/buildtag would be a good home for this check.

[Goclipse27]

@griesemer - Kindly assign me for this. How can I assign myself and update labels NeedsInvestigation, NeedsFix like that.

I have a silly question based on this doc/Blog - https://go.dev/doc/toolchain, https://go.dev/blog/toolchain

Doc :
For example, a module containing code that uses the Go 1.21 language version should have a go.mod file with a go line such as go 1.21 or go 1.21.3. If a specific source file should be compiled only when using a newer Go toolchain, adding //go:build go1.22 to that source file both ensures that only Go 1.22 and newer toolchains will compile the file and also changes the language version in that file to Go 1.22.

Blog:

There is also a new toolchain line in go.mod that specifies the minimum Go toolchain to use when working in a particular module. In contrast to the go line, toolchain does not impose a requirement on other modules. For example, a go.mod might say:

module m
go 1.21.0
toolchain go1.21.4

This says that **other modules requiring m** need to provide at least Go 1.21.0, but when we are working **in m itself,** we want an even newer toolchain, at least Go 1.21.4.

My Question : When working in m itself gives me a meaning like //go:build go1.21.4 - specific work is happening there for some of those files. But other modules requiring m files still build on go 1.21. So wouldn't patch version needed for build ?

Please let me know if I can re-phrase this better

[Goclipse27]

@griesemer @ianlancetaylor - Do you consider handling tags including expression like go:build go1.21 && go1.22.3 or a single tag ?

[Goclipse27]

@gopherbot - Assign this to me

[griesemer]

It should report any Go version string that is silently dropped and ignored.
Also, before anybody starts working on this: note this is a proposal and needs to be discussed by the proposal review committee first. Thanks.

[rsc]

We already have a //go:build line checker. It should definitely report these.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

The proposal is for the ‘buildtag’ checker to report build tags of the form go1.X.Y since only go1.X is recognized in build tags.