cmd/cover: go test reports panics on wrong line when using -covermode

[sarahhodne]

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

Reproduced on both:

• go version go1.6.2 linux/amd64
• go version devel +3b50adb Thu May 19 18:40:53 2016 +0000 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/henrik/gopath"
GORACE=""
GOROOT="/home/henrik/.gimme/versions/go"
GOTOOLDIR="/home/henrik/.gimme/versions/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build860467575=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

1. What did you do?

Project to reproduce is at https://github.com/henrikhodne/go-cover-test-panic (requires multiple files, otherwise I'd use play.golang.org).

1. What did you expect to see?

I'd expect the stack trace from go test with and without -covermode=count to report the panic on the same line (foo.go:7).

1. What did you see instead?

When enabling the coverage tool (go test -covermode=count ./...), the stack trace indicates that the panic is on foo.go:9, which is incorrect (probably due to the way the coverage tool injects code to mark lines as called?)

Interestingly, the line numbers are correct when I move the Foo() function into foo_test.go.
#6329 might be related.

[rsc]

This is due to an underlying bug, maybe, in go/printer. Probably the right thing to do is not to use go/printer at all and just insert the counter manipulation into the original file text (knowing the positions from go/ast). That would solve a few problems related to comments as well. But that's a pretty invasive change and won't happen for Go 1.8 or maybe even beyond. Marking Go1.9Early so we look at this early in the Go 1.9 cycle.

Note that when you do run the test you gave, the file names are different in the output as well: the line number in the -cover output refers to the cover-generated source file as well, so it's technically accurate. Of course, that source file has been deleted, so it's not terribly useful.

[JayNakrani]

This isn't a bug in cmd/cover or go/printer. The the actual code moves around a bit because of added counter increment statements.

Instrumented code,

$ go tool cover -mode=count foo.go | cat -n
     1	package foo
     2	
     3	func Foo() int {
     4		GoCover.Count[0]++
     5		a := 1 + 1
     6	
     7		if a == 2 {
     8			GoCover.Count[2]++
     9			panic("oops")
    10		}
    11		GoCover.Count[1]++
    12	
    13		return a
    14	}
    15	
    16	var GoCover = struct {
    17		Count     [3]uint32
    18		Pos       [3 * 3]uint32
    19		NumStmt   [3]uint16
    20	} {
    21		Pos: [3 * 3]uint32{
    22			3, 6, 0xc0010, // [0]
    23			10, 10, 0xa0002, // [1]
    24			6, 7, 0x10000c, // [2]
    25		},
    26		NumStmt: [3]uint16{
    27			2, // 0
    28			1, // 1
    29			1, // 2
    30		},
    31	}

Notice that in the generated code, panic("oops") has moved to 9th line because of two counter increment statements added before it.

There're two ways to improve debuggability of go test -cover:

1. Make instrumentation tool preserve the original line numbers. This is slightly tricky, but achievable with //line directive.
2. In case the test fails with -cover, keep the instrumented code around for later inspection.

I like the second one, because it's simple and doesn't add any more complexity into coverage instrumentation tool.

[gopherbot]

Change https://golang.org/cl/77151 mentions this issue: cmd/cover: add //line comment pointing to original file

[gopherbot]

Change https://golang.org/cl/77150 mentions this issue: cmd/cover: modify source as text, not as AST