cmd/vet: build tags in raw string literals should be ignored

[0xmohit]

main.go:

package main
const foo = `
//+build ignore
`

Running vet produces:

main.go:3: +build comment must appear before package clause and be followed by a blank line

This also contributes to noise in the vet output for core, e.g.

./src/crypto/x509/root_darwin_arm_gen.go:181: +build comment must appear before package clause and be followed by a blank line
./src/crypto/x509/root_darwin_arm_gen.go:182: +build comment must appear before package clause and be followed by a blank line
./src/crypto/x509/root_darwin_arm_gen.go:183: +build comment must appear before package clause and be followed by a blank line

[cznic]

Build tags detection by the go build system is by design line oriented to avoid unnecessary parsing. The vet tool does the same thing, which seems correct to me.

[ianlancetaylor]

@cznic That is a fair point, but in this case the other tools are not going to recognize the +build comment, which is what cmd/vet is saying anyhow. In a case like this it seems worth skipping raw string literals if not too complicated.

[tmthrgd]

This bug is actually a duplicate of #12269, I guess no one spotted that. That bug was closed by @robpike with the given reason "Not worth the trouble to fix."

I've hit this bug myself (here - tmthrgd/go-bindata#4), it's nothing all too major of course. Although it would be nice if go vet wasn't throwing up this false positive.

Is there any chance this bug might get fixed or is it still "not worth the trouble"?

[griesemer]

@ianlancetaylor Skipping raw string literals means recognizing them which requires full lexing (unless I'm missing some shortcut). That's probably more expensive than what we do now (to be verified). It seems a bit of overkill given that it's trivial to work around this issue (use a regular string and string concatenation as needed).

[ianlancetaylor]

Yes, it's probably not worth doing. Closing.

[josharian]

Now that vet is on by default, and we are aiming for 100% accuracy on such checks, and we’ve gotten a handful of dups of this recently, I think we should consider fixing this. Yes, parsing is more expensive than line-oriented searches, but compared to the rest of vet, which does full typechecking, I doubt it matters much, particularly since we only need parse up to the package clause.