Workaround for the issue using -coverprofile output:

$ egrep ' 0$' /c/Users/egon/AppData/Local/Temp/vscode-govqeSQk/go-code-cover
<dir>/<file>.go:77.47,79.3 1 0

Isn't this just floating point rounding for an extreme corner case? Even if it printed 2 digits after the decimal point, you might still get 100.00%, depending on exactly how many statements are not executed.

I don't see a good solution, and don't feel the problem is important enough to do something special. The shorthand report makes no guarantees but there are other output forms that might help.

It's not pretty, but a simple hack strings.HasPrefix(pct, "100.") would work...

Maybe something like this?

package main

import (
	"fmt"
	"strings"
)

func coveragePct(active, total int64) string {
	pn := 100 * float64(active) / float64(total)
	var pct string
	for f := []byte("%.1f%%"); f[2] <= '8'; f[2]++ {
		pct = fmt.Sprintf(string(f), pn)
		if active == total || !strings.HasPrefix(pct, "100.") {
			break
		}
	}
	return pct
}

func main() {
	for n := int64(10); n <= 100_000_000_000; n *= 10 {
		a := n - 1
		fmt.Printf("%v/%v => %v\n", a, n, coveragePct(a, n))
	}
}

Output:

9/10 => 90.0%
99/100 => 99.0%
999/1000 => 99.9%
9999/10000 => 99.99%
99999/100000 => 99.999%
999999/1000000 => 99.9999%
9999999/10000000 => 99.99999%
99999999/100000000 => 99.999999%
999999999/1000000000 => 99.9999999%
9999999999/10000000000 => 99.99999999%
99999999999/100000000000 => 100.00000000%

/cc @bcmills @jayconrod @matloob

I agree with @robpike. 100.0% of statements does not imply “full coverage”, it implies ≥
99.95% coverage. (I would assume that only the printed digits are significant, as I was taught in high school science classes.)

If you want to analyze coverage down to the exact line, I would expect that you could build a standalone tool for that on top of the -coverprofile output. Is that not the case?

@bcmills

If you want to analyze coverage down to the exact line, I would expect that you could build a standalone tool for that on top of the -coverprofile output. Is that not the case?

That's true of course. I've been thinking about the default experience, this is how it went for me:

1. add some tests
2. click "Run package tests" in VS Code
3. it says 100.0%, great!
4. write doc comment for the tested function
5. there's a red line in the function, oh right, floating point

I agree with @robpike. 100.0% of statements does not imply “full coverage”, it implies ≥
99.95% coverage. (I would assume that only the printed digits are significant, as I was taught in high school science classes.)

Yes, but it also means that the output cannot be reliably used to check for full coverage if the package is slightly bigger. I've just checked, only 2000 lines! The code above increases the precision around 100.0% but it still stays in the high school mathematics.

There's another simpler solution which I use for progress reports (I hate seeing 100% when the software is not done):

func coveragePct(active, total int64) string {
	return fmt.Sprintf("%.1f%%", math.Trunc(1000*float64(active)/float64(total))/10)
}

I'd be in favor of go test -cover outputting 100.0% if and only if every line is covered, and otherwise cap it out at 99.9%.
Thoughts on that @robpike?

For context, we have a script which parses that output to check that a pkg's coverage meets a specified threshold (which is often 100%). I understand we could (and perhaps should) be parsing some other, more robust output, but I think between our use-case and the general use-case of a CLI or editor/IDE user seeing 100% when it's not really (and having expectation that 100% means every-line-is-covered), that it's worth making this rounding exception.