However, it just so happened that the build tag was introduced in a version later than the version I had pinned. My go mod had v1.13, the build tag was introduced in v1.18
This was incredibly difficult to discover, therefor I am suggesting that passing a build tag should produce an error if that build tag is not found anywhere. At least a warning should be displayed, if not failing the build entirely.
The text was updated successfully, but these errors were encountered:
I think this would be fairly difficult in practice. For example there is a standard library build tag osusergo, used only by the "os/user" package. Some people routinely build with go build -tags=osusergo. They don't want the build to fail just because the specific program they happen to be building doesn't import the "os/user" package.
@ianlancetaylor Good to know! Perhaps a list of known common build tags could be omitted from the check? Normally I feel something like this would be in go vet but as it's a build argument, there's no way to include it there.
Conversely, if the tags are not found during normal compilation, a scan could be performed of all relevant source codes - all of stdlib, all of vendor - and if it is still not found that could be cause for a build failure? The problem you mentioned would still exist but in much rarer cases, perhaps rare enough that it is unlikely to have happened.
Edit: Random idea, but a vet flag for build could be a very cool addition. go build -vet could fail on all normal vet conditions, as well as some extras that only occur during a build.