The parser now supports the following subset of the parser grammar:
- logical-or and logical-and patterns (called "binary patterns" to
reflect analyzer nomenclature)
- extractor patterns
- cast patterns
- list patterns
- map patterns
- null-assert patterns
- null-check patterns
- variable patterns where the variable is preceded by `var`, `final`,
<type>, or `final <type>`
- if-case statements (and if-case within collections); without guards
- record patterns
- parenthesized patterns
- constant patterns where the constant is a plain expression not
beginning with `const` (booleanLiteral, nullLiteral, numericLiteral,
stringLiteral, identifier, or qualifiedName).
- relational patterns
- patterns in switch statements
- integration with the analyzer's AstBuilder class
Not implemented yet:
- constant patterns beginning with `const`
- variable patterns where the variable is a single identifier (note:
this means that `_` is currently interpreted as a constant pattern
rather than a "wildcard" variable pattern)
- guards (a.k.a. "when clauses")
- switch expressions
- pattern variable declarations
- patterns appearing in "for loop parts"
- pattern assignment
- several error checking and error recovery scenarios (see TODO
comments)
- integration with the front_end's BodyBuilder class
- front_end style parser tests (currently the feature is tested using
analyzer unit tests only)
Note that in patterns, `as` binds has higher precedence than `&` and
`|`, whereas in expressions, `&` and `|` have higher precedence than
`as`. To reflect this, a new precedence has been added,
CAST_PATTERN_PRECEDENCE.
To reduce the risk to users during parser development, the parser
currently only attempts to parse patterns when instructed to do so
(i.e. when the language feature is enabled). In the long term, I
intend to change the parser so that it always attempts to parse
patterns, and it is the responsibility of its listener to report
errors if patterns are used without enabling the language feature.
Change-Id: I360b535d2a6ebd35a0ee4d066b06e3ae8e3121ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261020
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
For ease in code review, I've made all the changes that affect test
expectations files here, in a way that can easily be confirmed during
code review to have no functional effect on parser semantics.
This will be followed by a change that introduces parser support for
patterns, but doesn't affect test expectations.
Change-Id: I830600c1ae89447c7745bfae6fd91c379b6e05d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261022
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Most of these arguments are flowing through to a `--packages` argument
which allows passing the `package_config.json` file. In the long term we
should remove the `.packages` file entirely.
TEST=None, the change should have no visible impact.
Change-Id: I60a8b175d5e217a85588bbcb91cc5095514066b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211503
Auto-Submit: Nate Bosch <nbosch@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This CL removes async markers where await wasn't used.
In a few cases this also meant the ability to make the procedure not
return a future at all.
Also - at least on the VM with my benchmark run on my PC - returning
new Future.value(whatever) in a non-async procedure is faster than
returning whatever in an async procedure.
TEST=CI and existing tests.
Change-Id: I4ba888313c87de76bb0ca02c19eb1ab45f168a85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213480
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This flag prepares for the removal of the special case of implicit
creation syntax, `foo<bar>.baz()`, which with constructor-tearoffs
doesn't have to be a creation expression. Since both the analyzer
and the CFE needs to support parsering without special casing
before it can be removed, the flag is added to ensure both
implementations will agree on what the future parser behavior will be.
The CL hard-wires the CFE use of the parser to a single constant value.
Change-Id: I04724f039d2e698f3cf67e8b0b56dfa7e96ed3b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211000
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This CL avoids the infinite loop created by allowing the parser
to parse it as a complex type (despite no actual name after it) and
adds a few asserts in an attempt to catch rewriting on eof (setting a
token after eof).
Fixes#42229Fixes#44477
Change-Id: Ie2da0957894067a3d4748cb6384bc9d6cf32c215
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150521
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
* Add mechanisms to try out a recovery and only perform it if is
successful.
* Recover written out binary operators, e.g. "a xor b", "a or b" etc.
This fixes#26810 and is also how these operators are written in e.g.
Kotlin. This might be somewhat controversial though.
* Adds a mechanism to _replace_ a token by another token.
This might be controversial.
It is done because just inserting the operator causes the same rewrite
to be attempted on the same token stream several times (at least with
the way the token stream is parsed via the CFE) in turn causing it to
be recovered *sometimes*. This is now avoided by actually replacing
the token.
Change-Id: Icfa806045575d2aa2e5f35126708651b275bcf84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162003
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL:
* Changes the events so beginX and endX events always comes in pairs
(though technically not right as some specific events can be beginX
endY --- but in those cases it is at least documented and used in code
that actually tests it).
-> This entails adding some events and converting something from
"beginX" to "handleX" instead.
* Adds a utility that can generate an AST of sorts directly from the
parser via a listener using the begin/end matching (and knowing of the
specific ones that doesn't match directly).
* Adds a test that checks that - at least for all tested (50,000+) files
- the AST actually generate "correctly", i.e. matches up begin/ends
and ends up with a single top entry "CompilationUnit".
* Adds a different visualization to the parser listener events by
displaying the "AST directly from the parser" in a UI that can be
navigated. The visualization may not be the best, but it's certainly
a stepping stone.
Change-Id: I9b27f7bbf3be442adc92f357c7b3c46da6f84cf7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159664
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This reverts commit bc4893a3b3.
The previous attempt failed because when we check if something is a
conditional expression we used a rewriter that didn't actually rewrite.
This further down the line (still checking if we can parse the expression)
results in errors occurring (that wouldn't have occurred if the rewrite
had happened) and the conclusion was thus that it wasn't a conditional
expression and we parsed it as a null-aware index operator (which gave
errors because it wasn't).
This 2nd try solves it by having a rewriter that actually rewrites,
but then allows to undo the rewrites after we're done parsing.
Change-Id: Ide3c0d6a870d4dc18b6d9475b0227d93c733dc7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136624
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I am trying to migrate all of the negative tests to something more
precise. As far as I can tell, this test stopped being useful with Dart
2.0. Now that all compilation errors are reported eagerly, the file
simply doesn't run at all. It's now just another test of an unresolved
identifier.
(This is a good example of *why* I want to get rid of negative tests.
This test silently went from a desired runtime failure to a compile-time
failure.)
Change-Id: Iec3cdd32a15612c0760119e92d618e3a5ba1f5ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125555
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Pass variance data to field in TypeParameter through the listeners.
ast_to_text will print variances for classes and mixins if specified.
Avoids serialization/deserialization (impl in future CL).
Change-Id: I298537604823710f0d30001f4cb5f1e81530959f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118464
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Splits strong_test into 4 shards. This test took 4+ minutes locally with
the fast_strong_test and analyze_test ticking in at ~1:45. This change
makes local testing of frontend unittests take 2 instead of 4 minutes in
total.
Change-Id: Id6015de86d547b209a699b1e5196b3edad1e6977
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114501
Reviewed-by: Jens Johansen <jensj@google.com>
This CL adds a simple spell-checker, adds a spell-checking-phase to
messages_test to spell-check our messages, adds a new test that
spell-check our dart-code and fixes a lot of spelling mistakes / typos.
Change-Id: I8943a5bd67970e9a8a775251ae0aa97799eab097
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112346
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Paul Berry