This is part of a series of CLs that will standardize CFE error
reporting to always use `codeFoo.withArguments(...)` when reporting
errors that take arguments and `codeFoo` when reporting errors that
don't take arguments, rather than `templateFoo.withArguments(...)`
when reporting errors that take arguments and `messageFoo` when
reporting errors that don't take arguments. This change will have two
advantages:
- It will lend greater consistency to the CFE codebase, by allowing
the same `code...` objects to be used both to name error codes
(e.g., in test expectations) and to report errors. This will allow
everything associated with a certain error code to be found using a
single invocation of "Find References" in the editor, rather than
having to search separately for uses of the code and the message or
template.
- It should hopefully make the experience of writing code that reports
errors more pleasant, since it will no longer be necessary to look
up an error to see whether it takes arguments before using it;
instead, the developer will be able to type the name of the message
`code...` declaration, and then use autocompletion to see whether
`.withArguments(...)` is required.
In this CL, the code generator for error messages is changed so that
both `template...` and `code...` declarations have the static type
`Template` (and, indeed, refer to the same constant
object). Previously, `code...` declarations had the static type
`Code`, and referred to a constant object with runtime type
`Code`. This will allow uses of `template...` to be replaced with
`code...`. In follow-up CLs, the uses of `template...` will be changed
to `code...`, and the `template...` declarations will be removed.
Since the `toString` methods on `Template` and `Code` differ, I had to
make some changes to ID tests and parser tests, both of which depend
on the behavior of `toString`:
- For ID tests, I was able to preserve the existing test expectations
by modifying the `errorsToText` function (in
`pkg/front_end/lib/src/testing/id_testing_utils.dart`).
- For parser tests, I wasn't able to find an easy way to preserve the
existing test expectations, so I updated the expectations to match
the new behavior.
Change-Id: I8a461d451b06dd2f88b3e59f0cb2153711b09461
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442731
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This splits handleEndingBinaryExpression into two new listeners handleDotAccess for `.` and `?.` access and handleCascadeAccess for `..` and `?..`, both with an explicit `isNullAware` flag.
This is a step towards handling `a.b` different from `a + b` in the parser such that listeners don't have to create a value for `b` the works in both use cases; in the first is just a named operation performed on the receiver, whereas in the second case it is a full expression in its own right.
Change-Id: I04ec80401f8f2dbb8dffa86543c434e530b18cf7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442821
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
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>
This allows the parser to parse constant patterns at lower precedence
level in order to recognize more expressions in this context. To
support this, _parsePrecedenceExpressionLoop special cases a few cases
that should _not_ be parsed as expression in a constant pattern context.
Closes#50996
Change-Id: I43bb0ce52d366bd2dfcf47e12eec5883402f668a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/282100
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Johnni Winther