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: cannot parse certain constraint literals in generic functions #49174

griesemer opened this issue Oct 27, 2021 · 4 comments


Copy link

@griesemer griesemer commented Oct 27, 2021

package p

func _[_ []int | int]() {}  // cannot parse: syntax error: unexpected |, expecting comma or ]
func _[_ int | []int]() {}  // ok

Both constraints are identical and both are valid. Should be able to parse both of them.

@griesemer griesemer added NeedsFix NeedsInvestigation release-blocker labels Oct 27, 2021
@griesemer griesemer added this to the Go1.18 milestone Oct 27, 2021
@griesemer griesemer self-assigned this Oct 27, 2021
@gopherbot gopherbot removed the NeedsFix label Oct 27, 2021
@griesemer griesemer changed the title cmd/compile: cannot parse certain constraint literals cmd/compile: cannot parse certain constraint literals in generic functions Oct 27, 2021
Copy link

@gopherbot gopherbot commented Oct 27, 2021

Change mentions this issue: cmd/compile/internal/syntax: fix constraint literal parsing for generic functions

Copy link

@findleyr findleyr commented Oct 27, 2021

This does not affect go/parser.

Copy link
Contributor Author

@griesemer griesemer commented Oct 27, 2021

Fix is pending but this is also not a release blocker. There is a work-around:

func _[_ ([]int) | int]() {} // work-around: use parentheses

and this case is uncommon; most of the time we want

func _[_ ~[]int | ~int]() {}

Copy link

@gopherbot gopherbot commented Oct 27, 2021

Change mentions this issue: go/parser: fix parsing of array or slice constraint types

gopherbot pushed a commit that referenced this issue Oct 28, 2021
Now that we allow eliding 'interface' from constraint types, we need to
be a bit more careful about not consuming a '[' when parsing the next
expression after "type T [". We want to check if the next expression is
an identifier not followed by ']', in which case we're in a generic
type, but need to avoid parsing index or slice expressions. Such
expressions aren't valid array lengths because these expressions are
never constant, so when encountering a following '[' we can instead
assume that this is a type parameter field with array or slice type

Test cases are added for the related issues #49174 and #49175, along
with a flag to enable tracing error tests.

For #49174
For #49175

Change-Id: I0476ef20c4c134ac537118272f20caaf123ee70e
Trust: Robert Findley <>
Run-TryBot: Robert Findley <>
TryBot-Result: Go Bot <>
Reviewed-by: Robert Griesemer <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants