Does this issue reproduce with the latest release?
N/A
What did you do?
I ran this testscript:
! exec go test -C ./x -fullpath .
! stderr '\./x.go'
-- x/x.go --
package foo
var x = mistake
-- go.mod --
module test
What did you expect to see?
A passing test.
What did you see instead?
> ! exec go test -C ./x -fullpath .
[stdout]
FAIL
[stderr]
# test/x
./x.go:3:9: undefined: mistake
[exit status 1]
> ! stderr '\./x.go'
FAIL: /tmp/testscript142857279/x.txtar/script.txtar:2: unexpected match for `\./x.go` found in stderr: ./x.go
It seems to me that the intent of -fullpath is to cause all filenames to print in a way that's absolute, even when those errors come from the compiler rather than the test binary. I'd expect the compiler error to print an absolute path there too.
The text was updated successfully, but these errors were encountered:
This means moving -fullpath from being a test option to being a build option, and then using it to pass something to cmd/compile. We would presumably still have the -test.fullpath option, which would be different, but -fullpath would imply -test.fullpath.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
N/A
What did you do?
I ran this testscript:
What did you expect to see?
A passing test.
What did you see instead?
It seems to me that the intent of
-fullpath
is to cause all filenames to print in a way that's absolute, even when those errors come from the compiler rather than the test binary. I'd expect the compiler error to print an absolute path there too.The text was updated successfully, but these errors were encountered: