This updates the handling of initializers in primary constructor body declarations. The parser is updated to pass the `:` token, similar to what is done for the regular constructors. The CFE is updated to use a boolean, rather that the `:` token (or a synthetic token), to determine whether initializers should be processed as part of building the outline. The parsing of initializers is done using the `:` token, if any, now pass both from regular constructors and primary constructor body declarations.
Closes#63468
Change-Id: Ia266dea7946b30b02d56f9f3cedf40848c4ee440
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507401
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
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 CL enables the primary constructors feature by default in Dart 3.13.
The primary constructors feature is a brevity feature. There are no new semantics, but it allows us to express declarations in a less verbose way.
This feature allows one constructor and a set of instance variables to be specified in the header of a declaration.
Currently a declaration with a constructor and some fields is written as:
```dart
// Current syntax.
class Point {
int x;
int y;
Point(this.x, this.y);
}
```
With a primary constructor, we would write the above as:
```
class Point(var int x, var int y);
```
If a primary constructor needs an initializer list or a body, they can be
specified inside the class using the `this` body syntax:
```dart
class Point(var int x, var int y) {
this : assert(x >= 0) {
print('Point created at $x, $y');
}
}
```
As part of this feature, you can also use the `new` and `factory` keywords to
declare constructors in the class body without repeating the class name:
```dart
class Point {
int x, y;
// Equivalent to Point(this.x, this.y)
new(this.x, this.y);
// Equivalent to Point.origin()
new origin() : x = 0, y = 0;
// Equivalent to factory Point.clone(Point other)
factory clone(Point other) => Point(other.x, other.y);
}
```
To learn more about the feature, check out the feature specification located here: https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md
Tested: Has existing language, CFE, analyzer, analysis server tests.
Bug: https://github.com/dart-lang/sdk/issues/61524
Change-Id: I296f2fcd918b87bf2a1dd00256340759866c2423
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489241
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Ben Konyi <bkonyi@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>
I changed the parsing of const dot shorthands to parse the entire selector chain in `parsePrecedenceExpression` rather than parsing them in `parseConstExpression`. We were originally parsing the initial expression before the `.` and only flagging that as a dot shorthand which prevented any chaining on const constructors. Const expressions with chained methods/property accesses were not being flagged as a dot shorthand so we weren’t saving the context type properly which led to producing the “unknown context type” error.
Before:
```
class C {
const new someConstCtor();
C method() => this;
}
C c = const .someConstCtor.method();
// (const .someConstCtor) is parsed and handled as a const constructor
// (const .someConstCtor) is handled as a dot shorthand, context is
// saved on only this AST and not the outer chain.
// Then we parse the rest of the selector chain (.method())
//
// Error: No context type for (const .someConstCtor.method())
```
After:
```
class C {
const new someConstCtor();
C method() => this;
}
C c = const .someConstCtor.method();
// (const .someConstCtor) is parsed and handled as a const constructor.
// Then we parse the rest of the selector chain (.method())
// (const .someConstCtor.method()) is handled as a dot shorthand, context is saved for this outer node.
//
// OK. No error because we are able to retrieve the type for the
// entire dot shorthand chain.
```
Fixes: https://github.com/dart-lang/sdk/issues/63119
Change-Id: I3308d8eb7ce101466be257aba6b5448921bff136
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495560
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@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 enables primary-constructors and private-named-parameters by default in CFE expectation tests.
Test are update accordingly; some are annotated with `@dart=3.10` to opt out of the features, some cloned to support both opt-in and opt-out, and some are modified to use opt-in before only.
Part of #61700
Change-Id: Iae9e5d188d9b49d4264d17dc989dbaeee7321845
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/479620
Reviewed-by: Konstantin Shcheglov <scheglov@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 updating front end parser
expectations.
Change-Id: I6a6a6964699f00e7e91af2e682ce1baa1846ca13
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478060
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Changes the `front_end` and `_fe_analyzer_shared` code that reports
the following diagnostics so that it uses `withArguments` rather than
`withArgumentsOld`:
- `expectedButGot`
- `expectedButGot2`
- `expectedAfterButGot`
- `expectedToken`
- `unmatchedToken`
- `constFieldWithoutInitializer`
- `finalFieldWithoutInitializer`
- `superclassHasNoMethod`
- `unavailableDartLibrary`
- `unsupportedPlatformDartLibraryImport`
These messages required special care because they are translated into
analyzer diagnostics by the analyzer method
`FastaErrorReporter.reportByCode`, and the logic to do the translation
depends on the exact parameter names used by the messages.
For some of the messages I've clarified the parameter names and
updated `FastaErrorReporter.reportByCode` accordingly. For others, I
left the parameter names as is.
Change-Id: I6a6a696481c75f4cbb198d1e012aa1ca4294ed61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/476323
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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 and then running the script
`use_new_with_arguments.dart`.
Change-Id: I6a6a6964d05c7481d886252f77d5c90c9e63a155
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/476340
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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, then running the script
`use_new_with_arguments.dart`, then updating parser testcases by
supplying `-DupdateExpectations=true` to
`pkg/front_end/test/unit_test_suites.dart`.
Change-Id: I6a6a6964232d48c9e6d01accc31b5c5acbd9435f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/476150
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reports `extraneousModifier` when the primary constructors feature is
enabled and `final` or `var` is used in a formal parameter declaration
that's not part of a primary constructor.
Change-Id: I32e530cc60b89a7385e382def7b4c33e90199a7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/475343
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This [handlePositionalArgument] and [handlePositionalRecordField] methods to the parser listener, allowing listeners to normals arguments and record fields
Change-Id: I3947e196dafffea2ab383f797904c857db8327ce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469620
Reviewed-by: Jens Johansen <jensj@google.com>
This adds error recovery for explicitly naming a constructor 'new' with the new constructor syntax. This is not allowed so an error is explicitly emitted while handling this.
Change-Id: Iac3045f04c9c75779ffb2d9e866817ac43ab5d26
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463281
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This improves the error recovery for syntax like `new C.named();`. Previously, the parser would derail with messages like "A method declaration needs an explicit list of parameters" and a cascade of other errors.
With this change the qualified name is recognized as an attemp to write the name of the constructor, reporting that qualified names are not allowed in this case.
Part of https://github.com/dart-lang/sdk/issues/61699
Change-Id: Id1062aac3b90db8d2346013cf8a0bd9a541b9a3c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463020
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds a beginConstructor listener method and calls this before constructor instead of beginMethod. This makes it possible for listeners to fully separate handling of constructors from methods.
Change-Id: Ibcbcf76ccb6d97314d395c4c0efcb4f9d073519a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462140
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@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 aligns the call to `Listener.beginEnum*` with that of `Listener.beginClass*`. A `beginExtensionPrelude` is added, replacing the call to `beginUncategorizedTopLevelDeclaration` and matching the call to `beginClassOrMixinOrNamedMixinApplicationPrelude` for classes. `beginEnumDeclaration` and `endEnumDeclaration` replaces the `beginEnum`/`endEnum` pair, matching the calls to `beginClassDeclaration`/`endClassDeclaration` with the name and type parameters now available at `beginEnumDeclaration` similar to `beginClassDeclaration`. This helps supporting primary constructors in enums because the enclosing enum can be prepared in `beginEnumDeclaration` before calls to `endPrimaryConstructor`.
Change-Id: I9c1ad55db6e3fcc09ed5ac0c05f5d50db95ae608
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458200
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Previous recovery resulted in an outline change and very bad performance
as a result (e.g. in the analyzer).
This takes an analyzer server benchmark from:
```
$ out/ReleaseX64/dart-sdk/bin/dart pkg/analysis_server/tool/benchmark_tools/big_chain_benchmark/lsp_typing_temporarily_missing_end_brace_in_string_interpolation.dart --types=ImportCycleExportChain --sizes=1024
[...]
==================================
size 1024 / CodeType.ImportCycleExportChain:
Initial analysis: 16.173549
Completion after change: 7.824299
Fully done after change: 24.515470
peak virtual memory size: 3941 MB
total program size (virtual): 3941 MB
peak resident set size ("high water mark"): 2125 MB
size of memory portions (rss): 2125 MB
==================================
```
to
```
==================================
size 1024 / CodeType.ImportCycleExportChain:
Initial analysis: 16.989549
Completion after change: 0.332792
Fully done after change: 0.333113
peak virtual memory size: 3817 MB
total program size (virtual): 3635 MB
peak resident set size ("high water mark"): 1983 MB
size of memory portions (rss): 1803 MB
==================================
```
Change-Id: I38478acbd9b0449c6962da7543aa4bd39b22d004
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453341
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Modifies the scanner logic that reports the `AsciiControlCharacter`
error message so that it invokes it using `withArguments` (which
accepts named arguments) rather than the old `withArgumentsOld` (which
accepts positional arguments). The name of the parameter accepted by
this error message has been changed to `character`, to reflect its
usage, and parameter documentation has been added.
This is an exercise to verify that the front end's new `withArguments`
error reporting infrastructure is fully functional. In follow-up CLs,
I plan to introduce some tools to partially automate the process of
updating front end code to use `withArguments` rather than
`withArgumentsOld`.
However, if anyone wishes to start migrating error reporting to the
new scheme before that, they are welcome to do so.
Change-Id: I6a6a6964fc87d6bf551ec4891c56e6106dd9c098
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/448239
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Konstantin Shcheglov