The go/parser package is working correctly. The error occurs in new code added by the cover tool. The cover tool should add a new //line comment for that code, so that it does not get misattributed to the original file.

In this case the bug is, of course, using a -var option with a name that is not a valid Go identifier. The cover tool could perhaps check for that too.

Hey @ianlancetaylor, I would like to start contributing to Go. I would be interested in working on this if that's OK for you. What do you think?

@nodo Sure, thanks.

Thanks @nodo

@ianlancetaylor I have started to look at the issue and I have a couple of doubts.

In order to check that the string passed using -var is a valid Go identifier I considered using https://golang.org/pkg/go/scanner and check if the output of the scanner is exactly one identifier. If that is the case, then the option is valid.

Another possibility would be to match the string against a regex that matches https://golang.org/ref/spec#Identifiers.

What do you think about these solutions? Are there other options?

@nodo A valid Go identifier is defined by the language spec at https://golang.org/ref/spec#Identifiers. It's easy enough to write a function for that, something like:

first := true
for _, c := range ident {
    if !unicode.IsLetter(c) && c != '_' && (first || !unicode.IsDigit(c)) {
        return false // invalid identifier
    }
    first = false
}

Awesome! Thanks @ianlancetaylor , I will continue that way.

Change https://golang.org/cl/120316 mentions this issue: cmd/cover: check that the argument of -var is valid

@ianlancetaylor I have added a first CL with the check that the argument of -var is a valid go identifier. WDYT?

Change https://golang.org/cl/153500 mentions this issue: cmd/cover: simplify and correct isValidIdentifier