Added error messages for when users try to use invalid mixins + a language test that tests that (and tests in each of the front ends).
Removed the tokens from the parser listeners.
Removed all behaviours and error reporting related to these invalid mixins.
Change-Id: I558595826dae7e2c176bd1929e97caa2335c167c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290614
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Johnni Winther <johnniwinther@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 behaviour `skipOuterPattern` needs to be kept in sync with that of
`parsePrimaryPattern`. To reduce the risk of these to going out of
sync, I've added logic to `parsePrimaryPattern` so that after parsing
an `outerPattern`, it asserts that `skipOuterPattern` would have
behaved appropriately.
This required adding some logic to `parser_test_parser.dart` so that
these calls to `skipOuterPattern` don't show up in front_end parser
expectations files. (If they did show up, they would lead to
failures, since the bots run the front_end parser tests with
assertions both enabled and disabled).
Bug: https://github.com/dart-lang/sdk/issues/50035
Change-Id: Ida3a37532bb9a86837e70b5ec1aa2e557e3cb769
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/271163
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This adds a new generated file into _fe_analyzer_shared for the
experimental flags. This is now used by the parser when generating
messages about features not being available.
The default implementation uses whether the feature is enabled by default
or not, to emit different messages. This change will therefore ensure
that when a missing feature changes from 'experimental' to
'enabled by default', the message reported by the parser will be
updated accordingly. Currently errors are only reported from the parser
on features that are enabled by default, so the message for experimental
features is not currently used.
The reporting is performed through the Listener, such that
implementations can override the reporting to improve the messaging.
This is done in the CFE where the message is improved to take into
account whether the language version is explicit in the parsed library.
In response to https://github.com/dart-lang/sdk/issues/46329
Change-Id: Ief812817c7eb4b1e433389f6f49d6a1f77604fa7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/269860
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change restores `parseParenthesizedExpressionOrRecordLiteral`,
`parseArguments`, and `parseArgumentsRest` to the way they looked
prior to adding parser support, and instead adds new methods
`parseParenthesizedPatternOrRecordPattern` and
`parseExtractorPatternRest` that are specialized for patterns parsing.
Bug: https://github.com/dart-lang/sdk/issues/50035
Change-Id: I104e031a796ef7f217cd427e1a9ae94a04dafa7b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261620
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
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>
This adds support for parsing `argument super` as its own expression
in augmentation libraries. This is not handled (correctly) by the
ast builders of analyzer and cfe yet.
Change-Id: Ibe67ad9daf56c82e8ec94f16d468e6b0d8f84d22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244922
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@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>
This expands the front_end's and analyzer's support for doc comment
references to include `/// [a.b.c]`. Such a reference must be to a
getter, setter, method, or constructor of a class or extension which
is referenced with an import prefix, such as `[async.Future.value]`.
In the existing support for two words, the two words are named
"prefix" and "token". In a three-word reference, the _first_ word
must be an import prefix, but I've chosen the new names,
"leadingPrefix", "prefix", and "token", to minimize the change.
If an improved change is desirable, considering the names from scratch,
I might choose something like "prefix", "container", and "identifier".
But these names will be applied to one-word and two-word references as
well, so `[async.Future]`, a reference to the Future class provided by
an import prefixed as 'async', would have a 'prefix' of null, a
'container' of 'async', and an identifier of 'Future'.
Bug: https://github.com/dart-lang/sdk/issues/47444
Change-Id: I7758ec16872677221c456dd1dd6dc2a4df0f6102
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/223661
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Paul Berry