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>
Doesn't change anything in `front_end/*testcases/primary_constructors/`.
(Would have skipped any other file with `test` in its path and
an explicit language version marker, but there weren't any outside
of those `front_end` directories).
Almost no files used as test input were affected, and none testing the actual syntax changed.
The `.../nnbd/required_2.dart` test case was split into a legacy version retaining the `var`/`final` with a language marker, and a new version without the `var`/`final` cases.
The `pkg/analyzer/` tests, and any other tests that have source code
in strings, are not migrated by this CL.
Tested: No change to behavior. One test split into legacy and new.
Change-Id: I7f5aa4cc98001a9adecacd106c0b3be14f96be1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480542
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This makes the arguments to `ScannerConfiguration` required and uses the current enabled-by-default state as default.
Furthermore, an extension method is added for `ExperimentalFeatures` (and object already required by the parser) that creates the `ScannerConfiguration` based on the enabled features. This method is used throughout the analyzer and CFE, ensuring that the scanner is set up consistently with the parser.
Change-Id: Id51456d5a547b06d0925865e35e01d9dc7d65381
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/493760
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@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>
Moves some of the business logic for type analyzing yield statements
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 yield statements to be integrated more closely with flow
analysis. Sharing the type analysis logic will avoid the need to do
that integration twice.
Change-Id: I36c1f5e45e33d9e46dc934fb71bc634d6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491260
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Adds the class `StatementTypeAnalysisResult` to the shared type
inference codebase, along with a test method,
`checkStatementTypeAnalysisResult`, which will allow unit tests to
examine it. This class is the base class for the return type of all
statement analysis methods in the shared `TypeAnalyzer`
class. (Previously these methods returned void).
There are no fields in `StatementTypeAnalysisResult`; for now, it is
intended solely as a base class. To avoid incurring an extra runtime
cost, statement analysis methods that don't need to return any data
have been changed to return `const StatementTypeAnalysisResult()`
rather implicitly than returning `null`.
So far there are no derived classes. In a follow-up CL I will add an
`analyzeYieldStatement` method to the shared `TypeAnalyzer` class; it
will use a derived class to communicate information about the operand
to the front end.
Change-Id: I83c80b15d18e88fa80c08999bb78ca2f6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491240
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@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>
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>
Kallen Tu