eernstg
commented
9 months ago Let's consider the example program:
void a() {
b..c = () => 0..d;
}In the specified grammar, a <cascadeAssignment> has the following syntax:
<cascadeAssignment> ::= <assignmentOperator> <expressionWithoutCascade>This implies that the specified grammar must parse a prefix of () => 0..d using <expressionWithoutCascade>. The language specification grammar will happily derive () => 0..d from <expressionWithoutCascade>, because of the rampant ambiguity introduced by <functionExpression>.
The grammar in Dart.g will also parse a prefix of () => 0..d using <expressionWithoutCascade>, but in this case we will use <functionExpressionWithoutCascade> to parse the body (a prefix of 0..d), which yields 0.
So, indeed, the Dart.g grammar will give rise to a parsing with the structure (b..c = () => 0)..d, and the grammar in the language specification will only arrive at b..c = (() => 0..d) because it will parse () => 0..d as an "expression without cascade".
I think the construct () => 0..d is not a particularly convincing "expression without cascade", so the intended parse is probably going to be as follows:
void main() {
// Likely intended structure:
var v1 = b
..c = () => 0
..d;
// Less likely:
var v2 = b
..c = (() => 0..d);
}I think this serves as yet another argument in favor of doing what Dart.g has done for years (that is, changing <functionExpression> to <functionPrimary> in <primary>, adding <functionExpression> to <expression>, and adding <functionExpressionWithoutCascade> to <expressionWithoutCascade>; finally, changing <functionExpression> and the one without cascades such that they only derive => functions).
I'll transfer this issue to the language repo, given that there is no reasonable solution (I think) without grammar changes.
munificent
Consider the following program:
Which leads to the following parse trees:
It looks like the analyzer and a Dart.g-based parser disagree on the expression that
..dis meant to belong to.The analyzer appears to assume the following:
And the Dart.g grammar appears to assume the following: