Add a syntactic diagnostic for extension type augmentations that declare
representation fields. Extension type augmentations may augment the
declaration, but they must not redeclare the representation.
Thread an explicit parser option through primary constructor parsing so
extension type augmentations can omit a representation without producing
the usual missing-primary-constructor diagnostics, while still reporting
an error when a representation is present.
Register the new diagnostic in the shared and analyzer generated
diagnostic tables and add it to fix status tracking.
Change-Id: I84815bb0669a76126564e590760e93096a3af046
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505860
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This adds error recovery for mixin and extension declarations with primary constructors. This avoids cascading errors when primary constructors are used with these declarations which do not support primary constructors.
Closes#63157
Change-Id: I17bfab4a7eabac1c75e7cfb580295dcf619c991d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499180
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Permit `abstract` on top-level variable declarations when the
augmentations feature is enabled. Previously the parser always reported
`abstract` as extraneous at the top level, which rejected valid syntax
and dropped the modifier before later stages could see it.
Thread the abstract token through top-level field parsing, record it on
`TopLevelVariableDeclaration`, and pass it through the front-end
builders. Reorder the field callback arguments so `augment` precedes
`abstract`, matching the augmentation grammar for incomplete top-level
variables and keeping the parser, listener, and outline plumbing
consistent.
Change-Id: I680414a746b707d483e485702685c95f28a9c9ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494564
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This removes the remaining support for `augment super` in the parser, analyzer and CFE.
`augment super` will not be part of the augmentations feature.
Change-Id: Ie8a185bba067ab6ecf3b3229ecc20d5c284842bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/493401
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
A flag that tells whether constructor is in an abstract class, enum or mixin was not correctly passed for primary constructors. This flag determines whether constructor tear-off lowerings are created for backends that use this, such dart2js and dartdevc.
The parser listener is updated to pass a DeclarationKind for primary constructors, similar to what is already done for regular constructors. The enable the CFE to pass the correct flag.
Change-Id: I114417795ae276dfeab9f10a0b0fcbcd2dbfc00b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/490541
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This is one of several planned batches of changes to transition the
front end (and related packages) away from the old `withArgumentsOld`
diagnostic reporting method, and to the new `withArguments`
method. The difference between the two is that `withArguments` has
named parameters rather than positional ones, so (a) it's less likely
for parameters to be mixed up, and (b) it's compatible with the
calling conventions used by analyzer diagnostics.
As part of this transition, I'm taking the opportunity to rename the
parameters themselves (since the names previously were restricted to a
very small set of possibilities based on type), and to document them
in `messages.yaml`. To avoid fatigue (both for myself and code
reviewers), I've chosen to break the change into many smaller batches.
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator, running the script
`use_new_with_arguments.dart`, and then regenerating front end parser
test expectations.
Change-Id: I6a6a696461f9184a42d646fab6a593bcb4abdf4a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478000
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This merges endX methods for non-top-level members into endMethod, endConstructor, endFactory and endFields.
These methods now have a DeclarationKind parameter that can be used to distinguish them.
Change-Id: I458d37a70b6c7839612f7199dad95f9a61e76e7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462120
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This updates the parser suites to use the FolderOptions already used by other expectation tests. This aligns the support for configuration tests in particular wrt experimental flags.
As a consequence of this change, all parser suite enable patterns for parser. Since the test setup didn't use experimental flags previously, newly added tests didn't use the current default, which is with pattern support. Since we don't have any tests explicitly for non-pattern support, all tests are updated to support patterns as it at least aligns with the default for current and future code.
Change-Id: I80ee769b35e74a0d111135ca4690983872a63623
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459741
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
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 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>
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>
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>
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>
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>
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>
Konstantin Shcheglov