cmd/compile: "used as value" syntax error reports the entire expression

[mvdan]

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

go version devel +9044f018ec Tue Jan 9 01:53:38 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What did you do?

https://play.golang.org/p/v7w9KCIbiDx

What did you expect to see?

syntax error: 0 = 1 used as value

What did you see instead?

syntax error: true || 0 = 1 used as value

I encountered this in a real program, where I typed = instead of ==. The overall boolean expression was much larger, so the error message wasn't very useful. I had to read the whole thing to manually spot where the mistake was.

I think that this error should instead point at what subexpression was invalid. That is, assuming that the syntax tree resulting from the bad program above has enough information to do that, which I hope it does. /cc @griesemer

[griesemer]

I agree that the error message is misleading. That said, it is not as wrong as it seems: Syntactically, this is not an expression but an assignment: (true || 0) = 1 . After parsing (and before type-checking) this is valid. But because it's used in an if statement, and because there's no ; following it, the if statement wants to see a condition (expression), but it sees a statement. It is correct to refer to the entire statement in the error message.

For the reference, gccgo complains with:

x.go:4:19: error: expected ';' after statement in if expression
  if true || 0 = 1 {
                   ^
x.go:4:15: error: invalid left hand side of assignment
  if true || 0 = 1 {
               ^
x.go:4:10: error: incompatible types in binary expression
  if true || 0 = 1 {
          ^

Leaving open for now; perhaps there's a better way to report this.

[mvdan]

I thought about that possibility for a bit before posting, but convinced myself that it wasn't the case because then the left part of an assignment would be an invalid node type. I should have played with other input programs for the compiler to check anyway - that was my bad.

I believe that "bad node type" could be detected before type checking. For example, speaking in AST terms, one could say that a binary expression can never be the left part of an assignment. I do not know whether this distinction could be part of the syntax package, or be considered a syntax error. But intuitively and practically, it seems to me like it could happen.

[mvdan]

To clarify - my thinking is that then the error for the example above would be something like cannot assign to "true || 0". It would allow identifiers, selectors, indexes, slices, stars, and other expression types that one can assign to.

[griesemer]

@mvdan Understood - such an error message for assignments may be helpful on its own, and it that case we might not get this error here. There's a lot of information that could be extracted from the AST before type-checking; it's a bit of a balancing act as to what errors the parser should report that are not pure syntax errors (syntactically, a + b = 0 is valid).

Independent of that (error for assignments), if the code would have been if true = 1 { ... we'd still have the same problem here: It would say true = 1 used as value albeit it would be perhaps less confusing (or more, depending on experience). The real question here is: What's more clearly expressing the programmer's intent, the fact that they wrote a statement here (and thus there's a semicolon missing and this is supposed to be an initialization statement); or the fact that they didn't write a semicolon (and thus this should have used an == instead of an = and this is supposed to be a condition)? It's a design decision. gccgo opted for the former and complains about a missing statementsemicolon; gc opted for the latter and complains about the statement used as value.

Perhaps the best solution is to do all three: Look for funny looking assignments (1), and in the error message here refer to the statement used as value (2), and the possibility of a missing semicolon (3).

Will play with this.

[gopherbot]

Change https://golang.org/cl/87316 mentions this issue: cmd/compile/internal/syntax: better error msg for some 'if' statements

[griesemer]

@mvdan I opted for simply highlighting (in the error message) the fact that we have an assignment here. See pending CL.

[gopherbot]

Change https://golang.org/cl/88336 mentions this issue: cmd/compile/internal/syntax: added test cases for recent fixes