Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

chrisreedy opened this issue Oct 22, 2018 · 3 comments

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

chrisreedy opened this issue Oct 22, 2018 · 3 comments


Copy link

@chrisreedy chrisreedy commented Oct 22, 2018

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?


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:


package test

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

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

	return x * y


package test

import (

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
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.

Copy link

@robpike robpike commented Oct 22, 2018

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

GoCover.Count[2] = 1;forloop:

/cc @rsc

@robpike robpike changed the title Reported coverage from go test -cover misses statements cmd/cover: branching to a labeled for misses some coverage Oct 23, 2018
Copy link

@robpike robpike commented Oct 23, 2018

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.

Copy link

@chrisreedy chrisreedy commented Oct 23, 2018

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.

@bcmills bcmills added the NeedsDecision label Oct 23, 2018
@bcmills bcmills added this to the Unplanned milestone Oct 23, 2018
tdakkota added a commit to tdakkota/jx that referenced this issue Jan 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants