go version go1.18 linux/amd64
https://go.dev/doc/go1.18 says:
In Go 1.18, go fix now removes the now-obsolete // +build lines in modules declaring go 1.17 or later in their go.mod files.
And the original issue agrees:
#41184
https://go.googlesource.com/proposal/+/master/design/draft-gobuild.md
I propose that we adopt this design, with N = 17 in the Transition section,
Go 1.(N+1) would complete the transition. In Go 1.(N+1):
A new fix in go fix will remove // +build stanzas, making sure to leave behind equivalent //go:build lines. The removal only happens when go fix is being run in a module with a go 1.N (or later) line, which is taken as an explicit signal that the developer no longer needs compatibility with Go 1.(N−1). The removal is never done in GOPATH mode, which lacks any such explicit signal.
However, the cmd/fix code incorrectly requires go 1.18 or later for the removal of // +build lines to happen:
const buildtagGoVersionCutoff = 1_18
[...]
func buildtag(f *ast.File) bool {
if goVersion < buildtagGoVersionCutoff {
return false
}
I assume this was a mistake in the code. I only noticed because I have a module with build tags and go 1.17 in its go.mod, signaling that I no longer support Go 1.16.x, and yet I was surprised to see that go fix wouldn't clean up the build tags until I pushed go.mod to go 1.18.
I have the rather trivial fix ready. The point of this issue is that, assuming I'm right, this would need to be backported for Go 1.18.x, to make the release notes actually reflect reality.
cc @rsc @ianlancetaylor
https://go.dev/doc/go1.18 says:
And the original issue agrees:
#41184
https://go.googlesource.com/proposal/+/master/design/draft-gobuild.md
However, the cmd/fix code incorrectly requires
go 1.18or later for the removal of// +buildlines to happen:I assume this was a mistake in the code. I only noticed because I have a module with build tags and
go 1.17in itsgo.mod, signaling that I no longer support Go 1.16.x, and yet I was surprised to see thatgo fixwouldn't clean up the build tags until I pushedgo.modtogo 1.18.I have the rather trivial fix ready. The point of this issue is that, assuming I'm right, this would need to be backported for Go 1.18.x, to make the release notes actually reflect reality.
cc @rsc @ianlancetaylor