cmd/compile: unexpected error with curly-braced initializer before if-block condition #20777
Comments
odeke-em
changed the title
|
This is working as expected. You already found the solution (https://play.golang.org/p/E4-j5HV-lz). See also https://golang.org/ref/spec#Composite_literals: A parsing ambiguity arises when a composite literal using the TypeName form of the LiteralType appears as an operand between the keyword and the opening brace of the block of an "if", "for", or "switch" statement, and the composite literal is not enclosed in parentheses, square brackets, or curly braces. In this rare case, the opening brace of the literal is erroneously parsed as the one introducing the block of statements. To resolve the ambiguity, the composite literal must appear within parentheses. |
|
PS: In a context-free grammar (as most modern programming languages have), there's no way for the parser/compiler to figure out what the programmer meant here. In other words, this is a true ambiguity in the syntax and not a compiler error. The ambiguity is resolved by adding the parentheses. We decided early on that it was worth the price for being able to use curly braces for composite literals (rather than some other notation which might have avoided the ambiguity). |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?1.8.3
What operating system and processor architecture are you using (
go env)?What did you do?
https://play.golang.org/p/TVAiPb6Bj7
What did you expect to see?
I expected this program to compile without error. It seems to choke on the use of curly-braced initializers in the (optional) simple statement before the semicolon preceding the
ifblock's condition expression. According to the spec, aSimpleStatementcan be aShortVarDecl, which by my reading ought to encompass such cases. I suspect that the parser is treating the open curly brace on the struct literal as if it were the open brace for theif's actual block.What did you see instead?
Adding parens around the
SimpleStatementworks around the problem. The same problem occurs not just with struct types, but also literals of user-defined types with an underlying type whose kind is a slice.The text was updated successfully, but these errors were encountered: