When the parser sends events to the listener some events has a pair of
parameters, `beginToken` and `endToken`. Most of these are constructed
in such a way that the `beginToken` is the first token and the
`endToken` is the last token in that construct. This is for instance the
case with `endClassDeclaration`.
It was, however, not the case for `endMetadata` where `endToken` instead
was the next token *not* in the metadata.
In this CL I've found a changed the following to point to the last token
in the construct instead of the next token not in the construct and
renamed the parameter where it made sense:
* `endAssert` --- and renamed `semicolonToken` (which only pointed to
a semicolon for statements) to `endToken`.
* `endAwaitExpression`
* `endConstLiteral` --- and renamed `token` to `endToken`
* `endConstructorReference`
* `endFieldInitializer` --- and renamed `token` to `endToken`
* `endForIn`
* `endForInBody` --- and renamed `token` to `endToken`
* `endForStatement`
* `endForStatementBody` --- and renamed `token` to `endToken`
* `endFunctionExpression` --- and renamed `token` to `endToken`
* `endInitializer` --- and renamed `token` to `endToken`
* `endInitializers`
* `endInvalidAwaitExpression`
* `endMetadata`
* `endSwitchCase`
* `endTopLevelDeclaration` --- and renamed `nextToken` to `endToken`
* `endWhileStatement`
* `endWhileStatementBody` --- and renamed `token` to `endToken`
* `handleNoConstructorReferenceContinuationAfterTypeArguments`
In the few places in listeners where these values were used I've mostly
updated to do e.g. `endToken.text!` to retain the current behavior.
Change-Id: I25495e160d1eec5c75bcf1313b512cd04bcb1533
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364322
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The listener API for variable patterns is split into three separate
functions, to handle the three separate behaviors:
- `handleAssignedVariablePattern` for variable names appearing in an
assignment context (these assign to an existing variable upon a
successful match).
- `handleDeclaredVariablePattern` for variable declarations appearing
in a declaration or matching context (these cause a new variable
name to come into scope).
- `handleWildcardPattern` for wildcards in any context (these don't
capture the matched value).
Also, responsibility is shifted to the parser for reporting the
following error conditions:
- VariablePatternKeywordInDeclarationContext (e.g.
`var (var x) = ...;`)
- PatternAssignmentDeclaresVariable (e.g. `[x, var y] = ...;`)
Previously these errors were detected by the implementations, and
weren't fully covering all possible error scenarios.
In the case of VariablePatternKeywordInDeclarationContext, the
listener method `handleDeclaredVariablePattern` is called instead of
`handleAssignedVariablePattern`. This ensures that no tokens are
dropped from the analyzer AST. The CFE uses the `inAssignmentPattern`
argument of `handleDeclaredVariablePattern` to distinguish this error
recovery case from a legitimate declared variable pattern.
Fixes#51868.
Bug: https://github.com/dart-lang/sdk/issues/51868
Change-Id: I28ec679b73d64033166721c6460be35f15e23171
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291583
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Variable patterns behave so differently inside a patternAssignment
that we may want to represent them using different AST nodes inside
the analyzer/CFE. This change adds a boolean flag allowing the
implementation to know what kind of variable pattern it's looking at
when parsing occurs.
Bug: https://github.com/dart-lang/sdk/issues/50035
Change-Id: I60adf2865bbe24f85b72a79b1360833bf823bd67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/273829
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The parser now handles maps that contain rest patterns with
subpatterns (e.g. `{'foo': _, ...var rest}`). Even though this is
invalid Dart, it still makes sense for the parser to handle it so that
we can generate higher quality error messages.
The shared type analyzer now generates an error,
`restPatternWithSubPatternInMap`, if it encounters this error
condition.
Change-Id: I7f447bde28e646593aa432e3e5ad1f5e415bdd30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/273283
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Jens Johansen