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>
Report new diagnostics when an introductory function, member, or factory
constructor is still incomplete after applying all augmentations.
Keep the existing missing-body diagnostics for declarations that have no
augmentations, but report augmentation-specific diagnostics when an
augmentation chain exists and none of the fragments provides a body or
factory redirection.
Move the checks into error verification so that extension and extension
type members can participate in augmentation completion before reporting
the existing abstract-member diagnostics. Also suppress the
corresponding shared parser diagnostic when it is reported by the
verifier.
Consolidate body-related tests by declaration shape instead of by
individual diagnostic. This keeps missing bodies, external bodies,
augmentation completion, and already-complete checks side by side,
making the interaction between these rules easier to review and extend.
Move the constructorAlreadyComplete coverage from its dedicated test
file into constructor_body_test.dart, and add the factory body
completeness cases there as well. Add executable_body_test.dart for
function and member body coverage, including top-level declarations,
static members, extension members, and extension type members.
Add diagnostic definitions and fix-status entries for the new
diagnostics.
Change-Id: I9ee803c1e767ff47a608c86413ef7ffc71518cfd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503540
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
This CL adds an implementation of anonymous `=>` methods in the CFE
which is sufficiently complete to handle the existing test cases in
language/anonymous_methods/expression.
Coverage is handled by adding magic comments to ignore the fact that new
code is not covered by existing testcases. This will be settled in a
separate CL.
To keep the failures visible, the failures in configurations
dart2js-hostasserts-linux-d8-try, dart2js-linux-chrome-try,
dart2js-minified-linux-d8-try, and ddc-linux-chrome-try have not been
approved. It seems likely to me that those are bugs in dart2js and in
DDC.
Change-Id: Ia70fedd4de6166d6a3bf8a108f49728b6e16c9f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494440
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This uses the previously added `%ignore=` syntax to enable validation of
the diagnostic documentation for several diagnostics that were
previously not being validated.
In the process I also cleaned up a few of the code snippets used in
those docs in order to minimize the number of ignored diagnostics.
I removed the newly validated diagnostics from the list in the validator,
and improved the comments for the ones that are still being ignored to
show why they're ignored and point to some possible future remediations
that would allow them to also be validated.
Change-Id: I46b0eeaab86740ba82784987e84f3e93046d39f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494941
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This uses MemberLookupResult instead of Builder as the result for BodyBuilderContext.lookupConstructor. This allows for a more precise handling of error cases and avoids reporting cascading error in case of duplicate constructors.
Change-Id: I465747883af594870cb0663e80a188e6dd1b552b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486202
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This reports an error on assignment to primary constructor parameters in field initializers and initializer lists.
The change includes a rewrite of the handle of variable lookup and use that fixes and existing problem in pattern assignment, where it was until now possible to assign to const and final variable in some cases.
Part of #61700
Change-Id: Icfe566fd03b805e8fc21c4b373dbb8ab3dab4b7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/484141
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds reporting of a primary constructor body declaration without a primary constructor declaration.
This current spec does not require an error on multiple primary constructor body declaration, but should, since this is not a all well-defined. An error is reported for this as well and the language test is updated to expect this error.
Part #61700
Change-Id: I88700d46971ac46b4c1a3d2e77980f642ee12fc9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478620
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This CL adds some elements of the implementation of anonymous methods:
- _fe.../messages.yaml: Add error message about wrong parameter list.
- analysis_server/.../error_fix_status.yaml: Add status of above error.
- analyzer/.../src/.../ast.dart: Add new AST classes AnonymousArrowBody
AnonymousBlockBody, AnonymousMethodBody, AnonymousMethodInvocation.
- analyzer/.../to_source_visitor.dart: Add new `visit` methods.
- analyzer/.../ast_builder.dart: add `endAnonymousMethodInvocation`.
- analyzer/.../resolver.dart: add new `visit` methods.
Change-Id: Ifa562c653f608884319ad9a1d87e169d9fac4b75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/475043
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the code that reports the following errors to use
`withArguments` instead of `withArgumentsOld`:
- `experimentNotEnabled`
- `experimentNotEnabledOffByDefault`
This was not possible to do in an automated fashion, because these two
errors are shared between the analyzer and CFE, and the analyzer code
to report these errors had already been translated to use
`withArguments`, even though the errors still used the placeholder
parameter names `string` and `string2`. In this CL I've given the
parameters meaningful names and manually updated all the usages in
both the analyzer and CFE.
Change-Id: I6a6a6964644d720f163d87b586489376ea7be385
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478160
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This moves the analyzer diagnostics for classes with a primary constructor and a non-redirecting generative constructor to the shared messages, and adds support for reporting it in the CFE.
Enum constructors, which are part of the test added, are now also always marked as constant.
Part of #61700
Change-Id: I29e5354ac2c4089a395b3e5a1d7bcccce0edccec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478381
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 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 usages of `IdentifierContext.recoveryTemplate` and
`Parser.reportRecoverableErrorWithToken`'s `template` argument so that
they format diagnostic messages using `withArguments` rather than
`withArgumentsOld`.
Also changes the following diagnostic messages so that their `lexeme`
argument is documented (these are the values that get passed, under
various circumstances, to `IdentifierContext.recoveryTemplate` and
`Parser.reportRecoverableErrorWithToken`'s `template` argument):
- `expectedIdentifierButGotKeyword`
- `duplicatedModifier`
- `extraneousModifier`
- `extraneousModifierInExtension`
- `extraneousModifierInExtensionType`
- `extraneousModifierInPrimaryConstructor`
- `invalidOperator`
- `expectedDeclaration`
- `expectedClassMember`
- `expectedIdentifier`
- `expectedString`
- `expectedType`
- `unexpectedToken`
- `builtInIdentifierAsType`
- `builtInIdentifierInDeclaration`
Finally, changes all the direct uses of these diagnostics to use
`withArguments` as well.
Change-Id: I6a6a6964cf5c1cee8709118c8cbf23537fb066a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/476152
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Updates the `messages.yaml` files to use `camelCase` naming
conventions for message keys, `sharedName` fields, and `analyzerCode`
fields. This eliminates a significant inconsistency between the
diagnostic code formats in the analyzer and the front end.
This CL was created automatically by running the script
`pkg/analyzer_utilities/tool/messages/switch_to_camel_case.dart`.
Change-Id: I6a6a6964cc9e5b2ff9d09875d49f0f3d3f404121
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467060
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Adds `type:` entries to the analyzer-style `messages.yaml` files.
Currently the only function of these entries is that they are checked
against the diagnostic types implied by the diagnostic's class name
(diagnostics under the heading `CompileTimeErrorCode` must have type
`compileTimeError`, those under `StaticWarningCode` must have type
`staticWarning`, etc).
In a follow-up CL I will change the code generation logic to these
`type:` entries instead of inferring the type from the diagnostic
code's class. This will pave the way for removing the notion of
diagnostic code class entirely.
This change was produced automatically by running the script
`pkg/analyzer_utilities/tool/messages/add_types_to_yaml.dart`.
Change-Id: I6a6a69646958a34e24ccbf69cb96ead9d7e7865b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464282
Reviewed-by: Konstantin Shcheglov <scheglov@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>
Changes `pkg/_fe_analyzer_shared/messages.yaml` so that every message
has a `hasPublishedDocs` entry with a value of either `true` or
`false`. Previously, only entries with a value of `true` appeared in
this file; a default value of `false` was assumed.
Also changes the code generation logic in for diagnostic messages so
that:
- It no longer assumes `false` when there is no `hasPublishedDocs`
entry.
- The `hasPublishedDocs` field is only accessible on messages deriving
from `MessageWithAnalyzerCode`, since these are the only messages
for which this field makes sense.
Also changes the logic in `messages_suite.dart` so that both `false`
and `true` values are accepted for `hasPublishedDocs`.
This change brings the conventions for `hasPublishedDocs` into harmony
between `pkg/_fe_analyzer_shared/messages.yaml` and
`pkg/analyzer/messages.yaml`.
Change-Id: I6a6a6964b5e256eb9fd6bdabadbb9392f05076f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458071
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the shared error code `FieldInitializerOutsideConstructor` so
that it generates
`CompileTimeErrorCode.fieldInitializerOutsideConstructor` rather than
`ParserErrorCode.fieldInitializerOutsideConstructor`, replacing the
old analyzer-only
`CompileTimeErrorCode.fieldInitializerOutsideConstructor`. This
eliminates unnecessary code duplication between
`pkg/analyzer/messages.yaml` and
`pkg/_fe_analyzer_shared/messages.yaml`.
Removes logic from `pkg/analyzer/lib/src/fasta/ast_builder.dart` that
previously reported
`ParserErrorCode.fieldInitializerOutsideConstructor`. This logic was
unreliable (it only triggered for method parameters and local function
declarations) and unnecessary (because it duplicated logic in the
`ErrorVerifier`). This improves the user experience by eliminating
duplicate errors.
Change-Id: I6a6a69648a9958db531bb0c84bc604358dd0af6f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455466
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Replaces the `index` entries in
`pkg/_fe_analyzer_shared/messages.yaml` with an automatic mechanism
that happens during code generation.
It is no longer necessary to specify an index when adding a shared
diagnostic code to `pkg/_fe_analyzer_shared/messages.yaml`. During
code generation, each shared message automatically associated with an
entry in a generated enum, `SharedCode`. When it comes time to
translate a shared message from a front end code to an analyzer code,
the enum index is used to look it up the corresponding analyzer error
code in the analyzer's `sharedAnalyzerCodes` table.
Change-Id: I6a6a69649356f13e2143f9c954cdf0413cccd07c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454685
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Moves all the diagnostics that are shared between the analyzer and the
CFE from `pkg/front_end/messages.yaml` to
`pkg/_fe_analyzer_shared/messages.yaml`.
This CL was generated by the following steps:
- Run the `move_shared_diagnostics.dart` script introduced in
https://dart-review.googlesource.com/c/sdk/+/448606.
- Manually modify `pkg/front_end/messages.status` to reflect the
diagnostics that have been moved.
Change-Id: I6a6a6964d618089f8fe8d447b4344800bad5d532
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/448660
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Konstantin Shcheglov