[Go Tests] Non-compilable code does not get its FilePath expanded

[oliverpool]

What version of Go, VS Code & VS Code Go extension are you using?

• go version go1.15 linux/amd64
• code -v

1.47.2
17299e413d5590b14ab0340ea477cdd86ff13daf
x64

• VS Code Go 0.16.1

Share the Go related settings you have added/edited

"go.useLanguageServer": true,

Describe the bug

When I run a test against a source which is not compilable (undefined struct), the location of the compilation error is not expanded to the fullpath of the code (and is hence not clickable).

Steps to reproduce the behavior:

Repo to reproduce: https://github.com/oliverpool/vscode-go-bugreport

1. Create a go file which can't compile. main.go

package main

func main() {
	Hello{}
}

2. Run the tests Go: Test package
3. See Output:

Running tool: /usr/bin/go test -timeout 30s -coverprofile=/tmp/vscode-go1sM0GN/go-code-cover

# github.com/oliverpool/vscode-go-bugreport
./main.go:4:2: undefined: Hello

The ./main.go:4:2 is not expanded, hence not clickable.

4. Create a test main_test.go

package main

func Test() {
	Hello{}
}

5. Run the tests Go: Test package
6. See Output:

Running tool: /usr/bin/go test -timeout 30s -coverprofile=/tmp/vscode-go1sM0GN/go-code-cover

# github.com/oliverpool/vscode-go-bugreport
/home/vscode-go-bugreport/main_test.go:3:1: wrong signature for Test, must be: func Test(t *testing.T)
FAIL	github.com/oliverpool/vscode-go-bugreport [setup failed]

/home/vscode-go-bugreport/main_test.go:3:1 is clickable (to quickly jump to the issue

[oliverpool]

When I run go test from the commandline, I get exactly the same output.

To fix this issue:

• either the output of go test must be changed to show the fullpath when the compilation error is not in the the test file
• or adjust the expandFilePathInOutput of this extension to consider this edge case

[oliverpool]

NB: sometime the failing output does not have a column value (./renderer.go:227: undefined: Matrix)

I can't reproduce it on a small example, but here is the output of my CLI:

> go test -timeout 30s
# github.com/tdewolff/canvas/pdf [github.com/tdewolff/canvas/pdf.test]
./renderer.go:227:61: undefined: Matrix
FAIL	github.com/tdewolff/canvas/pdf [build failed]

> go test -timeout 30s -coverprofile=/tmp/vscode-go4exoSB/go-code-cover
# github.com/tdewolff/canvas/pdf [github.com/tdewolff/canvas/pdf.test]
./renderer.go:227: undefined: Matrix
FAIL	github.com/tdewolff/canvas/pdf [build failed]

So this is more likely a go test issue, but this could easily be accounted for in this extension.

[oliverpool]

Please let me know, if you think that this issues should be reported (and fixed) directly in the go test tool.

[hyangah]

@oliverpool thanks for reporting the issue.
Compilation error is unstructured and I think the output is even printed before go test has a chance to handle, so it's somewhat tricky for us to handle. (See, go test -json output doesn't capture the compilation error messages)
File an issue in https://golang.org/issues if there is already an open issue already.

In my opinion, diagnostics feature is a more reliable way to surface compilation/build errors than the failure messages from the test output. For example, if you use the language server(gopls), the error will be reported with the correct location info already, so users don't have to depend on the test output.

[gopherbot]

Change https://golang.org/cl/248737 mentions this issue: src/testUtils.ts: fix parsing of the compiler error file expansion

[hyangah]

@oliverpool cl/248737 fixes the file location expansion issue when handling the build error output.

[oliverpool]

This look good, thanks!

Using a regex is brittle, but the proposed /^\s*(\S+\.go):(\d+):/ should cover most cases (it covers at least mine :-):

• main.go:123:
• ./main.go:123:

---

It does not match filenames with a space, but they always bear ambiguity:

• Failure in the file: main.go:123
• ./my main file.go (allowed by the tools, but uncommon enough to not be supported here)

[gopherbot]

Change https://golang.org/cl/252118 mentions this issue: [release] src/testUtils.ts: fix parsing of the compiler error file expansion