Adding the following extra assertions to cmd/go/testdata/script_build_cache_output.txt causes the test to fail at the ! stderr 'link(\.exe"?)? -' assertion:
--- c/src/cmd/go/testdata/script/build_cache_output.txt+++ w/src/cmd/go/testdata/script/build_cache_output.txt@@ -52,6 +52,25 @@ stderr '\d+ symbols' # from linker
! stderr 'p\.test( |\.exe"?)'
stdout 'TEST' # from test
+# The gcflags above cause the compiler and linker to print diagnostic output,+# but if we rebuild without those flags we should end up with a resulting test+# binary with exactly the same contents, and thus the same ID.+# The result of running that binary is already cached.+go test -v -x p+stdout 'TEST' # from test+stdout '^ok\s+p\s+\(cached\)$' # from cmd/go+stderr 'compile( |\.exe"?)'+stderr 'link(\.exe"?)? -'+stderr 'p\.test( |\.exe"?)'++# If we run the test one more time, we shouldn't need to compile or link anything,+# because we know that the ID will be the same.+go test -v -x p+stdout 'TEST' # from test+stdout '^ok\s+p\s+\(cached\)$' # from cmd/go+! stderr 'compile( |\.exe"?)'+! stderr 'link(\.exe"?)? -'+! stderr 'p\.test( |\.exe"?)'
-- lib.go --
Note that both ok p (cached) assertions are passing, so this means that under some circumstances we are printing a test's output as “cached” but re-invoking the linker for the test anyway. There is some special-case code in cmd/go/internal/test (added in CL 75631) that attempts to prevent exactly this situation; it isn't yet clear to me why it isn't working.