Skip to content

cmd/go: linker repeatedly invoked for cached test results #49267

Open
@bcmills

Description

@bcmills

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 --
 package p

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.

(CC @matloob)

Metadata

Metadata

Assignees

No one assigned

    Labels

    GoCommandcmd/goNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions