The new name, `handleMergedStatementCase`, is more consistent with the
rest of the type analyzer's `handle` methods, and more accurately
describes when the method is called (after a switch body that's
potentially shared by multiple case heads and possibly a `default`
clause).
Change-Id: I4f3166d5f58432f9f1cc0edffb3c0a317539ea23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/260064
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Support for the following pattern types is added to the (as yet
unused) shared type analysis prototype:
- Cast patterns
- List patterns
- Logical-and patterns
- Logical-or patterns
- Null-assert patterns
- Null-check patterns
- Wildcard patterns
Change-Id: I923df94b5deef925ca94e6ff0c8eac0493f69c1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257602
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
- `CaseHeadInfo` is renamed to `CaseHeadOrDefaultInfo`, to reflect the
fact that it is used for both case heads and default clauses.
- `CaseHeadOrDefaultInfo.node` is no longer needed; this used to be
used for error reporting, but after the refactor of
https://dart-review.googlesource.com/c/sdk/+/259021 is was no longer
used.
- `ExpressionCaseInfo` is renamed to `SwitchExpressionMemberInfo`,
consistent with the AST structure `SwitchExpressionMember` in the
analyzer.
- `SwitchExpressionMemberInfo.body` is renamed to
`SwitchExpressionMemberInfo.expression`, consistent with the
nomenclature used in the analyzer.
- `StatementCaseInfo` is renamed to `SwitchStatementMemberInfo` for
consistency with `SwitchExpressionMemberInfo`. Note that the
analyzer calls its corresponding AST structure `SwitchMember` rather
than `SwitchStatementMember` for legacy reasons.
- `SwitchExpressionMemberInfo` no longer extends
`CaseHeadOrDefaultInfo`; it contains a pointer to the head or
default info. This is more consistent with
`SwitchStatementMemberInfo`.
Change-Id: I727766a6f0601ec5cd8aff824364319a54446bd2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259880
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The spec has been updated so that the pattern type schema is only used
in irrefutable contexts, and consequently we don't need to come up
with a type schema for refutable patterns.
The prototype code already made these assumptions, so there is no
change, only comment updates.
Bug: https://github.com/dart-lang/language/issues/2458
Change-Id: I4179953fff24ad596d990ab0423fe35f8a010805
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259860
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Bug: https://github.com/dart-lang/sdk/issues/49351
Adds checks for the following cases:
- Type arguments to createStaticInteropMock are correct
- No missing members in implementing class
- Inherited and non-overridden @staticInterop members are implemented
- Dart class can implement through inheritance and mixins
- Implemented members are correct subtypes of @staticInterop members
- Potential extension member conflicts that are attempted to be
resolved through subtyping rules
Change-Id: Iacbe5846040ba7fab41459aa19be77351cf1efca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255761
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Riley Porter <rileyporter@google.com>
Make the following changes, based on
8a9b9a8a74:
- Replace `ConstOrLiteralPattern` nomenclature with `ConstantPattern`
(the spec no longer speaks of "literal patterns").
- It is an error if a guard's type is not assignable to `bool`.
- Variable patterns can now be `final`.
- We now have a separate error condition to cover the case where a
variable, list, map, record, or extractor pattern appears in an
irrefutable context and the matched type is not assignable to the
required type of the pattern. (Previously such patterns were simply
called "refutable", leading to a less clear error).
Additionally, we now consistenly use the term "guard" to refer to the
expression after a `when`, consistent with the spec text.
There are a few new TODOs, which I plan to address in follow-up CLs.
Change-Id: Ia0abab9492583f2aa8b59a9b381b90ba11b3e0fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259246
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change refactors the logic for detecting overlapping and missing
variable patterns so that it can be invoked prior to the rest of type
analysis, rather than during it. In addition separating concerns
nicely (since no types are involved in these checks), I believe this
will facilitate integration with the analyzer and front end, by
allowing them to detect these errors and find the unique set of
variables defined by a pattern, at the time they are resolving
identifiers to their corresponding declarations.
Change-Id: I40879fca46d39e78a60813db007983e57a3aec31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259021
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I've begun prototyping what it might look like to integrate the
current shared type analysis functionality with the analyzer and CFE,
and I've discovered some API improvements that are needed:
- The shared logic now handles the possibility that switch cases that
share a body have been merged prior to type analysis (because the
CFE merges them during parsing), in addition to the pre-existing
functionality which assumed that switch case merging had to be done
in the shared logic.
- The shared logic now returns several pieces of information as the
result of a call to `analyzeSwitchStatement`: whether the switch
statement had a `default` clause, whether it was exhaustive, whether
the last case body terminates, and the type of the scrutinee. These
are all needed by the CFE.
- The shared logic now allows `TypeAnalyzer.errors` to be `null`,
indicating that no errors should be reported. This reflects how
errors are suppressed during top level inference in the CFE.
- If a switch case lacks a `when` clause, this is reported by calling
`handleNoWhen` rather than passing a boolean to `handleCaseHead`.
- The shared logic now reports the appropriate error when a case
constant doesn't properly match the scrutinee's static type.
- Information about case labels is now delivered to flow analysis via
`switchStatement_endAlternatives` rather than
`switchStatement_beginCase`. This made it possible to rewrite the
shared `analyzeSwitchStatement` method in a way that requires less
bookkeeping, because it no longer has to peek ahead to look for
labels associated with a given case body.
- `TypeAnalyzer.analyzeExpression` is now responsible for
understanding that "no context" and a context of `dynamic` should
both be coalesced to `?`. The analyzer does this (although it's not
100% why), and it's definitely "business logic" that eventually
belongs in the shared type analyzer.
- `TypeAnalyzer.analyzeSwitchExpression` and
`TypeAnalyzer.analyzeSwitchStatement` no longer receive a list of
ExpressionCaseInfo / StatementCaseInfo objects describing the cases;
instead they query for them using a callback. This reduces the
lifetime of the ExpressionCaseInfo / StatementCaseInfo objects. In
the future, when we have record support, we could replace these
objects with records, which would then be passed on the stack,
avoiding any allocations.
- A new hook, `handleSwitchScrutinee`, is called right after visiting
the "scrutinee" expression of a switch expression or switch
statement. This hook is needed by the analyzer to compute
exhaustiveness. In a future CL, I hope to move exhaustiveness
analysis into the shared code as well, which should make this hook
unnecessary.
- `TypeAnalyzer.analyzeSwitchStatement` now reports an error if a
switch case completes normally and pattern support is not enabled.
- The test class `_MiniAstTypeAnalyzer` no longer overrides
`analyzeExpression` to provide a default context type; instead,
every call to `analyzeExpression` that didn't previously provide a
context now provides a context of `?`. Note that not all of these
are correct, but they are close enough for the unit tests we have
today. I plan to fix them in future CLs as I replace this logic
with shared logic.
- The hook `handleVariablePattern` is now always provided with a
static type. Previously, it was only provided with a static type if
this was the first time the variable was bound in the pattern.
Change-Id: I70e3c5468312a9329fcf4ad2e13749a32d2418e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257487
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Update the documentation for TypeAnalyzer and related classes so that
they explain the behavior of each method in terms of its effect on a
stack. (The test logic already contained an implementation of such a
stack; production clients may or may not need to keep a stack
depending on their requirements). This should make it more
straightforward to write clients of TypeAnalyzer.
Also, beef up the test logic in flow_analysis_mini_ast.dart and so that:
- In the event of a test error, a source location is shown, so that
it's easy to debug and/or update the test. This source location is
obtained by parsing `StackTrace.current`, an approach which I
wouldn't recommend for production code, but which is servicable for
these low-level tests.
- Items that are popped off the stack are checked to make sure they
have the expected kind.
The kind-checking caught a minor flaw in the previous test logic: it
was failing to distinguish expressions from expression statements.
This as been corrected, and as a result, a few test expectations in
type_inference_test.dart needed to be updated.
Change-Id: I0a2b257f6e970478c0c8e1b663dd5a367e7f24ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257486
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change adds logic to compute whether a pattern is refutable or
irrefutable, and reports the error `` if a refutable pattern is used
in an irrefutable context.
Additionally, the methods `handleConstOrLiteralPattern` and
`handleVariablePattern` are adjusted so that they report the static
type of the matcher back to the client.
A lot of internal type analysis logic previously referred to the
static type of a pattern as its "inferred type"; this nomenclature is
corrected to match the spec.
Change-Id: Icaa1118d1da41b28bea2b4f14c47578dacd85807
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256641
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Support for `when` clauses requires flow analysis integration, so that
`when` clauses can promote variables, e.g.:
f(int x, String? y) {
switch (x) {
case 0 when y != null:
// y is known to be non-null here
}
}
Support for labels in switch statements had a small flaw: we weren't
reporting an error in the case where a label shared a case body with a
pattern that tried to bind a variable, e.g.:
f(int x) {
switch (x) {
L: // Error: does not mind the variable `y`
case var y:
...
}
}
Change-Id: I0b2bb4721a6b3a8f7898df682b24b75ddb6e44ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256605
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change introduces the TypeAnalyzer methods
analyzeConstOrLiteralPattern, analyzeExpression,
analyzeInitializedVariableDeclaration, analyzeSwitchExpression,
analyzeSwitchStatement, analyzeUninitializedVariableDeclaration, and
analyzeVariablePattern. These are sufficient to analyze legacy switch
statements and legacy variable declarations, as well as switch
statements and switch expressions involving either constants or
variable patterns.
Although the code is not used in the analyzer or front end yet, it is
unit tested in isolation, and it's integrated into the existing flow
analysis unit tests.
A few minor tweaks had to be made to flow analysis to support this new
functionality. There should be no visible effect to existing analyzer
or front end behavior.
Change-Id: Ie8ec31ca92d5f2f7a7f6f6a20ca1baba3c6b28f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256604
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This changes how scopes are computed for libraries and classes
(work on extensions is still pending). The change supports the new
shared scope need for augmentations, in which a declaration on the
origin or any of the augmentations is directly accessible in the
origin and all augmentations.
Change-Id: Ifb76f49bf80fcad2d92a0400b9be623406afb40d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256262
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This change introduces the mixin TypeAnalyzer, which is intended to be
mixed into analyzer and front end classes to provide shared logic for
type analysis of Dart code. This work is currently experimental, and
not hooked up to the analyzer or front end, but the eventual hope is
that it can replace the logic that's currently duplicated between the
analyzer's ResolverVisitor and the front end's InferenceVisitorImpl.
A secondary goal of introducing this code is to allow some of the
static consequences of the patterns proposal to be explored now, even
before parser support is finished.
To avoid introducing additional code duplication while the project is
in this experimental phase, I'm going to attempt to restrict myself as
much as possible to prototyping functionality that is not yet
implemented in the analyzer or front end. This initial CL is an
exception; it introduces the method `analyzeIntLiteral`, which
duplicates logic that already exists in both the front end and
analyzer that analyzes integer literals. I'm doing this because it's
just complex enough to serve as a validation of the basic approach,
and because integer literals will be handy in writing test cases for
the expanded switch functionality in the patterns proposal, which I
plan to work on next.
Although the code is not used in the analyzer or front end yet, it is
unit tested in isolation, and it's integrated into the existing flow
analysis unit tests.
Change-Id: I07c7cd709eec9e8492669f2dc8db57fb7c10798f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255081
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Before this was ok:
```
var x = [a as int?, a];
```
but this was not:
```
var x = [a, a as int?];
```
Nor was this:
```
list[i as int?];
```
Fixes https://github.com/dart-lang/sdk/issues/49678
Change-Id: I8a169e15b189965ad19ad489e8a0a6f02c09b34b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This adds support for handling record literals in the BodyBuilder,
passing and handling it in the inference visitor. The correct
AST node is still not produced.
Change-Id: Ifc1e22f3ed30ddde7058ff666117e02d43a4c6a8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256210
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This prepares for the building of the RecordType nodes for record
types.
Change-Id: If055dd31ac55c4314553ccce50b803723a9e09ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255993
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This is a preparatory step towards sharing type inference logic
between the front end and analyzer. The ExpressionTypeAnalysisResult
interface will be returned from the shared `analyze` methods for
expressions, as a container for all the information needed by both the
client (front end or analyzer) and by the code that analyzes the
containing expression or statement.
For now, the only implementation of the interface is
SimpleTypeAnalysisResult, which represents the result of analyzing a
simple expression with no null shorting. In future CLs I plan to add
more types, recording information such as:
- For an integer literal, whether it was implicitly converted to
`double`.
- For a binary operator or a compound assignment, the resolved binary
operator.
- Information necessary to coordinate null shorting.
And so on. There is a placeholder method `resolveShorting` that will
encapsulate null shorting logic, but it doesn't do anything special in
the case of SimpleTypeAnalysisResult.
At the moment, only test code is affected.
Note that this approach isn't free; every time we analyze an
expression we wrap the resulting type in a SimpleTypeAnalysisResult,
so there's a cost of one allocation per expression in the user's
program. I don't believe this will be a problem in practice, because
the front end uses a similar approach, so it is already paying this
penalty.
Change-Id: Ic407089b6eb9e717c65d73766e7c836e161ef0da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255080
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This makes it possible to handle named record fields without peeking
at the last record field (list) on the stack.
Change-Id: I96e2009cf5933ef505459ac8722d5bcbeb67db83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255983
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
- Variable types are no longer specified in the call to the `Var`
constructor; they are now specified in the call to `declare`. This
paves the way for supporting variable pattern syntax, in which a
single variable might appear in multiple variable patterns, and have
its type specified in each pattern. The properties `isFinal` and
`isLate` are also moved to `declare` for consistency.
- Variables with inferred types are now specified by simply not
including a type in `declare`; it's no longer necessary to specify
`isImplicitlyTyped: true`.
- `declare` now supports an `expectInferredType` argument to allow the
inferred type of an implicitly typed variable to be tested.
- The tests now check that variables are assigned a type before flow
analysis requests it; previously this was not tested, and the flow
analysis tests sometimes did things in the wrong order. (The
analyzer and CFE have always done this in the proper order though).
- The tests now support some of the crazy types that arise during type
parameter promotion, e.g. they can now distinguish `(T&int)?` from
`T&(int?)`.
- Flow analysis tests now properly replicate the analyzer and CFE
behaviors for converting the static type of an initializer
expression to the corresponding inferred variable type: (a) `Null`
is converted to `dynamic`, and (b) type parameter promotions are
dropped.
Note that this last behavior (dropping type parameter promotions) has
a lot of subtleties, and I'm not convinced the CFE and analyzer do it
soundly in all cases (I've already found one such soundness bug:
https://github.com/dart-lang/sdk/issues/49691). In a later CL, I plan
to add a more thorough set of language tests to verify that we don't
have other lurking soundness issues.
Change-Id: I6f2cd20db1f07b34e0ad4e7002351c8de846b125
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255600
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Several unusual constructs that lead to unreachable code are now
recognized by flow analysis:
- Control flow after an expression of the form `e ?? other` or `e ??=
other`, where `e` has static type `Null` and `other` has static type
`Never`, is considered unreachable.
- Control flow predicated on an expression of the form `e is Never`
evaluating to `true` is considered unreachable.
- Control flow predicated on an expression of the form `e is! Never`
evaluating to `false` is considered unreachable.
- Control flow on the RHS of a null-aware access such as
`e?.property...`, `e?.property = ...` or `e?.method(...)`, where `e`
has static type `Null`, is considered unreachable (Note: this can
arise in the presence of extension methods).
Previously, these behaviors only took effect if `e` was a reference to
a local variable.
Note: the change to `regress/issue_31180` is because I’ve corrected
the behavior of implicit temporary variables to not undergo a type
change from `Null` to `dynamic`, so the dead code part of `null?[1]`
is now erroneous. (I had to make this change in order for the last
bullet above to work properly; without it, the type change to
`dynamic` prevents flow analysis from recognizing that the code to the
right of `?.` is unreachable.) There's no behavioral change to
correct code, but I've captured the behavioral change to incorrect
code in
`tests/language_2/null_aware/null_aware_index_on_null_error_test.dart`.
Bug: https://github.com/dart-lang/sdk/issues/49635
Change-Id: I8b24b3b040a34f897c0b61dcb9bd105be6d0af6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
A get of a promotable field on a non-promotable field shouldn't
promote, otherwise this code would be unsound:
class C {
D get _field1 => D();
}
class D {
final int? _field2 = randomBool() ? 1 : null;
}
main() {
var c = C();
if (c._field1._field2 != null) {
// Problem: `c._field1` returns a different `D` each time, so there's
// no guarantee that `c._field1._field2` is non-null the second time we
// access it!
print(c._field1._field2.isEven);
}
}
This change has no user-visible effect because field promotion is not
yet enabled.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I9a60cd343dff14cded03df700d7c2b62a251487a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255821
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
A single internal list pointing to a simple data structure is easier
to reason about than a bunch of parallel lists, and it reduces the
performance cost if we have to add more data to the internal data
structure in the future.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I348cae86781c4d1f15520160a674df381fe2e38f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255815
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The current [StringCanonicalizer] implementation has some issues:
* It hangs on to large [Uint8List]/[String] objects in it's cache
=> This requires users (such as analyzer) to clear the cache
frequently
* Has api that works on dynamic input (which is assumed to be String
or List<int> / Uint8List)
=> Call sites have typing information we loose when doing the call
* It uses dynamic [] calls to compare input bytes with cached bytes /
input strings with cached strings
=> Dynamic calls come with overhead
=> Will cause substring generation for every character comparison
=> Will compare bytes with strings (which doesn't make sense)
To address these issues we
* Use the canonicalized [String] to compare against instead of the
(much larger) source strings, thereby no longer hanging on to large
strings in the canonicalizer cache (it's still an issue with
[Uint8List]s though)
* Make seperate API for canonicalization of strings, sub-strings or
sub-utf8-bytes and use it from the token implementation.
* For canonicalization of strings use String.== (instead of
char-by-char comparison)
* For canonicalization of sub-strings use String.charCodeAt instead of
[] (which creates substrings)
* Seperate out cache node entries into two classes and reduce memory
consumption of the nodes that represent strings by 16 bytes (it
does an additional `is` check on lookups in the cache, but that is
better than paying for dynamic calls on the payload - which
causes the compiler to do implicit checks)
=> This CL reduces RAM consumption and makes CFE scan/scan_bytes benchmarks a little faster.
TEST=ci
Change-Id: I157c298d26d25ac5da82c32eedfa270a590156f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255121
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Some instances of analyzer have a heap of 600 MB, containing 400k
StringToken/StringTokenImpl.
This CL combines two existing fields which will shrink those objects
by 16 bytes, which saves 6 MB.
We densly number all token & keyword types so they can be looked up in
an array.
TEST=ci
Change-Id: I8431db243d55a316e7a72678844d031356c40e79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254920
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This change ensures that when a variable `x` is written to or
captured, promotions of its fields (e.g. `x.y`, `x.y.z`, etc.) are
cancelled. This is necessary for soundness of field promotion.
There is no effect on production code, since field promotion is not
yet enabled.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: Ic0739ca80cc2afe6188ada6209cb558d8cea9b63
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254620
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change breaks flow_analysis.dart into the following libraries:
- assigned_variables.dart (for the AssignedVariables class and related
code)
- promotion_key_store.dart (for the PromotionKeyStore class)
- type_operations.dart (for the TypeOperations mixin and related code)
- flow_analysis.dart (for the rest of flow analysis)
And it breaks mini_ast.dart into the following libraries:
- flow_analysis_mini_ast.dart (functionality specifically concerned
with testing flow analysis)
- mini_ast.dart (functionality not specifically related to flow
analysis)
This is in preparation for trying to share some more type inference
behaviors between the analyzer and CFE.
Note that although the diff is big, the only changes in this CL are
moving code from one place to another, renaming some class members
from private to public, and updating imports.
Change-Id: I71768f03b1e75ed754c7b7af39f6cf7f03c4fe44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254462
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change splits the `Harness` class into a base class, `Harness`,
which in principle can be used for testing type inference logic in
general, and a derived class `FlowAnalysisTestHarness`, which is
specialized for flow analysis tests.
This is in preparation for trying to share some more type inference
behaviors between the analyzer and CFE.
Change-Id: Ic56b8dd8748065ca59e246e0d804946cc69203c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
