Currently, coverage profiles include coverage for functions that cannot ever run (func _() { ... }). These sorts of functions are commonly used to generate compile-time checks that aren't expected to actually execute. For example, code generated by stringer:

// Code generated by "stringer -type=accessLevel -trimprefix=level"; DO NOT EDIT.

package bot

import "strconv"

func _() {
	// An "invalid array index" compiler error signifies that the constant values have changed.
	// Re-run the stringer command to generate them again.
	var x [1]struct{}
	_ = x[levelUnknown-0]
	_ = x[levelEveryone-1]
	_ = x[levelSubscriber-2]
	_ = x[levelModerator-3]
	_ = x[levelBroadcaster-4]
	_ = x[levelAdmin-99]
}

const (
	_accessLevel_name_0 = "UnknownEveryoneSubscriberModeratorBroadcaster"
	_accessLevel_name_1 = "Admin"
)

var (
	_accessLevel_index_0 = [...]uint8{0, 7, 15, 25, 34, 45}
)

func (i accessLevel) String() string {
	switch {
	case 0 <= i && i <= 4:
		return _accessLevel_name_0[_accessLevel_index_0[i]:_accessLevel_index_0[i+1]]
	case i == 99:
		return _accessLevel_name_1
	default:
		return "accessLevel(" + strconv.FormatInt(int64(i), 10) + ")"
	}
}

Could have a coverage profile of:

github.com/hortbot/hortbot/internal/bot/accesslevel_string.go:7.10,17.2 7 0
github.com/hortbot/hortbot/internal/bot/accesslevel_string.go:28.38,29.9 1 23
github.com/hortbot/hortbot/internal/bot/accesslevel_string.go:30.24,31.80 1 21
github.com/hortbot/hortbot/internal/bot/accesslevel_string.go:32.15,33.29 1 2
github.com/hortbot/hortbot/internal/bot/accesslevel_string.go:34.10,35.64 1 0

Note the first line, which says 7.10,17.2 7 0, i.e. the _ function has zero lines covered.

I propose that coverage data should be omitted for these _ functions. My rationale:

• Because these functions show up in coverage profiles, they "fool" commonly used coverage visualization / tracking systems into reporting a lower-than-true percentage. Here's my profile example on coveralls: https://coveralls.io/builds/27776643/source?filename=internal/bot/accesslevel_string.go
• These functions cannot run; their benefit is already gained at compile time.
• Due to the simplicity of the coverage profiles (just line info, no context), it's not straightforward to post-process coverage data to get this behavior without changing go test itself.

I'm not sure if this is a proper "proposal", but I didn't think it was exactly a "bug" either. Feel free to retitle as needed.