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/compile: give better error for composite literal parsing ambiguity #30867

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

Comments

Projects
None yet
4 participants
@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

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Mar 15, 2019

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 this to the Go1.13 milestone Mar 15, 2019

@arashbina

This comment has been minimized.

Copy link
Contributor

arashbina commented Mar 18, 2019

Do you still need someone to investigate this?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Mar 18, 2019

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

This comment has been minimized.

Copy link
Contributor

arashbina commented Mar 19, 2019

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

@quasilyte

This comment has been minimized.

Copy link
Contributor

quasilyte commented Apr 12, 2019

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

This comment has been minimized.

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 Apr 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.