cmd/compile: unexpected error with curly-braced initializer before if-block condition

[snargleplax]

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)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/luke/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/kk/4m8p_4c155bdfbg8kb5cgvx40000gq/T/go-build187863764=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

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 if block's condition expression. According to the spec, a SimpleStatement can be a ShortVarDecl, 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 the if's actual block.

What did you see instead?

tmp/sandbox703829250/main.go:10: syntax error: a := myStruct used as value
tmp/sandbox703829250/main.go:11: syntax error: unexpected semicolon or newline, expecting comma or }

Adding parens around the SimpleStatement works 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.

[griesemer]

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.

[griesemer]

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).