cmd/go: fullpath always enabled in GOPATH mode

[rittneje]

Go version

go version go1.22.6 darwin/amd64

Output of go env in your module/workspace:

GO111MODULE='auto'
GOARCH='amd64'
GOBIN=''
GOCACHE='/tmp/.gocache'
GOENV='/Users/rittneje/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/rittneje/go/pkg/mod'
GONOPROXY='[REDACTED]'
GONOSUMDB='[REDACTED]'
GOOS='darwin'
GOPATH='/Users/rittneje/go'
GOPRIVATE='[REDACTED]'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/rittneje/go1.22.6'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/Users/rittneje/go1.22.6/pkg/tool/darwin_amd64'
GOVCS='[REDACTED]'
GOVERSION='go1.22.6'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='[REDACTED]'
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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/kf/kr7_s3xx0l12zbj3jrn082hmzy5gvy/T/go-build561042032=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

I ran go test in GOPATH mode (i.e., GO111MODULE=auto) without -fullpath.

What did you see happen?

The errors included full (absolute) paths.

What did you expect to see?

I expected to see relative paths.

If this behavior is intentional, it should be explicitly noted in the documentation for the -fullpath flag. https://pkg.go.dev/cmd/go#hdr-Test_packages

This also was not mentioned in the 1.21 release notes on the matter. https://tip.golang.org/doc/go1.21#go-command

I'll also note that even explicitly passing -fullpath=false doesn't disable it.

[gabyhelp]

Related Issues and Documentation

• cmd/go: 'go build' on a module absolute path while cwd is in GOPATH builds in GOPATH mode #27612 (closed)
• cmd/cgo: rewrites file paths to absolute in godefs generated comment #52063 (closed)
• cmd/go: clean paths before checking whether command line files are in same directory #47392 (closed)
• cmd/go: go list mangles absolute paths weirdly #29709 (closed)
• cmd/go: Module mode doesn't turn on automatically while build upon relative path #34043 (closed)
• go/build: resolve package in GOPATH when GO111MODULE=on outside module #34669 (closed)
• cmd/go: go test -fullpath should include full paths for build errors too #60451
• cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode #68658 (closed)
• go/build: defaultGOPATH cannot handle the confiliction correctly #18863 (closed)
• cmd/go: go mod init in GOPATH can create invalid module path #46085 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[cagedmantis]

cc @matloob @samthanawalla

[matloob]

Hi @rittneje, could you help me reproduce this? This is what I tried:

[~]$ go install golang.org/dl/go1.22.6@latest 
[~]$ go1.22.6 download
go1.22.6: already downloaded in /Users/matloob/sdk/go1.22.6
[~]$ export GOPATH=$HOME/Desktop/issue69500
[~]$ export GO111MODULE=auto
[~]$ echo "" | txtar Desktop/issue69500
-- Desktop/issue69500/src/example.com/foo/foo_test.go --
package foo

import "testing"

func TestFoo(t *testing.T) {
	t.Errorf("this is an error")
}
[~]$ go1.22.6 test -fullpath example.com/foo
--- FAIL: TestFoo (0.00s)
    /Users/matloob/Desktop/issue69500/src/example.com/foo/foo_test.go:6: this is an error
FAIL
FAIL	example.com/foo	0.185s
FAIL
[~]$ go1.22.6 test example.com/foo        
--- FAIL: TestFoo (0.00s)
    foo_test.go:6: this is an error
FAIL
FAIL	example.com/foo	0.195s
FAIL
[~]$ go1.22.6 test -fullpath=false example.com/foo
--- FAIL: TestFoo (0.00s)
    foo_test.go:6: this is an error
FAIL
FAIL	example.com/foo	0.181s
FAIL

(I'm using the txtar command to dump the contents of the foo_test.go file)

[rittneje]

@matloob For some strange reason, it only does this if you do "run test" in VS Code. I can't figure out why - I've try printing out os.Args from the test and then running that directly, and even that doesn't reproduce it.

I'm going to re-file this over there.