Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/gc: inlining unparenthesizes struct literals in if statements. #4230

Closed
anacrolix opened this issue Oct 10, 2012 · 5 comments
Closed

cmd/gc: inlining unparenthesizes struct literals in if statements. #4230

anacrolix opened this issue Oct 10, 2012 · 5 comments

Comments

@anacrolix
Copy link
Contributor

Importing a module containing syntax like the following:

type bleh struct {
    hi int
}

func (me bleh) meh() string {
    if me == (bleh{}) { // <- this is bad
        return "0"
    }

Will give an error at the point of import, instead of during compilation at the line of
the actual syntax error.

I've boiled down the problem as small as I can get it here:
https://bitbucket.org/anacrolix/goplay/src/a2ffccb08ad0/bug

What is the expected output?
D:\gopath\src\bitbucket.org\anacrolix\goplay\bug>go build
bitbucket.org/anacrolix/goplay/bug
# bitbucket.org/anacrolix/goplay/bug/dep
d:\gopath\src\bitbucket.org\anacrolix\goplay\bug\dep\dep.go:8: syntax error: unexpected
{ at end of statement

What do you see instead?

D:\gopath\src\bitbucket.org\anacrolix\goplay\bug>go build
bitbucket.org/anacrolix/goplay/bug
# bitbucket.org/anacrolix/goplay/bug
d:\gopath\src\bitbucket.org\anacrolix\goplay\bug\main.go:4: syntax error: unexpected {
at end of statement

Which compiler are you using (5g, 6g, 8g, gccgo)?
8g, go version devel +bc50fc903d6e Thu Oct 11 01:34:26 2012 +0800

Which operating system are you using?
Windoze
@remyoudompheng
Copy link
Contributor

Comment 1:

This is not a syntax error. What happens is that the inlining information is missing the
parentheses that make the if statement grammatically correct.
See the spec:
A parsing ambiguity arises when a composite literal using the TypeName form of the
LiteralType appears between the keyword and the opening brace of the block of an "if",
"for", or "switch" statement, because the braces surrounding the expressions in the
literal are confused with those introducing the block of statements. To resolve the
ambiguity in this rare case, the composite literal must appear within parentheses.

Labels changed: added priority-later, compilerbug, removed priority-triage.

Status changed to Accepted.

@remyoudompheng
Copy link
Contributor

Comment 2:

This issue was closed by revision 319131f.

Status changed to Fixed.

@remyoudompheng
Copy link
Contributor

Comment 3:

This issue was closed by revision 20ebee2.

@ianlancetaylor
Copy link
Contributor

Comment 4:

Labels changed: added go1.1.2, removed go1.1.

@adg
Copy link
Contributor

adg commented Jul 22, 2013

Comment 5:

This issue was closed by revision 31a32150a72b.

@rsc rsc added this to the Go1.1.2 milestone Apr 14, 2015
@rsc rsc removed the go1.1.2 label Apr 14, 2015
adg added a commit that referenced this issue May 11, 2015
…rted if statements.

««« CL 10470043 / d04e6b0bcacf
cmd/gc: fix pointer composite literals in exported if statements.

Fixes #4230 (again).

R=rsc, golang-dev, r
CC=golang-dev
https://golang.org/cl/10470043
»»»

Update #5928

R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/11455045
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants