This change updates the mini_ast testing infrastructure so that:
- It properly models the "exception type" part of a catch clause (the
type named after the `on` keyword).
- It requires an exception variable to be specified if there is a
stack trace variable (this is required by the Dart grammar).
- It requires an exception type to be specified if there is no
exception variable (this is required by the Dart grammar).
- During the "pre-visit" stage, the exception variable and stack trace
variable are registered with the `AssignedVariables` object, so that
they can be properly handled by type promotion.
- During the main "visit" stage, the exception variable and stack
trace variable are assigned the appropriate types.
Flow analysis unit tests are updated in order to meet the new
requirements, and flow analysis tests are added to check that stack
trace and exception variables are promotable and appropriately typed.
By ensuring that stack trace and exception variables are properly
typed during flow analysis tests, this paves the way for some
follow-up work, in which I plan to re-work how flow analysis keeps
track of variable types.
There is no behavioral change to the analyzer or compiler pipeline;
these changes are confined to `pkg/_fe_analyzer_shared/test`.
Change-Id: I49c4b894d82d1dc58d62e3d3f25d232c9106922e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434145
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change introduces some helper functions to avoid duplication
between the enabled/disabled variants of each of the try/finally
ordering tests.
Thanks to Lasse for the suggestion.
Change-Id: I4538d44643fde7954a75bc1b6843fcc805d8afc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432782
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change adds test-only methods `propertyPromotionChainForTesting`
and `variablePromotionChainForTesting` to flow analysis; these are
used by the flow analysis unit tests to query the full promotion chain
of a porperty (or variable, respectively). This allows tests to
observe the effect of try/finally ordering on promotion chains without
having to resort to clever control flow joins.
Thanks to Lasse for the suggestion.
Change-Id: Ida5349ecc93dbd4b3392becd20882be3eb101024
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432800
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When an `is` test is trivially satisfied (i.e. `expr is T`, when the
static type of `expr` is a subtype of `T`), the `is` test is
guaranteed by soundness to evaluate to `true`, so any code path that
follows from the `is` test evaluating to `false` is unreachable.
This reasoning wasn't valid prior to sound null safety, because in
mixed mode programs, it was possible for an expression to evaluate to
`null` even if its static type wasn't nullable, and hence `expr is T`
might evaluate to `false` even if the static type of `expr` was a
subtype of `T`. So this change is gated on the `sound-flow-analysis`
language flag (which is enabled in Dart 3.9).
Fixes https://github.com/dart-lang/sdk/issues/60718.
Change-Id: I66a65580b738162f23b6fb468b71fcac66bfbb95
Bug: https://github.com/dart-lang/sdk/issues/60718
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431740
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
During the implementation of flow analysis for patterns, I added a
hack to the flow analysis tests so that all variable declarations were
desugared into the equivalent pattern variable declaration. This had
the advantage of getting some extra testing "for free" during early
development of the patterns feature, but it had a few disadvantages:
- It the caused the shared flow analysis and type inference tests to
stop exercising flow analysis code paths for ordinary variable
declarations.
- It forced the testing logic to "support" pattern variable
declarations that are late or lack an initializer; these are things
that regular Dart doesn't support, and they made the implementation
of `PatternVariableDeclaration.visit` much more complicated than it
needed to be.
The language team is currently contemplating some changes to how
promotions work in ordinary variable declarations and pattern variable
declarations (see, for example,
https://github.com/dart-lang/language/issues/4347#issuecomment-2861859329). So
in order to be able to experiment with these possibilities, I want to
get rid of this hack.
This CL adds a `VariableDeclaration` class, to represent ordinary
variable declarations, and modifies the `declare` function (which is
used by tests for creating an ordinary variable declaration) so that
it creates a `VariableDeclaration`, rather than rewriting it into a
`PatternVariableDeclaration` containing a `VariablePattern`. It
removes "support" for testing pattern variable declarations that are
late or lack an initializer, simplifying
`PatternVariableDeclaration.visit`.
A few test cases in `type_inference_test.dart` were checking the
generated IR for ordinary variable declarations, verifying that it was
properly desugared into a pattern variable declaration; these
expectations have accordingly changed to no longer expect desugaring.
There is no functional change to the compiler or analyzer
toolchain. These changes only affect tests in
`pkg/_fe_analyzer_shared/test`.
Change-Id: I90f074cd6e7a6ed5ed11afadeadb6131ce1d282f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432122
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The following renames are performed:
- The class `Declare` (which is the "mini-AST" representation of a
pattern variable declaration), is renamed to
`PatternVariableDeclaration`.
- The top level function `match` (which is used in tests to construct
a "mini-AST" representation of a pattern variable declaration), is
renamed to `patternVariableDeclaration`.
The new names should help avoid confusion in a follow-up CL I intend
to create, which will introduce a new `VariableDeclaration` class to
represent ordinary variable declarations.
There is no functional change. These renames only affect tests in
`pkg/_fe_analyzer_shared`.
Change-Id: Ic6b6f75cbb312180273a08f2c3926f83da254bc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, when assiging to a local variable that was promoted, if
the newly assigned value was not compatible with any of the promotions
(i.e., the variable was fully demoted back to its declared type), then
the set of types of interest was cleared.
This behavior was not documented anywhere in the spec, and it seems
oddly inconsistent to me; as far as I can tell, flow analysis doesn't
clear types of interest in any other circumstances. I've looked
through git history as well as my personal notes, and I've been unable
to find any justification for this behavior. So, with the agreement of
the language team, I'm removing it when sound-flow-analysis is
enabled.
Fixes https://github.com/dart-lang/language/issues/4380.
Bug: https://github.com/dart-lang/language/issues/4380
Change-Id: Ic1ca80a61e21482e659afa8796b08fce707db3c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429227
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
A tricky part of the implementation of flow analysis is the handling
of try/finally statements. Although promotions are tracked separately
in the `try` and `finally` blocks, promotions from both blocks need to
be merged together at the conclusion of the finally block. This
creates an ambiguity, because each type in a promotion chain is
required to be a subtype of the previous, and hence multiple
promotions of the same variable are inherently ordered. The ambiguity
is: when the promotions from the `try` and `finally` block are merged,
which promotions should be applied first?
In discussion with the language team, we've decided that the
promotions from the `try` block should be applied first, because that
matches the order of code execution. This change makes the behavior of
flow analysis more uniform, which should make it easier to reason
about and maintain.
In practice, the difference in behavior is quite subtle, and I don't
expect users to notice. However, to be on the safe side, the change in
behavior is conditioned on the `sound-flow-analysis` flag, so it will
only take effect when the user deliberately upgrades to language
version 3.9, and it will not affect already-published packages.
A test in google3 showed that no internal code would be broken by
force-enabling this change.
Fixes https://github.com/dart-lang/language/issues/4382.
Change-Id: I0e9f6db808a964e0b4325d3020654a9f2be273a2
Bug: https://github.com/dart-lang/language/issues/4382
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432001
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, flow analysis had the rule that type promotion only
occurred when the type being tested was a subtype of the previously
promoted type (or the declared type, if there was no previous
promotion). This led to counterintuitive behaviors when the type being
tested and the previously promoted type were mutual subtypes (see
https://github.com/dart-lang/language/issues/4368).
With this change, the rule is updated so that type promotion only
occurs when the type being tested is a subtype of the previously
promoted type _and_ the previously promoted type is _not_ a subtype of
the type being tested. The user-visible difference is that promotion
to a mutual subtype no longer occurs.
This change makes flow analysis easier to reason about, and improves
its behavior in corner cases, but I believe it will have minimal
impact on real-world code. But to reduce the risk to existing code,
the change only takes effect when the `sound-flow-analysis` language
feature is enabled.
Fixes https://github.com/dart-lang/language/issues/4368.
Bug: https://github.com/dart-lang/language/issues/4368
Change-Id: I30dab017e043e75603d618df721c8a2683667cd5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429200
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I accidentally called the test group "Sound null safety", which is a
related concept, but not the same thing.
Sound null safety is a compilation mode in which no legacy code is
allowed, and so it is sound to assume that an expression with a
non-nullable type cannot evaluate to `null`. It has been the only
allowed way to compile Dart programs for some time.
Sound flow analysis, on the other hand, is a set of improvements to
flow analysis which are possible now that all Dart programs are now
compiled in sound null safety mode. It is a language-versioned feature
that is enabled in Dart 3.9.
Change-Id: Ib13d28be7fecea6d0e931b33d6643afab2349629
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432004
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Default types are used in the exhaustiveness computation but were not
computed for local functions, leading to a crash during constant
evaluation. This adds computation of default types to
FunctionDeclaration and FunctionExpression.
Closes#54388Closes#60264
Change-Id: I95eb2ae5b42e4fb5ab77088c915fe6088a1d4060
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427702
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The way this is accomplished is that in
`_FlowAnalysisImpl.nullAwareAccess_rightBegin`, any expression
reference associated with the target of the null-aware access is
restored, and the corresponding SSA node is associated with the guard
variable (if any). These changes ensure that if the null-aware access
is a property get, the subsequent call to `propertyGet` will pick up
the appropriate SSA node, so it will be able to locate the promotion
key for the property.
This functionality is only enabled when the language feature
`sound-flow-analysis` is enabled.
To prevent test regressions, a few related changes need to be made at
the same time:
- `_FlowAnalysisImpl.nullAwareAccess_end` is changed so that it clears
any expression info or expression reference that was associated with
the null-aware access expression. This prevents flow analysis
information from being erroneously propagated out of a null-aware
expression, which would have led to assertion failures when
analyzing null-aware expressions inside of conditional
expressions. This wasn't previously a problem because the expression
reference used to be consumed by
`_FlowAnalysisImpl.nullAwareAccess_rightBegin`, preventing further
expression references and expression infos from being recorded
further along in the null-aware access.
- The test framework in `mini_ast.dart` is fixed so that `!` is
considered to participate in null shorting. This was a bug in the
test framework that wasn't previously caught because it happened not
to produce any test failures.
- The analyzer's method `PostfixExpressionResolver._resolveNullCheck`
is changed so that it calls `nonNullAssert_end` before terminating
null-aware access. Previously, the order was swapped, causing
`nullAwareAccess_end` to be called before `nonNullAssert_end` when
analyzing expressions like `a?.b!`. This used to be benign, but now
that non-cascaded field accesses participate in field promotion,
flow analysis needs the methods to be called in the correct order.
Fixes https://github.com/dart-lang/language/issues/4344.
Bug: https://github.com/dart-lang/language/issues/4344
Change-Id: I523be1b4be1af3f68654a745187a546728c878fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427820
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The CFE desugars null-aware expressions such as `a?.b` into equivalent
`let` expressions involving a temporary guard variable (e.g., `let x =
a in x == null ? null : x.b`). This desugaring happens in the body
builder, prior to flow analysis. As a result, the expressions and
variables passed to flow analysis are those of the desugared `let`
expression rather than those of the code the user wrote. So a hack is
needed to ensure that flow analysis produces the correct result; the
hack involves promoting the temporary guard variable in the code path
where it is not null.
Prior to this change, the hack was done entirely in the CFE. Instead
of making a single pair of calls to
`FlowAnalysis.nullAwareAccess_rightBegin` and
`FlowAnalysis.nullAwareAccess_end` for every null-aware expression,
the CFE made two nested pairs of calls: one to promote the true target
of the null-aware access, and the other to promote the temporary guard
variable.
This had the advantage of keeping the hack entirely in the CFE, but
unfortunately it got in the way of fixing
https://github.com/dart-lang/language/issues/4344, because it
prevented flow analysis from properly recognizing field accesses
inside null-aware expressions.
This change adds an optional `guardVariable` parameter to
`FlowAnalysis_nullAwareAccess_rightBegin`, and shifts the
responsibility for promoting the temporary guard variable to the flow
analysis engine itself. With this change, the CFE no longer needs to
make two nested pairs of calls to
`FlowAnalysis.nullAwareAccess_rightBegin` and
`FlowAnalysis.nullAwareAccess_end`, and flow analysis now has the
necessary information to recognize field accesses inside null-aware
expressions.
I will perform the actual fix for
https://github.com/dart-lang/language/issues/4344 in a follow-up CL.
Note that in the future, I would like to change the CFE so that it
desugars null-aware accesses during type inference rather than during
the body builder; this will allow the expressions and variables passed
to flow analysis to be precisely those of the code the user wrote;
that in turn will give us extra confidence that flow analysis produces
the same results in the analyzer and the CFE.
Change-Id: Ie63619a3ca0f011c1ae8e3c0c76b5bc7c1ab8419
Bug: https://github.com/dart-lang/language/issues/4344
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427341
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These unit tests exercise flow analysis behaviors for patterns that
one might plausibly assume are part of the `sound-flow-analysis`
feature, but actually have been present ever since the `patterns`
feature was introduced.
Adding these tests helps me be confident that the behavior of flow
analysis after `sound-flow-analysis` has all of the soundness
behaviors I expect; even though some of those behaviors aren't new.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: I77a269907c67d643d0ef23d4f76545e36761bbfc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421960
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change updates the logic in the flow analysis method
`promoteForPattern`, so that when the language feature
`sound-flow-analysis` is enabled, the following additional behaviors
are added:
- If the matched value type is non-nullable, and the pattern
implicitly performs an `is Null` test, then the pattern is known not
to match.
- If the matched value type is `Null`, and the pattern implicitly
performs an `is T` test, where `T` is a non-nullable type, then the
pattern is known not to match. Note that this reasoning step is
sound regardless of whether the program is running with sound null
safety enabled, but since it is a new reasoning step, it only takes
place if the `sound-flow-analysis` feature is enabled.
There is no behavioral change if the feature `sound-flow-analysis` is
disabled.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: I5a6e8def050c95b6c1ad01d37584d17a0cd590c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421900
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change updates the flow analysis logic for map patterns, so that
when the language feature `sound-flow-analysis` is enabled, an empty
map pattern is considered to match a non-nullable map.
There is no behavioral change if the feature `sound-flow-analysis` is
disabled.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: I3f5a79c00cfe91d37528a3790b5cedb9a8f010fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421584
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change updates the flow analysis logic for null check patterns,
so that when the language feature `sound-flow-analysis` is enabled,
the matched value type is checked for nullability. If it's
non-nullable, then the null check pattern is known to succeed.
There is no behavioral change if the feature `sound-flow-analysis` is
disabled.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: Ie68d98d95e30053f992a3f8db6ccdd3978960eb7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421583
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
It turns out that the flow analysis logic for null-aware map entries
has always presumed sound null safety. That is, given a map entry with
a null-aware key (`{?x: y}`), flow analysis assumed that if the key
was non-nullable, then the value was guaranteed to execute.
However, another piece of logic that could have been implemented, and
wasn't, was that if the key had static type `Null`, then the value was
guaranteed _not_ to execute. This logic would have been sound even
without assuming sound null safety (because even in unsound null
safety mode, the type `Null` was only inhabited by the value `null`).
This change implements the missing logic. Even though it doesn't
strictly depend on the assumption sound null safety, it still makes
sense to guard it by the `sound-flow-analysis` flag, because (a) it's
a potentially breaking change, and (b) it brings the flow analysis
behavior of null-aware map entries into alignment with the other
behaviors that are being implemented as part of the
`sound-flow-analysis` feature.
There is no behavioral change if the feature `sound-flow-analysis` is
disabled.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: Ie711f582660a31a411be0dc339995df140feb04f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420800
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change updates the flow analysis logic for `??` and `??=`
expressions, so that when the language feature `sound-flow-analysis`
is enabled, the static type of the left hand side is checked for
nullability. If it's non-nullable, then the right hand side of the
expresison is considered unreachable.
These new behaviors break assumptions made by two pre-existing flow
analysis tests. I changed those tests to run with
`sound-flow-analysis` disabled.
There is no behavioral change if the feature `sound-flow-analysis` is
disabled.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: I33d6d256bd3c41b764245f50ad34eb5c8b33878e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420740
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This change updates the flow analysis logic for `?.` expressions, so
that when the language feature `sound-flow-analysis` is enabled, the
static type of the target is checked for nullability. If it's
non-nullable, then the "shortcut" control flow path (the control flow
path in which the null-aware operation is not executed) is considered
unreachable.
One pre-existing flow analysis test was made redundant by this
change. Another needed a minor tweak to continue passing.
There is no behavioral change if the feature `sound-flow-analysis` is
disabled.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: I3cd92dd49d4393b40f0ec888b643f0353de5e2d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420466
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change updates the flow analysis logic for `==` and `!=`
expressions, `==` and `!=` patterns, and constant patterns, so that
when the language feature `sound-flow-analysis` is enabled, the static
types of the two expressions being compared are checked for
nullability. If one of the types is non-nullable and the other type is
`Null`, then it is known that the values will be unequal.
Note that these new behaviors break assumptions made by several
pre-existing flow analysis tests. I was able to adjust some of the
tests to preserve their old behavior, either by adjusting expectations
or running the test with `sound-flow-analysis` disabled. Some other
tests became redundant, so I removed them.
There is no behavioral change if the feature `sound-flow-analysis` is
disabled.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: Ib65477e064bb8dcd761542ebe187843fe265a24b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420463
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This change updates the flow analysis logic for `is` and `as`
expressions so that when the language feature `sound-flow-analysis` is
enabled, the static type of the operand is compared to the type to the
right of the `is` or `as` keyword. If one of the types is non-nullable
and the other type is `Null`, then the type test is known to fail. For
an `as` expression, this means that the code path following the
expression will be marked as unreachable. For an `is` expression, this
means that any code paths that assume it evaluates to `true` will be
marked as unreachable.
Note that these new behaviors break assumptions made by three
pre-existing flow analysis tests. I was able to adjust one of the
tests ("equalityOp_end does not set reachability for `this`") to
preserve its old behavior. The other two tests became redundant, so I
removed them.
There is no behavioral change if the feature `sound-flow-analysis` is
disabled.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: Ib3a9e96bd39cf7df4c6c297568763c0f25bc9e39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420164
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, flow analysis was configured by passing a set of named
booleans to its constructor, each to enable or disable a separate
language feature.
This change merges the flow analysis configuration with the
`TypeAnalyzerOptions` class (which was already being used for
configuring the shared `TypeAnalyzer` class). This should make it
easier to add language features to the shared code base in the future,
since there will be one common place where all features will be
configured.
To avoid duplicating the logic that creates `TypeAnalyzerOptions`,
I've had to do a bit of minor surgery to the clients:
- In the test harness in `_fe_analyzer_shared`, there is a common
method (`Harness.computeTypeAnalyzerOptions`) that constructs
`TypeAnalyzerOptions` based on the harness configuration. It is
called from a few different tests.
- In `pkg/analyzer`, there is a common method
(`computeTypeAnalyzerOptions`) that constructs `TypeAnalyzerOptions`
based on a `FeatureSet`. It is used by
`LibraryAnalyzer.analyzeForCompletion`,
`LibraryAnalyzer._resolveFile`, and the late variable
`AstResolver._typeAnalyzerOptions`.
- In `pkg/front_end`, I've moved computation of `TypeAnalyzerOptions`
from the `InferenceVisitorImpl` constructor to the
`TypeInferrerImpl` constructor; the options are then passed to the
`InferenceVisitorImpl` by `_createInferenceVisitor`.
I'm doing this work now as preparation for adding support for sound
flow analysis (https://github.com/dart-lang/sdk/issues/60438), so that
I can add the logic to enable it in a clean way.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: Ib845194adb404b4c0a3feeff17a14ae641d515eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/419940
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
A null-aware access can result in dead code if the target has static
type `Null`. The analyzer wasn't properly accounting for this,
resulting in some confusing ranges reported for the DEAD_CODE warning.
This change causes the following expressions to report dead code for
the code ranges indiced by `^`:
Null myNullVar = null;
myNullVar?[index];
// ^^^^^^ DEAD_CODE
myNullVar?[index] = value;
// ^^^^^^^^^^^^^^ DEAD_CODE
myNullVar?.method();
// ^^^^^^^^ DEAD_CODE
myNullVar?.property;
// ^^^^^^^^ DEAD_CODE
myNullVar?.property = value;
// ^^^^^^^^^^^^^^^^ DEAD_CODE
Note that the bug was confined solely to the logic that reports the
DEAD_CODE warning; there is no change to the reachability inferred by
flow analysis (and hence, this is a non-breaking change).
Fixes https://github.com/dart-lang/sdk/issues/60364.
Bug: https://github.com/dart-lang/sdk/issues/60364
Change-Id: I068826282fba6b9057e9c27d1d9310c65714e203
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416723
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The getter `SharedType.nullabilitySuffix` is replaced by
`SharedType.isQuestionType`, which returns a boolean.
The method `TypeAnalyzerOperations.withNullabilitySuffixInternal` is
replaced by `SharedType.setNullabilitySuffix`, which accepts a
boolean.
Support for `*` types has been removed from `mini_types.dart`.
A few test cases in `flow_analysis_test.dart` previously used `*`
types as a way of exercising corner cases involving types that were
mutual subtypes of each other. These tests have been changed to take
advantage of the fact that `dynamic` and `Object?` are mutual
subtypes.
Change-Id: Id9904f9570fc738b388192db8536848204af03e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/414581
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This field was only used to populate expectation strings in "id"
tests; it did not affect any user-visible behavior of the analyzer or
CFE.
Including information in "id" tests that doesn't affect any
user-visible behavior isn't helpful. Removing this field will enable
some upcoming flow analysis refactoring work (I intend to remove the
`ExpressionInfo._type` field, replacing its remaining usages with a
more reliable mechanism).
Change-Id: Id4c6593fae4ef25b8c21f0625e6c1f9eaa766e17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406403
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This moves the creation of class builders for anonymous mixin application to after the creation of the normal class builders.
A ClassDeclaration interface is added to support class builders from different fragments. This is also a step towards creating class builders fully through fragments.
TEST=existing
Change-Id: Ia6b4a17648bdc89b89fd3cfdfe39d24d347b6341
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/407420
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This removes the support running macros in the CFE.
The scanner and package:kernel still have support for the macro modifier. This will be removed in a follow-up.
The metadata expression parser is deliberately left in, since it might serve as the basis for a parser AST.
Change-Id: I06d91eb0fac2e7a71e6afde647b03be3814dbd5f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406963
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Morgan :) <davidmorgan@google.com>
This updates the exhaustiveness checking to return the shortest witness when no more cases match a value.
This also fixes an exponential case that occurred when checking for reachability.
Closes#59927
Change-Id: I82ede75113ca5d361875620287f7ce3c5fb2f5d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/405120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Since the class `TypeConstraintGatherer` (which is only used in
`_fe_analyzer_shared`'s unit tests) is now used both by
`type_constraint_gatherer_test.dart` and by `mini_ast.dart`, it makes
sense for it to live in its own file.
Change-Id: I7c8a58cfbf3724e2c8313b701345bc47ce032522
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404060
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@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>
The following shared getters are renamed so that their names are
distinct from the corresponding getters in the analyzer:
- `SharedFunctionTypeStructure.positionalParameterTypes` is renamed to
`positionalParameterTypesShared` to be distinct from the analyzer's
public getter `FunctionType.positionalParameterTypes`.*
- `SharedFunctionTypeStructure.returnType` is renamed to
`returnTypeShared` to be distinct from the analyzer's public getter
`FunctionType.returnType`.
- `SharedNamedFunctionParameterStructure.type` is renamed to
`typeShared` to be distinct from the analyzer's public getter
`FormalParameterElement.type`.
- `SharedNamedTypeStructure.type` is renamed to `typeShared` to be
distinct from the analyzer's public getter
`RecordTypeNamedField.type`.
- `SharedRecordTypeStructure.positionalTypes` is renamed to
`positionalTypesShared` to be distinct from the analyzer's public
getter `RecordType.positionalTypes`.*
- `SharedRecordTypeStructure.sortedNamedTypes` is renamed to
`sortedNamedTypesShared` to be distinct from the analyzer's public
getter `RecordType.sortedNamedTypes`.
- `SharedTypeParameterStructure.bound` is renamed to `boundShared` to
be distinct from the analyzer's public getter
`TypeParameterElement2.bound`.
*Note that `FunctionType.positionalParameterTypes`,
`RecordType.positionalTypes`, and `RecordType.sortedNamedTypes` were
unintentionally exposed as part of the analyzer's public API. In a
previous CL I marked them as deprecated.
These renames pave the way for changing the analyzer's `DartType`
class so that it implements `SharedTypeStructure<TypeImpl>` rather
than `SharedTypeStructure<DartType>` (without the renames, the public
getters mentioned above would all have to be changed to have type
`TypeImpl`, and that in turn would expose `TypeImpl` through the
analyzer public API, which we don't want to do).
Once `DartType` implements `SharedTypeStructure<TypeImpl>`, that will
allow all the other uses of `SharedTypeStructure<DartType>` in the
analyzer to be gradually migrated to
`SharedTypeStructure<TypeImpl>`. Once that is done, `DartType` can be
changed so that it no longer implements
`SharedTypeStructure<TypeImpl>` at all (`TypeImpl` will implement
`SharedTypeStructure<TypeImpl> instead). This will free us up to make
future changes to the `SharedTypeStructure` base class without
inadvertently exposing those changes through the analyzer public API.
This is part of a larger arc of work to change the analyzer's use of
the shared code so that the type parameters it supplies are not part
of the analyzer public API. See
https://github.com/dart-lang/sdk/issues/59763.
Change-Id: I0686fdeae304f8948484516f0249841b79e7da6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403625
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The following shared getters are renamed so that their names are
distinct from the corresponding getters in the analyzer:
- `SharedFunctionTypeStructure.sortedNamedParameters` is renamed to
`sortedNamedParametersShared` to be distinct from the analyzer's
getter `FunctionTypeImpl.sortedNamedParameters`.
- `SharedFunctionTypeStructure.typeFormals` is renamed to
`typeParametersShared` to be distinct from the analyzer's getter
`FunctionTypeImpl.typeFormals`.
- `SharedNamedFunctionParameterStructure.name` is renamed to
`nameShared` to be distinct from the analyzer's getter
`ParameterElement.name`.
- `SharedNamedTypeStructure.name` is renamed to `nameShared` to be
distinct from the analyzer's getter `RecordTypeNamedFieldImpl.name`.
These renames pave the way for switching the analyzer's use of these
shared types over to the new element model. They're necessary because
when the analyzer switches over to the new element model:
- `FunctionTypeImpl.sortedNamedParameters` will no longer have the
correct type to override
`SharedFunctionTypeStructure.sortedNamedParameters`; instead, it
will be necessary to convert each named parameter to a corresponding
element in the new element model (`FormalParameterElementImpl` or
`ParameterMember`).
- `FunctionTypeImpl.typeFormals` will no longer have the correct type
to override `SharedFunctionTypeStructure.typeParametersShared`;
instead, it will be necessary to use
`FunctionTypeImpl.typeParameters` (which is a list of
new element model type parameters).
- `ParameterElementMixin` will no longer implement
`SharedNamedFunctionParameterStructure`; instead,
`FormalParameterElementImpl` and `ParameterMember` (which are
classes in the new element model) will implement it. The class
`FormalParameterElementImpl` deliberately doesn't have a `name`
getter; instead it has a `name3` getter, with slightly different
semantics (it returns `null` rather than the empty string when there
is no name).
Change-Id: I629e45b6fc588e6a86f7590aab853064e31ab661
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/402220
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Paul Berry