cmd/cover: branching to a labeled for misses some coverage

[chrisreedy]

See below for a simple program that reports statements as uncovered when they are covered.

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

go version go1.11 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

Mac OS 10.13.6

What did you do?

Run "go test -cover" on the following code:

demo.go:

package test

func testit(x, y int) int {
	var i int
	if x == 0 {
		goto forloop
	}
	goto returnit

forloop:
	// The problem also appears if for is changed to switch but not to if
	for i < y {
		i += 1
	}
	return x + i

returnit:
	return x * y
}

demo_test.go

package test

import (
	"fmt"
	"testing"
)

var testCases = []struct {
	x, y, ret int
}{
	{1, 1, 1},
	{0, -1, 0},
	{0, 3, 3},
}

func TestDemo(t *testing.T) {
	for n, c := range testCases {
		t.Run(fmt.Sprint("Case#", n), func(t *testing.T) {
			if r := testit(c.x, c.y); r != c.ret {
				t.Errorf("testit(%d, %d) returned %d expected %d", c.x, c.y, r, c.ret)
			}
		})
	}
}

What did you expect to see?

100% coverage

What did you see instead?

Chriss-MacBook-Pro:test godev$ go test -cover
PASS
coverage: 88.9% of statements
ok  	test	0.005s

Running the html coverage tool shows the code "forloop: for i < y" as not covered. Changing the for to a switch does not change the result. However, changing the for to an if results in 100% coverage. The "goto" jumping over this code appears to be essential to the bug.

This issue may be the same as #27015.

[robpike]

The bug is that the counter is placed before the label:

GoCover.Count[2] = 1;forloop:

/cc @rsc

[robpike]

There is a comment in the code about this case:

// If it is a labeled statement, we need to place a counter between
// the label and its statement because it may be the target of a goto
// and thus start a basic block. That is, given
//	foo: stmt
// we need to create
//	foo: ; stmt
// and mark the label as a block-terminating statement.
// The result will then be
//	foo: COUNTER[n]++; stmt
// However, we can't do this if the labeled statement is already
// a control statement, such as a labeled for.

The problem is that

foo: for ...

makes the for statement a "labeled for", which means break and continue can name the label to control the loop. But then we can't insert a statement between the label and the for without breaking the code.

The only way to fix this that I can see is difficult: We need to change the code to

_newlabel_: foo: for ...

Then we can insert the counter after _newlabel_. That will require rewriting the goto statements (or rewriting the break and continue statements).

Ugly corner case. I'm not sure it's worth the trouble to fix.

[chrisreedy]

Thanks for the information. In this case, the label is a branch target not a label on the for. (The code is from a state machine that uses "goto" to transition between states.) I can fix my coverage problem by inserting a ; between the label and the for.