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: parser rejects unambiguous unparenthesized TypeName composite literals in Condition expression of ForClause #48159

Open
mdempsky opened this issue Sep 2, 2021 · 3 comments
Labels
compiler/runtime NeedsDecision
Milestone

Comments

@mdempsky
Copy link
Member

mdempsky commented Sep 2, 2021

This package is rejected as syntactically invalid by go/parser and cmd/compile (and Go 1.4's 6g), but accepted by gccgo:

package p

type T struct{}

func F() {
	for ; T{} == T{}; {}
}

The Go spec says [emphasis added]:

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.

I think the intention here is that this is a gccgo parser issue for allowing TypeName composite literal between for and { without enclosing it in parentheses.

However, arguably this case isn't actually ambiguous: we've seen one semicolon after the for keyword, so we know to expect another ; before the {. And so the emphasized sentence technically doesn't apply as there's no ambiguity to resolve, and the program should be accepted.

/cc @griesemer @ianlancetaylor

@mdempsky mdempsky added the NeedsDecision label Sep 2, 2021
@mdempsky mdempsky added this to the Gccgo milestone Sep 2, 2021
@griesemer
Copy link
Contributor

griesemer commented Sep 2, 2021

I think the spec rule would need to be slightly tweaked to accommodate for the case of a condition in a for loop before the last semicolon; this would be a backward compatible change. And then parsers should just accept this code.

@mdempsky
Copy link
Member Author

mdempsky commented Sep 2, 2021

Revising the spec and other parsers to allow unparenthesized TypeName composite literals within ForClause.Condition sounds reasonable to me too.

@ianlancetaylor ianlancetaylor changed the title gccgo: parser accepts unparenthesized TypeName composite literals within Condition expression of ForClause cmd/compile: parser rejects unambiguous unparenthesized TypeName composite literals in Condition expression of ForClause Jul 7, 2022
@ianlancetaylor ianlancetaylor modified the milestones: Gccgo, Backlog Jul 7, 2022
@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Jul 7, 2022

Changing this to not be a gccgo issue. It's a minor language tweak that we could add if we like.

@gopherbot gopherbot added the compiler/runtime label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime NeedsDecision
Projects
Status: Triage Backlog
Development

No branches or pull requests

4 participants