When analyzing the CFE with StableAnalysis in AOT with GC disabled:
* This CL reduces the combined cost of `popTypedList2` from ~501 million
instructions to ~150 million instructions according to
`valgrind --tool=callgrind`.
* Total savings, via `valgrind --tool=callgrind`, is reported as
~359 million instructions.
* Total savings, via `perf stat`, is reported as
~367 million instructions (see also below).
A benchmark run with 5 runs each gives this (but note that the normal gc
runs should mostly be ignored):
With normal GC:
```
page-faults:u: 2.5544% +/- 0.0884% (4895.60 +/- 169.43) (191651.60 -> 196547.20)
instructions:u: -1.7106% +/- 0.0039% (-990609348.00 +/- 2286578.79) (57909229892.40 -> 56918620544.40)
branch-misses:u: -4.0211% +/- 2.2322% (-7537436.00 +/- 4184151.25) (187447442.80 -> 179910006.80)
maxRssKbytes: -1.1530% +/- 0.0148% (-7169.60 +/- 91.81) (621801.60 -> 614632.00)
maxRssBytes: -1.1530% +/- 0.0148% (-7341670.40 +/- 94008.95) (636724838.40 -> 629383168.00)
Comparing GC data:
Scavenge( new space) goes from 171 to 169
MarkSweep( promotion) goes from 17 to 16
MarkSweep( old space) goes from 0 to 1
Notice combined GC time goes from 3636 ms to 3507 ms (notice only 1 run each).
```
```
With GC disabled:
page-faults:u: -1.7322% +/- 0.0001% (-21490.20 +/- 1.49) (1240629.60 -> 1219139.40)
instructions:u: -0.9185% +/- 0.0021% (-367119249.20 +/- 829664.80) (39970048410.80 -> 39602929161.60)
maxRssKbytes: -1.7226% +/- 0.0012% (-85733.60 +/- 60.60) (4977076.00 -> 4891342.40)
maxRssBytes: -1.7226% +/- 0.0012% (-87791206.40 +/- 62052.71) (5096525824.00 -> 5008734617.60)
```
Change-Id: I85eae091cc45d5fb2820fbd263d022619c9875f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/490122
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Moves the bulk of the business logic for type analyzing await
expressions from the analyzer and front_end codebases into the shared
`TypeAnalyzer` class. There is no functional change.
This paves the way for fixing
https://github.com/dart-lang/sdk/issues/62889 (Unsound type promotion
in inner async/generator functions), which will require the type
analysis of await expressions to be integrated more closely with flow
analysis. Sharing the type analysis logic will avoid the need to do
that integration twice.
Change-Id: I9f8770ce8127a960b746a89ee3e370ed6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489480
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In the front end, the logic for determining when to report a
`voidExpression` error is integrated into the resolution pass. The
method `InferenceVisitorImpl.inferExpression` accepts a named
parameter `isVoidAllowed`; if the value is `false`, and the
expression's static type is `void`, an error will be reported. The
parameter is optional with a default value of `false`; this means that
the parameter only needs to be specified in the situations where
`void` is allowed; this aligns well with the language spec, which
lists the situations in which an expression may have type `void`, and
declares that in all other situations it is an error.
This change integrates the front end's `isVoidAllowed` boolean with
the shared type analysis logic in `package:_fe_analyzer_shared`, so
that the shared logic can specify when a subexpression should not be
void. This will pave the way for fixing
https://github.com/dart-lang/sdk/issues/62939 (Switch scrutinees of
type void are erroneously accepted by the front end). It also will
pave the way for sharing the logic for analyzing await expressions,
which will make it easier to fix
https://github.com/dart-lang/sdk/issues/62889 (Unsound type promotion
in inner async/generator functions).
Note that the analyzer doesn't use the `isVoidAllowed` parameter; it
has its own mechanism for detecting invalid uses of void (which is
more ad hoc). In the long run I would like to make the analyzer's
mechanism more like the front end's, for easier code sharing; see
https://github.com/dart-lang/sdk/issues/62942.
Change-Id: Ibb8dd072d6aff980d7df0b2e94f434ee6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489501
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The `Match.operator[]` does the same thing and is
generally recommended (and shorter).
(I want to deprecate `group` and `groups`)
Tested: Refactoring.
CoreLibraryReviewExempt: Calling equivalent function.
Change-Id: I4c758968ae622fe16b7322be1b29b05b91e7fcd9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489021
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Prior to the introduction of the "anonymous methods" experiment, a
`return` statement and a `throw` expression behaved identically from
the point of view of flow analysis, since both had the effect of
causing control flow to jump outside the function that flow analysis
is analyzing*. So they were both implemented using a single flow
analysis method called `handleExit`.
(*Technically a `return` from an inner function could lead to a point
in an enclosing function, and a `throw` could lead to a `catch`, but
flow analysis handles both of these possibilities using a conservative
approximation (see the `FlowModel.conservativeJoin` method), rather
than modeling them as direct jumps.
But a `return` statement inside a block-bodied anonymous method is
known to jump directly to the code that follows the anonymous method
invocation, so `handleExit` is not the correct way to model it.
Prior to this CL, this was handled in the analyzer's resolver (the
corresponding CFE logic hasn't been written yet) by treating anonymous
methods as a kind of loop construct. When visiting a return statement,
the resolver would find the innermost enclosing function expression,
local function, or block-bodied anonymous method; if it was a
block-bodied anonymous method, then it would achieve the desired
effect by calling `FlowAnalysis.handleBreak` rather than
`FlowAnalysis.handleExit`. This was an abstraction leak, because in
effect it put some of the business logic of flow analysis in its
client (namely, the knowledge that return statements in block-bodied
anonymous methods have a different flow analysis behavior than return
statements elsewhere).
This CL moves this business logic into flow analysis through the
addition of a `FlowAnalysis.handleReturn` method.
Flow analysis keeps track of whether the current point in the code
being analyzed is inside a block-bodied anonymous method using the new
field `FlowAnalysis._anonymousBlockContext`, which points to either
`null` or an instance of a new type, `_AnonymousBlockContext`. This
field is updated in proper nesting fashion by the methods:
- `anonymousBlockBody_begin`
- `anonymousBlockBody_end`
- `_functionExpression_begin`
- `_functionExpression_end`
Finally, some aspects of
https://dart-review.googlesource.com/c/sdk/+/482786 that are no longer
necessary are rolled back:
- A node no longer needs to be passed to `anonymousBlockBody_begin`.
- The mapping from nodes to branch targets is changed back to a
mapping from statements to branch targets, since it no longer needs
to accept an anonymous method invocation as a key.
Change-Id: I8b0f35cab016fc5bd609cfa1581ecaa36a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/485020
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL adds support for anonymous block bodies (as in `e.{...}`) by
generalizing the flow analysis to handle begin/end of anonymous block
bodies and treating them similarly to labeled statements (and treating
`return` statements using `handleBreak`). It generalizes `handleBreak`
and the internal make `_StatementToContext` to handle `Node` keys rather
than just `Statement` keys, such that an anonymous block body can be the
context. It adds a `bodyContext` instance variable to
`AnonymousBodyImpl` to be used during flow analysis of anonymous block
bodies. `BodyInferenceContext` gets a new factory constructor in order
to allow an anonymous block body to be the context. Finally,
`ErrorVerifier` is generalized to handle the case where a return
statement is returning from an anonymous block body.
Change-Id: I04bc3c852611dbefb885afce655dc00054709fb7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482786
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
I initially thought it had a bug, because I didn't
recognize that it would scan the same characters more than once.
So changed to never scanning the same character more than once,
for a completely linear pass, and some small tweaks.
Change-Id: If24955cf3b3d22cc2818a0751d14a68661b4219b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486982
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
The RegEx engine in the VM was updated in
e443b89f23 which caused the analyzer
analyzing the CFE to use ~150 mio instructions more.
Part of this was an increased cost in formatList which before cost ~40
mio and after cost 114 mio (analyzing the cfe).
This CL removes the regex from the method reducing the cost to ~19 mio,
saving ~95 mio instructions.
Numbers from `valgrind --tool=callgrind`.
Change-Id: I7c72d9e4ed3a21e627a3c846428c2e62965d4602
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486782
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@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 sets the `experimentReleaseVersion` of `primary-constructors` to `3.12.0`. This enables tests, outside the SDK in particular, to reliably pin tests that prepare for the feature to language version 3.12.
Change-Id: I85565b9434c052398be5a7839ce5731d71162416
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482784
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
Reviewed-by: Sarah Zakarias <zarah@google.com>
This change makes two changes to how flow analysis works for post
increment/decrement operations.
Firstly, in the anaylzer implementation, the check against
`inference_update_4` is removed. Previously, the analyzer called
`FlowAnalysis.postIncDec` when `inference_update_4` was enabled, and
`FlowAnalysis.write` when it was disabled. This was unnecessary, since
that language feature had no effect on the flow analysis of post
increment/decrement. Furthermore, it was a violation of separation of
concerns, because even if that language feature _had_ had an effect on
the flow analysis of post increment/decrement, it would have been the
job of flow analysis to implement that effect, not the
client. Fortunately, `FlowAnalysis.write` happens to have the same
behavior as `FlowAnalysis.postIncDec` when `inference_update_4` is
disabled, so there is no behavioral change; this is purely a clean-up.
Secondly, the return type of `FlowAnalysis.postIncDec` is changed from
`ExpressionInfo?` to `void`, and the calls to `storeExpressionInfo`
are removed from call sites. Previously, `FlowAnalysis.postIncDec`
always returned `null`, so again, there is no behavioral change.
Note that these changes do not affect the front_end in any way, since
it de-sugars `x++` and `x--` to equivalent "let" expressions before
invoking flow analysis. Those let expressions, fortunately, have the
same flow analysis effect as `FlowAnalysis.postIncDec`. Thanks to the
test added in https://dart-review.googlesource.com/c/sdk/+/482342, we
have enough language test coverage to confirm this.
Change-Id: I6a6a6964253394c71e6bc72d801d9044b1b1ae30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482541
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The CFE and analyzer diagnostic code base classes (`Template` and
`DiagnosticWithArguments`, respectively) should always be instantiated
with a function type, to ensure that their `withArguments` getter can
be invoked as though it's a method. Accordingly, it would seem
sensible for their type parameter to be declared as `extends
Function`.
But there's a big downside to declaring them in that way: a derived
class that forgot to specify a type parameter would be implicitly
instantiated with the type `Function`, allowing `withArguments` to be
invoked dynamically (and thus bypassing all of that member's
compile-time type safety).
To mitigate that risk, this CL changes the base classes so that their
type parameters are declared as `extends Object` instead.
Change-Id: I6a6a696464ff5cfb1d383099aae6d2e5467a55e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481166
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Removes the call to `storeExpressionInfo` from
`NullShortingMixin.finishNullShorting`, putting it instead in
overrides in the derived classes: `ResolverVisitor`,
`_MiniAstTypeAnalyzer`, and `InferenceVisitorImpl`.
With this change, there are no more calls to `getExpressionInfo` or
`storeExpressionInfo` in the shared type analysis logic; they are all
in clients.
This opens the door to changing how the clients track flow analysis
expression info.
Change-Id: I6a6a696480c8ce5f353f3c37ee2215f5bf9d606d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480802
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Removes calls to `getExpressionInfo` and `storeExpressionInfo` out of
`NullShortingMixin.startNullShorting`.
These calls are moved to the methods that call `startNullShorting`.
This reduces the reliance of `pkg/_fe_analyzer_shared` on
`getExpressionInfo` and `storeExpressionInfo`, which paves the way for
moving the exprssion info map to clients.
Change-Id: I6a6a69641d10db8acb0e1e45a26ca383ac9fe3ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480781
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Adds a `flowAnalysisInfo` field to the `ExpressionTypeAnalysisResult`
class. This field is populated with the `ExpressionInfo` that flow
analysis associates with the expression (or `null` if flow analysis
doesn't associate any `ExpressionInfo` with the expression).
The information in this field replicates the information stored in
`_FlowAnalysisImpl._expressionInfoMap`. Eventually all uses of
`_FlowAnalysisImpl._expressionInfoMap` will be transitioned to using
`ExpressionTypeAnalysisResult.flowAnalysisInfo` instead, and then
`_FlowAnalysisImpl._expressionInfoMap` will be removed.
Assertions are added to help ensure that the new field is populated
with sensible data:
- In the "mini-AST" representation used by `_fe_analyzer_shared` for
testing, an assertion checks that the value of
`ExpressionTypeAnalysisResult.flowAnalysisInfo` matches the value
stored in `_FlowAnalysisImpl._expressionInfoMap`.
- In the analyzer and front end, such an assertion wouldn't add any
value (since the front end and the analyzer make use of
`ExpressionTypeAnalysisResult` solely for interacting with shared
code), however assertions are added to verify the analyzer and front
end's conventions for handling expression infos for rewritten ASTs.
Change-Id: I6a6a696415fe48f5e24c33c50f1bccf55fff0f1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480743
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Removes the method `FlowAnalysis.forwardExpression`, whose job was to
handle expressions that were rewritten during resolution, transferring
`ExpressionInfo` objects that were associated with the old expression
to the new rewritten expression.
Calls to `FlowAnalysis.forwardExpression` are replaced by an
equivalent construct: a call to `FlowAnalysis.getExpressionInfo` and a
call to `FlowAnalysis.setExpressionInfo`.
This change reduces the number of flow analysis methods that need to
interact with the map that associates expressions with
`ExpressionInfo` objects, paving the way for eventually removing that
map entirely.
Change-Id: I6a6a696486ea5bd30a6b2945f827a320fce1588b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480720
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the signature of `FlowAnalysis.whyNotPromoted` so that the
caller is responsible for looking up the expression info of the
matched value, and passing it in to flow analysis.
Change-Id: I6a6a69647bd1006c4ed4776a20bf36cd4c923498
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480620
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Removes the private methods `_getExpressionInfo` and
`_storeExpressionInfo`, inlining their contents in the public API
methods `getExpressionInfo` and `storeExpressionInfo`.
The private methods are no longer needed, since all logic that gets
and stores expression info is now in the client.
Change-Id: I6a6a696476a78934f8fef2dcd94cebc33d9e5e79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480601
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the signature of `FlowAnalysis.parenthesizedExpression` so
that instead of the caller passing in the inner and outer expressions,
the caller is responsible for fetching the expression info of the
inner expression and storing the expression info for the outer
expression.
With this change, `FlowAnalysis.parenthesizedExpression` is
essentially a no-op (it just returns back the expression info it was
passed). So in principle we could remove it from the flow analysis API
entirely. But I think it's valuable to keep it around because it
clearly documents the behavioral intent (namely, the flow analysis
treats a parenthesized expression exactly the same way it treats the
inner expression).
Change-Id: I6a6a69647d41fb91017a3a42796418f61c009f09
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480583
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is the second in a series of two CLs that changes the class
`ExpressionPropertyTarget` so that instead of looking up the target's
expression info during the call to `_getSsaNode`, it is given the
expression info at the time it is constructed. This will help simplify
the flow analysis API, by removing the need for it to know about the
`Expression` types used by the client.
In this second CL, the `expression` field is dropped from
`ExpressionPropertyTarget`. The `_getSsaNode` method no longer needs
to look up the expression info using `_getExpressionInfo`, since it is
supplied by the caller.
Change-Id: I6a6a69642c45a68d9eb580c1e7a28ea29bc07a65
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480581
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is the first in a series of two CLs that will change the class
`ExpressionPropertyTarget` so that instead of looking up the target's
expression info during the call to `_getSsaNode`, it is given the
expression info at the time it is constructed. This will help simplify
the flow analysis API, by removing the need for it to know about the
`Expression` types used by the client.
In this first CL, an `expressionInfo` field is added to
`ExpressionPropertyTarget`, but the old `expression` field is not yet
removed. At the time `_getSsaNode` is called, it looks up the
expression info and double checks (using an assertion) that it's the
same as what is stored in its `expressionInfo` field.
Once this change has passed trybots, I'll follow up with the second CL
in the series, which will remove the `expression` field.
The reason I've split this into two CLs is that I've discovered that
at least one call site needed to have its logic reordered, to make
sure that it didn't try to call `getExpressionInfo` too early. Before
I proceed with the second CL, I want to see a full trybot run with the
assertion in place, to verify that the expression infos supplied to
`ExpressionPropertyTarget` are correct.
Change-Id: I6a6a69641bf8779743dda4e74ec6adbeac0ee2d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480600
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the signatures of the following flow analysis methods:
- `FlowAnalysis.cascadeExpression_afterTarget`
- `FlowAnalysis.initialize`
- `FlowAnalysis.nullAwareMapEntry_valueBegin`
- `FlowAnalysis.write`
- `FlowAnalysisNullShortingInterface.nullAwareAccess_rightBegin`
so that the caller is responsible for looking up the expression info of
the matched value, and passing it in to flow analysis.
Additionally, the declaration of `getExpressionInfo` is moved from
`FlowAnalysis` to `FlowAnalysisNullShortingInterface`, in order to make
it available for calling in `NullShortingMixin`. With that change,
`getExpressionInfo` becomes declared in the same class as
`storeExpressionInfo`.
Change-Id: I2940663d00b46ee144fb1f86273ed87ae78a9fff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480160
Reviewed-by: Paul Berry <paulberry@google.com>
Auto-Submit: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the signatures of the following flow analysis methods:
- `ifNullExpression_rightBegin`
- `nonNullAssert_end`
so that the caller is responsible for looking up the expression info
of the matched value, and passing it in to flow analysis.
Change-Id: I6998042a3048c0d9c2cc5967d1f6f3e0ce744435
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/479842
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Auto-Submit: Chloe Stefantsova <cstefantsova@google.com>
Now that the `front_end` (and all related packages) have been migrated
off of the old `withArgumentsOld` methods and to the new
`withArguments` methods, the old methods may be deleted.
Note that the diff is rather large owing to the removal of
`withArgumentsOld` methods from the generated `diagnostic.g.dart`
files, and the removal of the `TOld` type parameter from the
`Template` class (which is used extensively in those generated
files). Excluding the generated file changes, the only changes are:
- Updating `generate_messages_lib.dart` so that the `withArgumentsOld`
methods are no longer generated.
- Removing `Template.withArgumentsOld`.
- Removing the type parameter `TOld` from the `Template` class (which
formerly specified the type of `Template.withArgumentsOld`), and
removing the corresponding type argument at all usage sites.
Change-Id: I6a6a6964ff1d088b8f67216478ef5da629fb3c1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/479060
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This adds reporting of const constructor with a primary constructor body with a constructor body.
The parser is augmented to provide the start token for the error reporting.
Part of #61700
Change-Id: If5a4dd041ab2b2d812d65aabfbcc72f536b5fe7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478363
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Changes the signatures of the flow analysis method
`equalityOperation_end` so that the caller is responsible for looking
up the expression info of the matched value, and passing it in to flow
analysis.
Change-Id: Ic12274a21b4197018ac7ba2057b49589c0737f53
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478960
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Auto-Submit: Chloe Stefantsova <cstefantsova@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>
Changes the signatures of the following flow analysis methods:
- `asExpression_end`
- `isExpression_end`
so that the caller is responsible for looking up the expression info
of the matched value, and passing it in to flow analysis.
Change-Id: Ifd51c2e0feb7b02f8bec2f08e74138064828a4ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478601
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@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>
Changes the signature of `FlowAnalysis.propertyGet`, so that in
addition to returning the promoted type of the variable, it returns an
`ExpressionInfo`, which the caller is responsible for storing.
Change-Id: I6a6a6964b7d3a1f8509433383ab7e70afabe99f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/474921
Reviewed-by: Chloe Stefantsova <cstefantsova@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 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 `DillLoader._logSummary` and `SourceLoader.logSummary` to use
`withArguments` rather than `withArgumentsOld` to report compilation
speed.
Also documents and renames the parameters of the following diagnostic
codes, which are the diagnostic codes that get passed to these
methods:
- `sourceOutlineSummary`
- `sourceBodySummary`
- `dillOutlineSummary`
Change-Id: I6a6a6964a21b7c3b5e607f9ff16624c9d7da9d7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/477061
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 and then running the script
`use_new_with_arguments.dart`.
Change-Id: I6a6a6964ff0ba0fc3c41ef96cd4146d9cd3c465a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/476821
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Jens Johansen