proposal: cmd/go: allow fine-grained go build constraints for go version

[pjebs]

Proposal Details

It would be great if *.go files can allow more fine-grained version constraints.
The go.mod file permits it - so it seems like an incongruency.

My project is dealing with compiled object files which have been compiled on a very specific go version/OS/arch. It is important to be able to differentiate between different versions of go with precision.

=== go.mod ===
module mymod
go 1.22.3

=== main1.go ===
//go:build go1.23.5 && !go1.23.6
package main
func main() {
	println("built using go1.23.5")
}

=== main2.go ===
//go:build go1.23.6 && !go1.24
package main
func main() {
	println("built using go1.23.6")
}

$ go1.23.5  run .
package mymod: build constraints exclude all Go files in /Users/x/Documents/test-go-build-constraints

$ go1.23.6  run .
package mymod: build constraints exclude all Go files in /Users/x/Documents/test-go-build-constraints

[gabyhelp]

Related Issues

• go/ast, go/build/constraint: support for per-file Go versions using //go:build lines #59033 (closed)
• cmd/go: use go.mod to define the required version of Go #26499 (closed)
• cmd/go: go directive is insufficiently documented for module authors to be able to make a decision about its value #30791 (closed)
• go build ignores GoVersion in go.mod file #58420 (closed)
• cmd/go: do not modify the 'go.mod' or 'go.sum' files if the 'go' directive indicates a newer-than-supported version? #34262
• cmd/go: consider matching newly added _goos.go, _goarch.go or _goos_goarch.go suffixes based on go.mod go version (rather than Go toolchain version only) #44626
• proposal: cmd/go: GOTOOLCHAIN=mod to use exact version of toolchain directive #69956

Related Documentation

• go.mod file reference > go > Notes
• Go Wiki: Comments > Directives > go tool directives > //go:build
• Go Modules Reference > go.mod files > go directive

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

[seankhliao]

I believe this is one of the reasons we removed support for binary only packages, I don't see it making it's way back.

[pjebs]

My example was specific to my use-case. The proposal is more general in terms of use-cases. Perhaps a Go patch version has a bug that you want your build to avoid. And that's not to mention the inconsistency with go.mod allowing it.

@ianlancetaylor What do you think?

[ianlancetaylor]

I think this is separate from binary-only packages.

[ianlancetaylor]

CC @matloob @samthanawalla

[matloob]

I think we'd want to have strong use cases to consider adding a feature like this, given the increased complexity.

My project is dealing with compiled object files which have been compiled on a very specific go version/OS/arch. It is important to be able to differentiate between different versions of go with precision.

Could you explain your use case more? I don't fully understand it.

[pjebs]

@matloob

My use-case is essentially to create a plugin package that works on any os,arch,go version. I am basically embedding the Go object files and adding build constraints to limit the package size. i.e. If go1.23 has 6 patch versions, currently because I can't add build constraints for each patch version, I have to embed each 6 Object files into the package under the go1.23 build constraint. Then in runtime I use the correct object file. But that means the end executable is larger than it needs to be.

I know what I'm doing is frowned upon by the Elders so it will have no persuasive value.

However, I was hoping these facts will be more persuasive:

1. Adding fine-grained build constraints is backward compatible as it goes from more general to more specific.
2. "go/version" and internal/gover.Parse already parse patch versions so it'd be trivial to parse the patch version of the go build constraints. Presumably that is what is parsing the go.mod file.
3. I once used an aws-go package that had a memory leak that only became noticeable over the medium-term. I'm not sure if it ever got fixed but it was acknowledged by AWS for over a year. That is a real-world anecdote. Brad Fitz has discovered another unique: Handle memory leaks; cleanup goroutine can't keep up #71772 memory leak.
4. Let's assume he didn't discover it in time for a back-port to be viable. (Say the current version of Go is Go1.28 and the memory leak is for Go1.24). Let's assume it was a serious bug that a person making a package DID NOT WANT their package to be built against that version of Go. Alternatively, it could be a security vulnerability instead of a obscure memory leak.
5. In that scenario, with finer build constraints, it is possible to enforce.