This change introduces experimental AST support for the "declaring
constructors" (DeCo) feature and wires the parser to build explicit
nodes for primary constructors. The new behavior is gated by a static
switch:
analyzer/dart/ast/ast.dart: useDeclaringConstructorsAst (experimental)
When the flag is **true** (must be set once before parsing and not
changed thereafter):
* Declarations expose structured bodies:
- `ClassDeclaration.body` / `MixinDeclaration.body`
- `EnumDeclaration.body`
- `ExtensionDeclaration.body`
- `ExtensionTypeDeclaration.body`
Legacy bracket/members tokens (`leftBracket`, `members`,
`rightBracket`) throw `UnsupportedError`.
* The declaration "name" area is modeled as `namePart: ClassNamePart`,
which is either:
- `NameWithTypeParameters` (e.g., `A<T>`), or
- `PrimaryConstructorDeclaration` (e.g., `A<T>.named(...)`).
Legacy fields (`name`, `typeParameters`) throw `UnsupportedError`.
For extension types, `representation` also throws under the flag and
is represented via `PrimaryConstructorDeclaration`.
* Child iteration (`childEntities`), visiting (`visitChildren`), and
token boundaries (`endToken`) adapt to the new shape.
Parser changes:
* Build `PrimaryConstructorDeclaration` / `PrimaryConstructorName` via a
new `_PrimaryConstructorBuilder`. For extension types, the existing
representation syntax is mapped to a primary constructor when the flag
is enabled.
* Add `NullValue.PrimaryConstructor` to the stack listener to carry the
parsed primary constructor through the builder pipeline.
Implementation details:
* Introduce small internal *Stub classes (e.g., `ClassBodyImplStub`,
`EnumBodyImplStub`, `RepresentationDeclarationImplStub`) to satisfy
constructor requirements for fields that are not surfaced under the
current mode, avoiding API churn while the feature is gated.
* Update API surface to make `body` and `namePart` available on the
affected declarations and document which legacy getters throw when the
flag is enabled.
Rationale:
This lays the AST groundwork for DeCo while preserving backwards
compatibility by default. Consumers can opt in to validate workflows and
migrate incrementally.
Bug: https://github.com/dart-lang/sdk/issues/61701
Change-Id: Ie5300b2958383bf3b2e9d6faf138bb7f74c9d7ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455820
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This adds an ExperimentalFeatures interface to make the parser able to know which experimental feature is currently supported. This generalizes the existing dependency on patterns and enhanced parts, and facilitates reporting of unsupported features directly within the parser, avoid the need for duplicate handling of this within analyzer+CFE.
Change-Id: If1752745ee4d753e4b463f2017f440223cd98737
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455700
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The CFE `Template` class now exposes a `withArguments` method, which
behaves the same as `withArgumetsOld` method, but accepts named
arguments rather than positional arguments.
In follow-up CLs, I will adjust the names of these positional
parameters to be more descriptive, and update call sites to use
`withArguments` rather than `withArgumentsOld`. This should make the
call sites clearer and easier to understand.
Change-Id: I6a6a6964638e0312003aa622c5e0fef782b8d979
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447963
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is the beginning of a series of CLs intended to change the CFE's
`withArguments` methods (used for diagnostic reporting) so that they
accept named parameters rather than positional parameters. This change
will carry two major benefits:
- It will reduce the risk of mistakes when reporting diagnostics.
- It will make the analyzer and CFE diagnostic reporting mechanisms
more similar, paving the way for sharing more diagnostic reporting
code in the future.
As a first step, this CL renames the old `withArguments` methods to
`withArgumentsOld` and updates call sites. In follow-up CLs, I will
introduce new `withArguments` methods that accept named arguments, and
migrate call sites to use them.
Change-Id: I6a6a6964f4130cdb732b14d515e0ad8f2b65dc26
Tested: standard trybots
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447625
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@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, references to the `message...` declarations that define
errors are changed to the equivalent `code...` declarations. There is
no functional change, since these declarations denote the same
constant object. In a follow-up CL, the `message...` declarations will
be removed.
Tested: standard trybots
Change-Id: I44d4b3cffb768b908d4341a7851f270db6caa87b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/443183
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jackson Gardner <jacksongardner@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Paul Berry <paulberry@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 references to the `template...` declarations that
define errors are changed to the equivalent `code...`
declarations. There is no functional change, since these declarations
denote the same constant object. In follow-up CLs, the `template...`
declarations will be removed, and then a similar set of changes will
be made to replace references to `message...` declarations with
references to the corresponding `code...` declaration.
Tested: normal trybots
Change-Id: I178bd2072349088f342bc39cfc789bcb5c7ef19e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442732
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
This splits handleEndingBinaryExpression into two new listeners handleDotAccess for `.` and `?.` access and handleCascadeAccess for `..` and `?..`, both with an explicit `isNullAware` flag.
This is a step towards handling `a.b` different from `a + b` in the parser such that listeners don't have to create a value for `b` the works in both use cases; in the first is just a named operation performed on the receiver, whereas in the second case it is a full expression in its own right.
Change-Id: I04ec80401f8f2dbb8dffa86543c434e530b18cf7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442821
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This type argument was never used. Removing it should make it easier
to make changes to the front end error message logic (and associated
code generator), which I intend to do as part of a long term plan to
make the analyzer and front end error reporting systems more
consistent, and eventually merge them.
Change-Id: I994cd2a74c5fd77df192f6a1f2dde46ba8a31883
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442723
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This moves implementation handling calls to handleEndingBinaryExpression into its own method in the subclasses. This splits the `.`, `.?`, `..` and `?..` from the real binary expressions.
This is a step towards handling `a.b` different from `a + b` in the parser such that listeners don't have to create a value for `b` the works in both use cases; in the first is just a named operation performed on the receiver, whereas in the second case it is a full expression in its own right.
Change-Id: I5291439f333971b7ff482325a15502e4d8a66b71
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442820
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This change mainly has side effects for code completion, making sure we're suggesting the right members. When the user writes something like `E e = .^` where `^` is the cursor, they're most likely intending to write a dot shorthand.
So this parser recovery change ensures that we recover as a dot shorthand node and not as a prefixed identifier (missing it's target) in the analyzer. We don't need special casing in the code completion pass to handle dot shorthands in the prefixed identifier visitor now.
The CFE should have no notable changes, but I added a few tests since it uncovered some crashing behavior. The duplicate errors have always been the case even prior to this change.
Bug: https://github.com/dart-lang/sdk/issues/59836
Change-Id: I6c4a9f2c8cc376e4dedd715af76967da471aa681
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/439140
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This gets rid of (what is described in commented code as)
InstantiatedTypeWithArgumentsTest, Subtype1TestCacheLookup, BoolTest.
Running this through the benchmarker like this:
```
out/ReleaseX64/dart-sdk/bin/dart pkg/front_end/tool/benchmarker.dart \
--snapshot=pkg/analysis_server/bin/server.aot.1 \
--snapshot=pkg/analysis_server/bin/server.aot.2 \
--arguments="--disable-file-byte-store" \
--arguments="--train-using" \
--arguments="pkg/front_end/lib/"
```
(there `server.aot.1` is without this CL and `server.aot.2` is with)
I get:
```
msec task-clock:u: -0.9614% +/- 0.3557% (-78.23 +/- 28.95) (8136.80 -> 8058.57)
cycles:u: -1.0257% +/- 0.3626% (-348283560.66 +/- 123129577.69) (33955507948.94 -> 33607224388.28)
instructions:u: -1.0595% +/- 0.0662% (-479117043.74 +/- 29935955.93) (45220681554.68 -> 44741564510.94)
seconds time elapsed: -0.9548% +/- 0.3540% (-0.08 +/- 0.03) (8.15 -> 8.07)
seconds user: -1.0649% +/- 0.4031% (-0.08 +/- 0.03) (7.80 -> 7.72)
Scavenge( new space) goes from 130 to 129
Notice combined GC time goes from 2613 ms to 2608 ms (notice only 1 run each).
```
`StackImpl.pop` as reported by `perf report --no-children` goes from
0.81% to 0.34% (and I'm unsure why the apparent change seen as a whole
is quite a bit bigger).
Change-Id: Ife36da11215e0c8aa706d945f0ee5018ad03ab91
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432340
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Context:
A while back, I inserted a synthetic token in the parser to allow us to parse without crashing the analyzer while I worked on the CFE. Now that both implementations are up and working, we can remove this synthetic token and allow the parser to parse as if we had enabled dot shorthands by default, and produce an error if the experiment isn't enabled.
This change allows a bunch of different language tests to start passing since they were blocked on the weird synthetic token messing up the parsing stream.
Bug: https://github.com/dart-lang/sdk/issues/59758
Change-Id: I792e3b917a76241b04ee708de06f670bbde64036
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/423563
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Parse and build dot shorthand invocations that are constant.
Added a new listener to handle and store the const-ness. It didn't feel right re-using any of the other `beginConstPattern` methods.
Added an error message if invoking a non-const constructor where we expected a const constructor.
Bug: https://github.com/dart-lang/sdk/issues/59758
Change-Id: I8551e3b8f71e89a69d090510bb64694d5e09247d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/414660
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
The parser was still WIP and was emitting an extra error, so this CL removes that error so tests can start passing and so I can properly test the new implementation e2e.
It still needs some fixes after the analyzer implementation is complete. The current extra synthetic tokens added in the parser are temporary to prevent crashes on the analyzer side when the experiment flag is turned off. But it works fine for now, and I'll clean it up in a CL when the feature is complete.
Bug: https://github.com/dart-lang/sdk/issues/59758
Change-Id: I83d8c840f66bedff4aa27a737a3f57e77d3973b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/412344
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Extension methods can no longer be disabled. This CL removes the option
from the scanner config and the parser related specific recovery.
It also removes any specific (triggered) test of the functionality.
A follow-up CL will do the same for NNBD.
Change-Id: Ia385008e5ed1333fb37697b8fe424b8759bce198
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403581
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Autogenerated files was formatted with the new style, so if one for
instance formatted the file via the IDE or by saying
`out/ReleaseX64/dart-sdk/bin/dart format pkg/front_end/lib/` we'd get
*a lot* of changes which isn't great.
This CL sets the formatter version for the auto-generated files,
hopefully avoiding such things.
Change-Id: I4f92aafde7c77e7c78179f78bf821979a25ec12c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/398884
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
With 0ca1ff2281 fixing the reason why we
had `isA2` we can get rid of it. One 100-run-each-benchmark of compiling
a fixed version of the CFE with the current version of the CFE I get
```
msec task-clock:u: -0.3133% +/- 0.2298% (-13.22 +/- 9.70)
cycles:u: -0.4109% +/- 0.2303% (-71702583.62 +/- 40176749.86)
instructions:u: -0.0150% +/- 0.0002% (-3206465.75 +/- 50567.00)
branch-misses:u: -0.9597% +/- 0.8046% (-615355.48 +/- 515877.98)
seconds time elapsed: -0.3138% +/- 0.2297% (-0.01 +/- 0.01)
seconds user: -0.2991% +/- 0.2978% (-0.01 +/- 0.01)
```
(the only real thing to look at here is likely the `instructions:u`
going down by ~3.2 mio.)
For anyone interested:
Manualy testing what 0ca1ff2281 did vs
the commit before (by running it 5 times each by hand through perf stat)
I get
instructions:u: -0.0831338% +/- 0.00115149% (-1.78503e+07 +/- 247246)
(i.e. almost 18 mio less instructions).
Change-Id: I01600c33364933da262b3354298255e8b2df8afb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/394101
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Before, when parsing a new style typedef without an identifier (e.g.
`typedef = whatnot`) it concluded that the token after the equal-sign
wasn't an equal sign an that it thus had to be an old style typedef,
followed by recovery there.
This CL makes the recovery insert an identifier after `typedef` (what
the recovery of the old style actually did too), and then parse it as a
new style typedef.
This causes the previous many errors to just be `Expected an identifier,
but got '='.`
It is furthermore verified that the parsing of such a case is ~the same
as when having an indentifier.
Fixes https://github.com/dart-lang/sdk/issues/56912
Change-Id: I5cde1f29839555b1d6027a7d040dc6f60ac614a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392560
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Johnni Winther