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

Jump to bottom

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

Open
chrisreedy opened this issue Oct 22, 2018 · 3 comments
Open

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

chrisreedy opened this issue Oct 22, 2018 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Unplanned

Comments

@chrisreedy
Copy link

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
Copy link
Contributor

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
@robpike
Copy link
Contributor

robpike commented Oct 23, 2018 •
edited

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
Copy link
Author

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 Feedback is required from experts, contributors, and/or the community before a change can be made. 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
@tdakkota
chore: add semicolon to fix cover tool bug
97d4e11 
See golang/go#28319
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@robpike @bcmills @chrisreedy @gopherbot