cmd/test2json: has no timeout and behaves differently from go test in terms of signal handling

[ianwoolf]

What version of Go are you using (go version)?

$ go version
go version go1.19beta1 darwin/amd64
(also reproduces on 1.18.3)

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

GO111MODULE="on"
GOARCH="amd64"
GOBIN="/Users/bytedance/lang/go/bin"
GOCACHE="/Users/bytedance/Library/Caches/go-build"
GOENV="/Users/bytedance/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/bytedance/code/go/pkg/mod"
GONOPROXY="*.byted.org,*.everphoto.cn"
GONOSUMDB="*.byted.org,*.everphoto.cn"
GOOS="darwin"
GOPATH="/Users/bytedance/code/go"
GOPRIVATE="*.byted.org,*.everphoto.cn"
GOPROXY="https://goproxy.cn"
GOROOT="/Users/bytedance/code/self/go"
GOSUMDB="sum.golang.google.cn"
GOTMPDIR=""
GOTOOLDIR="/Users/bytedance/code/self/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.19beta1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/bytedance/code/self/go/src/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/p0/kb961x5d6wd79gfp2h6t_8500000gn/T/go-build1211973374=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

What did you expect to see?

go test has -timeout and does not handle the Ctrl-C. But test2json does not have test2json and handles Ctrl-C.

What did you see instead?

test2json should behave the same as go test in terms of signal handling.

[gopherbot]

Change https://go.dev/cl/419295 mentions this issue: cmd/test2json: add timeout and signal handlers

[ianwoolf]

related to #53563

[ianwoolf]

I submitted a cl. As I replied in cl, I think it might be more appropriate to put the signal related code into src/cmd/internal/base？

[ianlancetaylor]

Why do we need a timeout? We don't expect people to run test2json themselves. We expect them to run it via go test -json.

[ianwoolf]

Why do we need a timeout? We don't expect people to run test2json themselves. We expect them to run it via go test -json.

If we don't expect people to run test2json themselves, then test2json does not behave exactly like go test. If so, I think it would be appropriate to remove the timeout. But I want to confirm this, because there should be people using test2json now.

By the way, I want to confirm, should I add the signal related code directly to the test2json package? I originally wanted to move it from cmd/go/internal/base to cmd/internal/base, but I thought about it again, maybe other cmd don't need this.

how about you？@bcmills

[bcmills]

Duplicate of #53563

[bcmills]

If you want to run the test with a timeout outside of go test, you need to pass it the -test.timeout flag explicitly.

The signal-handling behavior is exactly the root cause of #53563.