go/printer: produces a invalid source, for a successfully parsed AST

[mateusz834]

Consider:

type _[a (b + 3),] struct{}

This is parsed successfully by go/parser and it gets formatted into:

type _[a b + 3] struct{}

This is not valid go syntax. Not sure how this should be handled, should type _[a (b + 3),] struct{} cause a parser error?

For example, the source below causes a parser error (expected ')', found '+')

type _[a ~int, b (a+3)]struct{}

CC @griesemer

[griesemer]

Milestone 1.24 only so it stays on the radar - this is not really urgent in any way as this code won't pass the typecheckers and thus won't appear in real code.

[griesemer]

Looking at this some more, type _[a (b + 3),] struct{} should probably be a parser error, but there's two ways to approach it: since (b + 3) cannot be a type, the entire parameter list is considered an array length, and the , is unexpected. Alternatively, the comma implies a type parameter list, but (b + 3) cannot be a type so there's an error there.

I believe the spec's current wording permits both approaches.

[adonovan]

Looks like the comma causes it to be parsed as a type parameter list, even though the parenexpr holds a term not a type:

[griesemer]

Yes, the comma forces parsing as a type parameter list which is expected in the current implementation. The question is what is the most consistent error to report: is it an invalid type constraint or an invalid array length.

[griesemer]

The parsers accept a larger language than what is syntactically permitted, both to simplify the implementation and make it more efficient, and also to be more error-tolerant. We guarantee that code is correct after type-checking. This specific issue may not be the only one where printing produces syntactically invalid code after parsing.

Certainly would be nice to fix but also not urgent or important. Marking as backlog.