proposal: cmd/go: support naming compiled tests with full qualified name

[howardjohn]

Since #15513, we can now do go test -c -o dir/ ./.... This works great and has a lot of use cases mentioned in the issue.

The issue, though, is this requires every package to have a unique name. This is not the case for most code bases, including Go itself (you can check with go list ./... | xargs -n1 basename | sort | uniq -d I believe).

It would be great to allow an alternate naming for the compiled tests. For example, instead of naming a file a/b/c/some_test.go as c.test, it could be named a_b_c.test or similar.

This would ensure the new mode works for all codebases.

This could be a new flag, or it could be the default when using -c with multiple files. However, the latter is probably a breaking change unless its included in 1.21 which may be too late.

[rittneje]

This can still cause a collision if I have a package named a/b and a package named a_b (unusual but not impossible).

Another option is to preserve the directory structure, so we'd end up with for example a/b/c.test. (I'd love if that were a thing for go build since you can also get collisions there.)

[seankhliao]

or just use a different separator like -

[bcmills]

There is a tradeoff between ergonomics and API complexity: you always have the fallback of running go test -c on the packages individually, although getting the concurrency right could be a little tricky.

[howardjohn]

@bcmills while that is true its going to be dramatically less efficient than a single invocation. https://blog.howardjohn.info/posts/go-build-times/#concurrent-builds showcases this a bit; running two compile jobs concurrently in different processes seems to get very very little caching benefits.

https://blog.howardjohn.info/posts/go-build-times/#integration-tests shows another concrete example of how we would use this, specifically to take advantage of the superior build times when compiling multiple things in a single go invocation