This updates the checking order of the exhaustiveness algorithm to
process the sealed type on its own before checking the subtypes. This
has the benefit that for fields that fully covered by (a supertype of)
the sealed type itself, like a wildcard pattern, we avoid checking
each individual subtype.
For the exponential cases added in
https://dart-review.googlesource.com/c/sdk/+/291800
this avoids the exponential growth, bringing the number of checked
witness candidates from 837932 to 6 for the "subtype" test with n = 30 and from 12207032 to 12 for the "fields" test with n = 10.
The change also fixes a problem in the 'future_or_members.dart' caused by the non-null version of 'FutureOr<dynamic>' still being nullable. The old algorithm tried to use 'Object' as a witness canditate but filtered out 'FutureOr<dynamic>' because 'Object' wasn't a subtype if it. The new algorithm starts by using 'Object?' and therefore sees that 'FutureOr<dynamic>' exhausts it. This is an inherent problem in the modelling of StaticType and it should still be addressed.
Change-Id: Iaa5d5604afc4662fe1983d670638223eae5dbf6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291822
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This updates the toString on Witness to produce pattern code. The
created pattern is directly derived from the predicates of the
witness and there contain some needless precision, for instance
`[...[...]]` instead of `[...]`. It is the plan to address this in
a follow-up.
Change-Id: Ied7930f36b1e1818540b8c635b18ff92f28e113b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290720
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds support for exhaustiveness checking of list types by
contextually dividing the list type into relevant cases for checking.
For instance, the exhaustiveness can be achieved by a single pattern
case [...]:
or by two disjoint patterns:
case []:
case [_, ...]:
When checking for exhaustiveness, witness candidates are created and tested against the available cases. This means that the chosen candidates must be matched by at least one case or the candidate is considered a witness of non-exhaustiveness.
Looking at the first example, we could choose `[...]`, the list of
arbitrary size, as a candidate. This works for the first example, since the case `[...]` matches the list of arbitrary size. But if we tried to use this on the second example it would fail, since neither `[]` nor `[_, ...]` fully matches the list of arbitrary size.
A solution could be to choose candidates `[]` and `[_, ...]`, the empty list and the list of 1 or more elements. This would work for the first example, since `[...]` matches both the empty list and the list of 1 or more elements. It also works for the second example, since `[]` matches the empty list and `[_, ...]` matches the list of 1 or more elements.
But now comes a third way of exhaustively matching a list:
case []:
case [_]:
case [_, _, ...]:
and our candidates no longer work, since while `[]` does match the empty
list, neither `[_]` nor `[_, _, ...]` matches the list of 1 or more
elements.
This shows us that there can be no fixed set of witness candidates that we can use to match a list type.
What we do instead, is to create the set of witness candidates based on the cases that should match it. We find the maximal number, n, of fixed, i.e. non-rest, elements in the cases, and then create the lists of sizes 0 to n-1 and the list of n or more elements as the witness candidates.
Change-Id: I27d594699a65510636a2b7811c60c261a02f9b57
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287680
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Only the fields of a scrutinee type that are used in the cases are
now shown in the test expectations. When the field is not present,
for instance when the scrutinee type is nullable, or the fields are
only present on (some of) the subtype of the scrutinee type, the
fields are shown to be missing with a `-`.
Change-Id: I2d36b230e979dc929d083cfb8f9cdb9f1143d380
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287280
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This remove the [Space] class from the old algorithm and instead
encodes the patterns into the new model. The [Pattern] and
[Patterns] classes of the new model have been renamed to
[SingleSpace] and [Space], respectively, and a [Path] class is
added to track the path property used in the model of the new
algorithm.
Change-Id: I0c86c738807030be2f9b59f3aefb5bfcf5bbaeee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286501
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds support for generic types in exhaustiveness checking.
There are two main obstacles:
1) Types that are not Dart subtypes might be related in the context
of exhaustiveness. For instance
sealed class A<X> {}
class B extends A<num> {}
method<T>(A<T> a) {
switch (a) {
case B(): ...
}
}
Here B is not a Dart subtype of A<T> but must still be a subtype
in the context of exhaustiveness since T could be num at runtime.
2) It is non-trivial to compute the subtypes of a generic sealed class
that is both sound and precise enough to be useful. For instance
sealed class A<X> {}
class B extends A<num> {}
class C<X> extends A<X> {}
class D<X extends num> extends A<X> {}
class E<X extends E<X>> extends A<X> {}
Computing the subtypes of A<F> for some type F, we would like to
exclude B (assuming F is not a supertype of num) because it
cannot be inhabit A<F>, and include C<F> so that we recognize
that C<F> exactly covers all C instances of A<F>. We would also
like to include D<F> but if we don't include the added `extends
num` bound, we might conclude that D<num> is _not_ sufficient to
cover D<F>. And what to do about E, can we even come up with a
type that represents the valid values?
The solution is threefold:
1) We add an 'overapproximate' function of types, which
replaces all type variables with their default types. This will compute
A<dynamic> for A<T>, A<int> for A<int>, A<List<dynamic>> for A<List<T>>,
and E<dynamic> for E<T extends E<T>>. This is similar to instantiate-
to-bounds, but is recursive.
We use this to test whether a type without type variables is a potential
subtype. For instance testing B <: overapproximate(A<F>) = A<F> shows
that B _cannot_ be a subtype of A<F>, and testing
B <: overapproximate(A<T>) = A<dynamic> shows that B _can_ be a subtype
of A<T>.
2) For finding subtypes of a sealed type, we recognize the case
when a type is a trivial subtype in which all type variables are passed
directly to the superclass, for instance like C<T> in the example. For
other cases we overapproximate the this type of the subclass.
3) To ensure that the [StaticType] can be subtype in the normal Dart
sense but also handle the overapproximation when computing sealed
subtypes, a new [WrappedStaticType] is added. This bridges the subtype
relation such that for instance B, when created as a sealed subtype
of A<T>, is both a subtype of A<num> (as it normally is) and of A<T>,
which it is by construction.
Change-Id: I9970c46009938ef15625e1193faf916b7544ce0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284681
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds the initial implementation of exhaustiveness checking in
the analyzer and CFE. The checking is currently only performed in
switch statements and only handle a subset of the patterns.
Change-Id: Ia0050c2c80fbefe3e22615599136f9d919ebe4ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279173
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@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 is necessary to separate `ClassElement`, `EnumElement`, and `MixinElement`. And, in the future, augmentations like `ClassAugmentationElement`, etc.
Change-Id: Iecd2f8707212e53ef56f0e101880c7bab9e5d057
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254104
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
For `InterfaceType` keep `element2` deprecated and define
`InterfaceElement get element2` instead. Most changes are because
of this.
Change-Id: I13b888610fc707438c3c97b676f1460e7fc2b040
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253564
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Each variable is mapped to a unique integer "promotion key", which is
used as an index into the `FlowModel.variableInfo` map. This paves
the way for adding entries to `FlowModel.variableInfo` to represent
promoted properties. It also cleans up the previous hacky way we used
to use `null` as a map key to represent `this`.
In a future CL I plan to try to replace `FlowModel.variableInfo` with
a list rather than a map. This should improve both memory and CPU
usage.
As a side effect of this change, many classes related to flow analysis
no loger need a `Variable` type argument, including the `EqualityInfo`
class (which is exposed to clients).
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I853ca835c6b36ab9865bd187973c6524a7471db0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In most case, id testing annotations can be regenerated automatical.
This updates the error reporting to include the regeneration commands.
The test system now also runs all tests in case of failures instead of
stopping after the first found failure.
Change-Id: Ice865bddccd8d1da416a1072b3927ed6adfa48fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240048
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Cases where `null` was being passed as an argument to formatting a
message have all been fixed in previous CLs; all that remains to do is
change the type system to reflect that, and insert `!`s in a few
places.
This brings us one step closer to being able to make analyzer message
formatting type safe.
Change-Id: Id9e0d0b32f29cde0fdc5227417b7a2e3fc3b443d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216272
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
It is not a huge improvement, because it does not add static safety,
for this we would need to distinguish between unresolved and resolved
expressions, as separate types.
But it is still an improvement.
1. We get to know the node that was not resolved.
Maybe not enough, in case if it was because of the enclosing
now that this node was not resolved. But still something.
2. We group this use case into one place.
Change-Id: I2e8f029e8a5fcd8ccecdd1b6bc9d78ee9eaf12a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184103
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The CL to add why_not_promoted_test.dart and the CL to remove
NullSafetyUnderstandingFlag landed around the same time, so we failed
to notice the conflict between them. The fix is easy: since
NullSafetyUnderstandingFlag doesn't exist anymore (and isn't needed
anymore), we can just remove this use of it.
Fixes bot failures with the test
`pkg/analyzer/test/id_tests/why_not_promoted_test`.
Change-Id: Icec2d57d371229f103b42c5e25d49aab952adc1a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182340
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL implements the core flow analysis infrastructure for tracking
reasons why an expression was not promoted. It supports the following
reasons:
- Expression was a property access
- Expression has been written to since it was promoted
I expect to add support for other non-promotion reasons in the future,
for example:
- `this` cannot be promoted
- Expression has been write captured
- Expression was a reference to a static field or top level variable
These non-promotion reasons are plumbed through to the CFE and
analyzer for the purpose of making errors easier for the user to
understand. For example, given the following code:
class C {
int? i;
f() {
if (i == null) return;
print(i.isEven);
}
}
The front end now prints:
../../tmp/test.dart:5:13: Error: Property 'isEven' cannot be accessed on 'int?' because it is potentially null.
Try accessing using ?. instead.
print(i.isEven);
^^^^^^
Context: 'i' refers to a property so it could not be promoted.
Much work still needs to be done to round out this feature, for example:
- Currently the analyzer only shows the new "why not promoted"
messages when the "--verbose" flag is specified; this means the
feature is unlikely to be noticed by users.
- Currently the analyzer doesn't show a "why not promoted" message
when the non-promotion reason is that the expression is a property
access.
- We need one or more web pages explaining non-promotion reasons in
more detail so that the error messages can contain pointers to them.
- The analyzer and front end currently only show non-promotion reasons
for expressions of the form `x.y` where `x` fails to be promoted to
non-nullable. There are many other scenarios that should be
handled.
Change-Id: I0a12df74d0fc6274dfb3cb555abea81a75884231
Bug: https://github.com/dart-lang/sdk/issues/38773
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181741
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
We now track the following additional information:
- All local variable reads and read captures (previously we only
tracked writes)
- For any conditional expression (`?:`) or if-test, the variables
written in the "then" branch
- For any logical and expression (`&&`), the variables written in the
right hand side of the expression
Tracking this information will allow us to implement legacy type
promotion as part of _fe_analyzer_shared, using the same API as flow
anaylsis, which will in turn allow a lot of front end and analyzer
code to be removed and simplified.
Change-Id: I01aaf64cefb989a4450c8e6d3a8373c1ca2b6dec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179980
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This adds some technical debt in form of using writeOrReadElement in
clients, which can be paid incrementally by migrating these places to
handling assignment like expressions one by one. Doing it all in one
CL was too much. But now the underlaying AST resolution will be
sound.
In the next breaking change we will remove
setAssignmentBackwardCompatibility(), so stop setting elements/types
for assignment targets.
Change-Id: I11626876cfed25653edb0cc18544aba51cef5965
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/165622
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Johnni Winther