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

Jump to bottom

cmd/compile: give better error for composite literal parsing ambiguity #30867

Closed
empijei opened this issue Mar 15, 2019 · 6 comments
Closed

cmd/compile: give better error for composite literal parsing ambiguity #30867

empijei opened this issue Mar 15, 2019 · 6 comments
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.13

Comments

@empijei
Copy link
Contributor

empijei commented Mar 15, 2019

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

$ go version
go version go1.12 linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

type foo struct{}

func main() {
	bar := foo{}
	if bar == foo{} {
		fmt.Println("true")
		return
	}
	fmt.Println("false")
}

Play link

What did you expect to see?

true

What did you see instead?

prog.go:11:18: syntax error: unexpected { at end of statement
prog.go:15:2: syntax error: non-declaration statement outside function body

Please note that adding parentheses works

	if bar == (foo{}) {

Is this intended? If so, shouldn't the compiler give better errors?
@ianlancetaylor
Copy link
Contributor

Search for "parsing ambiguity" in https://golang.org/ref/spec#Composite_literals .

I don't know whether the compiler could give a better error message. I'll retitle the issue for that.

@ianlancetaylor ianlancetaylor changed the title cmd/compile: doesn't correctly parse struct literals without parentheses in if condition cmd/compile: give better error for composite literal parsing ambiguity Mar 15, 2019
@ianlancetaylor ianlancetaylor added help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 15, 2019
@ianlancetaylor ianlancetaylor added this to the Go1.13 milestone Mar 15, 2019
@arashbina
Copy link
Contributor

Do you still need someone to investigate this?

@ianlancetaylor
Copy link
Contributor

The thing to investigate would be whether it is straightforward for the compiler to give a better error message for this case. If you want to look into it, go ahead, but please be aware that this is a subtle issue that will need to consider several different kinds of incorrect code to make sure that the error message does not become more misleading. Thanks.

@arashbina
Copy link
Contributor

Ok thanks. I'll take a look and update here.

@quasilyte
Copy link
Contributor

quasilyte commented Apr 12, 2019 •
edited

I think the main complexity here is that the error message probably originates from the parser, and we don't know about types at that point, so I think it's impossible for a parser in the current state to tell whether foo is a type or not. It's relevant not only to the Go internal parser but also to go/parser.

@empijei
Copy link
Contributor Author

empijei commented Apr 18, 2019

I think this is rather complicated and would probably come up to be a hack. I looked into it and IMO it would add too much complexity to address it. I don't want that and since this is already documented I guess it can stay as it is.

Closing as won't fix. Feel free to re-open if you can come up with a good and simple solution.

@empijei empijei closed this as completed Apr 18, 2019
@golang golang locked and limited conversation to collaborators Apr 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.13
Development

No branches or pull requests
5 participants
@arashbina @empijei @ianlancetaylor @quasilyte @gopherbot