proposal: cmd/vet: consider reporting invalid/ignored Go versions in build tags #64127
Comments
|
go/analysis/passes/buildtag would be a good home for this check. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@griesemer @ianlancetaylor - Do you consider handling tags including expression like go:build go1.21 && go1.22.3 or a single tag ? |
This comment was marked as resolved.
This comment was marked as resolved.
|
It should report any Go version string that is silently dropped and ignored. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Files may specify their own Go language version via a build tag. For instance:
//go:build go1.22indicates 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 vetmight 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.The text was updated successfully, but these errors were encountered: