This adds the enclosingDeclarationName to the beginMethod of the
parser listener.
This enables the removal BuilderFactory.currentTypeParameterScopeBuilder.
Change-Id: Ie2bec9432c20b8bdbd62a14e8a65c272179d4698
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383182
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This changes the BodyBuilder to create FunctionTypeParameter instead
of FormalParameterBuilder for "parameters" in function types. This
avoids the creation of unnecessary VariableDeclaration nodes
function types.
The types of these VariableDeclarations where created before the type
variable scope was completed, introducing an artificial dependency on
the pending nullability computation.
Change-Id: Ie1203fa4c78a27f3e7a0dfad16725cbbde24a6a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381143
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@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 passes the first token of these top level declaration directly
to the endX listener method.
In the CFE this is used to ensure that can handle the new modifiers in
the textual outline. Furthermore, support for extension types is added
and having an "unknown chunk" now results in an error. The latter should
help us keep the textual outline up-to-date wrt new features.
Change-Id: I813d6162b6cba0a2bf550ed33a6091abf9bf49f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324702
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This changes the parser to always interpret `extension type` as the
start of an extension type declaration.
Recovery is added to handle missing identifier, primary constructor,
parameter constructor parameters, and extension type declaration body.
Change-Id: I98cac0b2641167c4708fa20b22f0de0a70336457
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321704
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This is not the flag you're looking for.
The 'extension-types' flag was used for an early experiment that is
not directly related to the Extension Types feature currently being
developed. The current feature uses the 'inline-class' flag.
Change-Id: Icbb6c3828c41e743e726161b17da4c7784a2c677
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316380
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Record parsing is generally done by accepting what comes after as
something that can follow a record type.
To support something like `List<List<(int, int)>>` we have to accept
`>>` after a record type.
When parsing something like `(whatever here) >> 42;` we thus say that
it's a record --- even if the stuff inside is a recovered type. We
inherit the `recovered` mark, but will say we're a record type.
This CL fixes parsing this by returning that it's _not_ a record type
when seing the `>>` (an a few others) if what's inside is recovered.
This _might_ mean worse recovery in some situations but fixes parsing
valid code such as `(() => print("hello")) >> 42;`.
Fix: https://github.com/dart-lang/sdk/issues/52365
Change-Id: Ie56958f5503e74d37c181c0b71003b8e61209c6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303242
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously, if a pattern variable declaration appeared outside of a
function or method, the parser would get very confused. Now it
recognizes the situation, issues a comprehensible error message, and
replaces the pattern with a synthetic identifier token so that the
analyzer AST is somewhat sensible.
Fixes#51322.
Bug: https://github.com/dart-lang/sdk/issues/51322
Change-Id: Ica5f060cb483a39c4e50942d639939b1fab40bea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293087
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I have not yet run the analyzer's generators just to keep the generated
version of the changes out of the review.
There are 10 parser diagnostics that are not being documented:
- ParserErrorCode.INVALID_CONSTANT_CONST_PREFIX
- ParserErrorCode.INVALID_CONSTANT_PATTERN_BINARY
- ParserErrorCode.INVALID_CONSTANT_PATTERN_DUPLICATE_CONST
- ParserErrorCode.INVALID_CONSTANT_PATTERN_EMPTY_RECORD_LITERAL
- ParserErrorCode.INVALID_CONSTANT_PATTERN_GENERIC
- ParserErrorCode.INVALID_CONSTANT_PATTERN_NEGATION
- ParserErrorCode.INVALID_CONSTANT_PATTERN_UNARY
- ParserErrorCode.FINAL_MIXIN_CLASS
- ParserErrorCode.INTERFACE_MIXIN_CLASS
- ParserErrorCode.SEALED_MIXIN_CLASS
Let me know if you think any of those need documentation.
Change-Id: I904ecaeb07383fedcdc5c7c286f36d635ed8684e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286524
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Marya Belanger <mbelanger@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
* required is a modifier when followed by [record type] `?`.
* Parse record type as record type if followed by `super` or `?` `super`
or `?` `this`.
* Typedef with record type follow by `?`.
* Parse record type as record type in get/set with async/sync/sync*.
* Parse record type as record type when followed by `>>=` or `>>>=`
(for weird formatted use in typedefs).
Change-Id: I19e208497e28780fb1505139c488e943751cce25
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/263123
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Johnni Winther