Unfortunately, that makes it much more difficult than necessary to diagnose test failures that are specific to a GOOS or GOARCH, especially when those tests can be run natively (such as for 386 on an amd64 host) or under emulation (such as for tests that happen to mostly-work under QEMU).
The problem is especially acute now that we have fuzzing: 386 builds lack fuzzer instrumentation (so tests on that architecture behave substantially differently than on amd64), and many tests of the fuzzer are implemented as cmd/go script tests so that they can check the behavior of go test -fuzz=. end-to-end.
bcmills
added
Testing
An issue that has been verified to require only test changes, not just a test failure.
GoCommand
cmd/go
NeedsFix
The path to resolution is known, but the work has not been done.
labels
Jul 18, 2022
bcmills commentedJul 18, 2022
The test binary for
cmd/go
currently skips itself completely when itsGOOS
orGOARCH
doesn't match theGOOS
orGOARCH
of the installed toolchain:https://cs.opensource.google/go/go/+/master:src/cmd/go/go_test.go;l=196-214;drc=c2edb2c841149f2e56963071065d52247e24092a
Unfortunately, that makes it much more difficult than necessary to diagnose test failures that are specific to a
GOOS
orGOARCH
, especially when those tests can be run natively (such as for386
on anamd64
host) or under emulation (such as for tests that happen to mostly-work under QEMU).The problem is especially acute now that we have fuzzing:
386
builds lack fuzzer instrumentation (so tests on that architecture behave substantially differently than onamd64
), and many tests of the fuzzer are implemented ascmd/go
script tests so that they can check the behavior ofgo test -fuzz=.
end-to-end.I have a pending fix for this in CL 356611.
The text was updated successfully, but these errors were encountered: