Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testing: go test -n is missing the creation of _testmain.go #66592

Open
Snaipe opened this issue Mar 29, 2024 · 4 comments
Open

testing: go test -n is missing the creation of _testmain.go #66592

Snaipe opened this issue Mar 29, 2024 · 4 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@Snaipe
Copy link

Snaipe commented Mar 29, 2024

Go version

go1.21.5

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/snaipe/.local/var/cache/go-build'
GOENV='/home/snaipe/.local/etc/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/snaipe/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/snaipe/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/lib/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.5'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/snaipe/b5/src/barney.ci/golang/generator/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build859927413=/tmp/go-build -gno-record-gcc-switches'

What did you do?

Running the following commands:

$ go test -a -n 2>build.sh
$ WORK=/tmp/go-test envsubst '$WORK' <build.sh >build-exp.sh
$ sh -xe ./build-exp.sh </dev/null

... should reproduce the same effect as running go test normally.

What did you see happen?

The command building the test binary fails to find _testmain.go

+ /usr/lib/go/pkg/tool/linux_amd64/compile -o /tmp/go-test/b001/_pkg_.a -trimpath /tmp/go-test/b001=> -p main -complete -buildid yj7N4yan_zFjBd_JXc9h/yj7N4yan_zFjBd_JXc9h -dwarf=false -goversion go1.21.5 -c=4 -nolocalimports -importcfg /tmp/go-test/b001/importcfg -pack /tmp/go-test/b001/_testmain.go
open /tmp/go-test/b001/_testmain.go: no such file or directory

What did you expect to see?

The compile command should have succeeded.

This is happening because the writing of the _testmain.go file is directly done by go test rather than done via an action.

@gopherbot
Copy link

Change https://go.dev/cl/574698 mentions this issue: cmd/go/internal/test: write _testmain.go with -n flag

@thanm thanm added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 29, 2024
@thanm
Copy link
Contributor

thanm commented Mar 29, 2024

@golang/tools-team

I am not sure it makes sense to have a strong commitment to ensuring that "go build/test -n" output produces a script that has the exact same semantics as the build itself - I am sure I have seen other places similar to this where the trace output is not perfectly reflective of reality.

If we want to do this we would need a lot more testing, perhaps a builder that would lock down this behavior (otherwise it would break as the Go tool evolved). This doesn't seem (at least to me) like a good use of team resources. Go tools folks should have the final call however.

@matloob
Copy link
Contributor

matloob commented Apr 3, 2024

@thanm I agree that it shouldn't be a super high priority for us to ensure the script is perfect, but -n is a feature of go build/test that we say we support in the documentation, so it seems to me that we should try to make an effort to keep it accurate?

edit: I can see the argument in the other direction-- the help test says that we print the commands run, and I guess it's debatable whether producing the testmain file is one of the "commands" that we run, but we seem to print out entries for the other inputs that we produce to the other commands.

@thanm
Copy link
Contributor

thanm commented Apr 3, 2024

@matloob that works for me-- if you and the other Go command owners are happy with the proposed fix so am I, thanks :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants