GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build576186895=/tmp/go-build -gno-record-gcc-switches"
The exact same test code (main_test.go) is present in both bn256/cloudflare and bn256/google. I expect either both to fail with the format error, or neither of them.
Cloudflare always passes, Google always fails.
Thanks for the detailed report! This is a false positive, as math/big.Int implements fmt.Formatter, so the printf vet check should skip it.
It seems like the issue is that vet assumes that a program must import fmt to implement fmt.Formatter. Which is correct, but not the way it's used in the vet check. In this case, it's imported in the package that implements fmt.Formatter, which is math/big, and not the current package.
You can see that this is the cause because adding an import _ "fmt" makes the false positive go away.
@alandonovan now that cmd/vet is out of repo, how can we easily backport single commits? With git it should be possible to cherry-pick the x/tools commit into cmd/vendor/golang.org/x/tools, but I don't know if you have a better plan.
I also messed up the "Fixes" line in the x/tools commit, as usual. But that's actually good, as the issue isn't fixed in neither master nor 1.12.
I don't have any better ideas than simply applying the same change to both repos. The x/tools/go/analysis tree is subject to the release freeze, so I don't think there's any situation in which they should deviate.
Ah right, I keep forgetting that x/tools has a 1.12 branch as well. I presume we can just cherry-pick into its 1.12 branch, and update Go's 1.12 branch to vendor x/tools' updated 1.12 branch.
The x/tools piece was merged over a month ago; this just needs someone to update the vendored copy into a Go 1.12.x release. Unassigning myself, as I'm not needed for that bit.