The old code tries to determine something by using a forwarding listener
without forwarding to anything. It leaked a rewrite though, meaning that
the rewrite stayed, but the error given when rewriting wasn't passed on.
When then parsing it with the real listener, the rewrite was in effect
and there was no error to report. In total no errors were reported.
This fixes the issue by undoing any rewrites in this situation.
Fixes https://github.com/dart-lang/sdk/issues/47020
Change-Id: I5342ae6969f00dea830fb7abb30f21932907b8bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/236540
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This adds support for the `import augment <uri>` import syntax when
the 'macros' experiment is enabled.
The CL also include propagation of the augment modifier on class methods
which was missed in a previous CL.
Change-Id: Ic843e7e34559bcac728c810590f34b727b5f7090
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/234401
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This changes the way the 'augment' modifier is handled in the parser.
Instead of being special cased for class declarations, it is now a
built-in identifier recognized only when the scanner is configured to
support augmentation libraries.
The change supports the used of the 'augment' modifier on not only
class declarations but also mixin and member declarations, as needed
for supporting macros.
Change-Id: I2679d198dea360900cfc478fae9c1660702a8a02
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233887
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This CL add the 'macros' experiment and adds support for the `macro`
modifier on class declarations. This is part of the prototyping of
the static meta-programming feature.
Change-Id: Ie4b8c5443fda3813307ea076c315baad6a90c3e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/224205
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Since the check or the absence of the check for a named argument
appearing before a positional parameter is feature-specific
considering the language feature that allows placing the named
arguments anywhere, it should be performed by the listeners of the
parser and guarded by an experiment flag, in alignment with other
experimental featuers. This CL moves the check and the reporting of
the error from the parser into the Analyzer, so that later this check
can be skipped if the corresponding experiment flag is enabled.
Part of https://github.com/dart-lang/sdk/issues/47451.
Change-Id: Ib795d418af429ee04ecfff6dfa71ec1e836fe798
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216640
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Chloe Stefantsova <dmitryas@google.com>
E.g. if reporting a missing ";" after a SyntheticStringToken (e.g. a
inserted identifier) before this CL it would go to the next token and
say we expected the ";" after that, when really we expected it *before*
that token.
Change-Id: I2c358e017edb2f661e307eba03dddaee889086d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205799
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When the parser encounters a `<` after an expression, it must choose
whether to interpret it as a relational operator or a <typeArguments>
selector. The disambiguation rule is: if the `<` and the tokens
following it *can* be parsed as <typeArguments>, and the token that
follows is a member of a privileged set of tokens, then it is treated
as a <typeArguments> selector; otherwise it is treated as a relational
operator.
This change reduces the privileged set of tokens to the following:
- the "continuation tokens" `(`, `.`, `==`, and `!=`
- the "stop tokens" `)`, `]`, `}`, `;`, `:`, and `,`
The names "continuation tokens" and "stop tokens" reflect the
rationale for choosing these tokens:
- Continuation tokens are tokens that we can reasonably imagine a
programmer wanting to place after a type argument selector to
*continue* the expression. For example, `if (List<int> == T) ...`
is allowed.
- Stop tokens are tokens that can't possibly follow a `>` that is a
relational operator, because they *stop* the expression that's in
progress. For example, `var x = List<int>;` is allowed.
If a user wants to follow a <typeArguments> selector with a token
other than the ones above, they'll have to parenthesize the
expression. So for example, if they want to do `List<int> + 1` (which
could be meaningful if an extension method defined `operator +` for
the type `Type`), they will have to use parentheses, and instead write
`(List<int>) + 1`.
Bug: https://github.com/dart-lang/language/issues/1806
Change-Id: I2816cdac24e55eac3cb3e9920e276404c1228d46
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210941
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Instead of getting errors like this:
```
t.dart:6:4: Error: Expected an identifier, but got 'class'.
Try inserting an identifier before 'class'.
#class.foo;
^^^^^
t.dart:6:4: Error: Expected ';' after this.
#class.foo;
^^^^^
t.dart:6:4: Error: 'class' can't be used as an identifier because it's a keyword.
Try renaming this to be an identifier that isn't a keyword.
#class.foo;
^^^^^
t.dart:6:4: Error: Getter not found: 'class'.
#class.foo;
^^^^^
```
we get something like this:
```
t.dart:6:4: Error: 'class' can't be used as an identifier because it's a keyword.
Try renaming this to be an identifier that isn't a keyword.
#class.foo;
^^^^^
```
https://github.com/dart-lang/sdk/issues/46208https://github.com/dart-lang/sdk/issues/46207
Change-Id: I79da73e600f732d10020c871d11e11c3f7fe740a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203686
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The new "constructor tearoffs" feature includes the ability to use the
`new` keyword in a place where an identifier is expected, and that
identifier could denote a constructor name. We handle this by
replacing the `new` keyword token with an identifier token whose
identifier string is `new` (this should ease the burden on the
implementations, since they are already set up to handle constructor
names that are identifiers).
Since all such situations follow a `.`, and `new` was never previously
allowed after a `.`, the parser treats `new` as an identifier in any
situation where it could possibly refer to a constructor, regardless
of whether the "constructor tearoffs" feature is enabled. (This
should allow for easier error recovery in the situation where the user
tries to use the feature with a language feature that does not support
it). It is up to the client to report an error if the feature is
disabled.
In this CL, I've implemented logic for the analyzer to choose whether
to report an error based on whether the feature is enabled. I've
implemented logic for the CFE to report the error unconditionally.
Bug: https://github.com/dart-lang/sdk/issues/46020, https://github.com/dart-lang/sdk/issues/46044
Change-Id: I36a496688400d2d9f699dd42be4d0ba620cda244
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201961
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL adds parser support for use of `<typeArguments>` as a
selector. This allows expressions like `List<int>` (type literal with
type arguments), `f<int>` (function tear-off with type arguments),
`C.m<int>` (static method tear-off with type arguments), `EXPR.m<int>`
(instance method tear-off with type arguments), and `EXPR<int>`
(tear-off of `.call` method with type arguments).
I will add parser support for `.new` as a constructor name in a
follow-up CL.
Change-Id: I157e732276421e8c3fd20c38c67ae9643993bd85
Bug: https://github.com/dart-lang/sdk/issues/46020, https://github.com/dart-lang/sdk/issues/46044.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/197102
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Before this CL we had 2 tests:
* One for messages (not checked in presubmit)
* One for experimental features (checked in presubmit)
And had nothing for:
* direct parser ast helper
* parser test listener
* parser test parser
These are now replaced by a single tool that checks all five and is
run in presubmit.
Change-Id: I885f74cc26dd75722804366e1f8bfc4616ad03ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200187
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL creates a new test suite running through *.equivalence_info
(yaml) files where one specifies a number of files that are supposed to
parse 'the same' in the sense that it gives 'the same' listener events
modulo whatever the yaml file specifies is ok is not the same.
This could for instance - and is in the tests added here - be to not
include data after the parenthesis (as it often includes tokens),
ignoring `handleParenthesizedExpression` (as for instance `a < b` and
`(a < b)` should probably parse the same and ignoring
`handleRecoverableError`.
This might be a bit basic, but as future needs come up we can make this
fit our needs.
Change-Id: I4f5dfde9e916a95742f49e104fb5c751a8a9b921
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/197381
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
A few places in the parser we call `computeTypeParamOrArg` and then
either use the result or not depending on whether there's a `(` after
it. That doesn't work well when `computeTypeParamOrArg` does recovery
by for instance inserting a > though.
This CL fixes that - at least in the places we know about.
Fixes#45848.
Change-Id: Id4b62b965131031f43c8ada0fe05045fc9834db3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/197360
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Make the parser handle metadata properly according to the spec.
There has been some confusion in regards to metadata because
https://github.com/dart-lang/language/blob/master/accepted/future-releases/small-features-21Q1/feature-specification.md
(used to) say we needed a spec update.
That was done in the parser in
https://dart-review.googlesource.com/c/sdk/+/182668
but really that made the parser adhere to the spec as it was which is
also correct (as the spec change wasn't needed at all).
The parser also needs to be able to skip metadata, though, and that
wasn't done it that CL which caused the issues in
https://github.com/dart-lang/sdk/issues/45120
The work directly in this CL is:
* Add lots of comments to parseMetadata to make them more up-to-date with
the spec.
* Fix skipMetadata to correspond to parseMetadata.
* Tests verifying that 45120 is fixed in the parser and that metadata in
general works as expected in the parser.
(In working on this, the future specification was corrected to say that the
spec did not need updating. Thanks to Erik for the quick turn-around
there).
Bug: #45120
Change-Id: Id1e4912cac7e5d9113efe083b3ecd06e6834a16e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190880
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Jens Johansen