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

Go 1.9

Does this issue reproduce with the latest release?

Yes.

What did you do?

Suppose we have the following files:

package repro

type T struct{}

//go:nointerface

// NoInterfaceMethod has documentation that does not include the pragma above.
func (t *T) NoInterfaceMethod() {
}

package repro

import (
	"testing"
)

func TestNoInterface(t *testing.T) {
	x := interface{}(new(T))
	if _, ok := x.(interface {
		NoInterfaceMethod()
	}); ok {
		t.Error("type unexpectedly has method NoInterfaceMethod")
	}
}

This test passes normally, but fails with coverage enabled.

(NOTE: the field tracking experiment has to be enabled to turn on nointerface. This bug applies to function pragmas in general though; nointerface is just the easiest to observe).

Analysis

The problem is that cmd/compile and cmd/cover (and presumably other tools) treat pragmas differently.

In cmd/compile, pragmas are recognized by the lexer with minimal awareness of surrounding syntax. When lexer sees a pragma, it sets a bit in the parser. When a top-level definition is parsed, whichever pragma bits are set apply to that function. Pragma bits are cleared at the end of each top-level definition. See parser.go. Consequently, the compiler recognizes function pragmas even when there are comments and blank lines between the pragma and the definition it applies to.

In cmd/cover, pragmas are read from the syntax tree produced by go/parser. cmd/cover adds instrumentation to the source code. It removes most comments (since they are difficult to re-emit) but preserves pragma comments that were in the comment block for top-level definitions. Pragmas that were floating above a definition (as in the example above) are assumed not to apply to any specific definition and are moved to the top of the file. See cover.go. Here's the cover output for the example above:

//go:nointerface
package repro

type T struct{}

func (t *T) NoInterfaceMethod() {
	GoCover.Count[0] = 1
}

var GoCover = ...

Discussion

I'm not sure whether this should be considered a cmd/compile bug or a cmd/cover bug. It's surprising to me that the compiler recognizes function pragmas even when there are unrelated comments and blank lines between the pragma and the function definition. There aren't many public examples of pragmas used in this way. In cases where this happens, it seems like people are trying to avoid including the pragma in the documentation.

If this is a compiler bug, we should make the compiler consistent with cmd/cover, so that function pragmas must appear in the block of comments immediately above the definition. cmd/cover would not need to change. Existing examples of these floating pragmas would need to be fixed.

If this is considered a bug in cmd/cover, the comment processing functionality would need to be fixed so that function pragmas are attached to the following top-level definition. In general, any tool that rewrites source code while preserving semantics needs to watch out for this.