Looking at instructions this seems to speedup compilation of
`compile.dart` with about 1.00% in AOT mode.
Occasionally there's also a measurable time improvement, e.g.
```
msec task-clock:u: -1.3447% +/- 1.1644%
seconds time elapsed: -1.3438% +/- 1.1638%
seconds user: -1.8838% +/- 1.4478%
```
Change-Id: I98866740b00bc01c70dd82d7591864bcb278394d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303701
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When compiling "compile.dart" the type given to computeNonNull
is already non-nullable in ~42% of the cases, meaning it spends
time not doing anything.
Change-Id: I94598efceb3b46f0ac81ec36814c216d01a9e38b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298823
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This uses the required type instead of the lookup type for object
patterns to ensure that extension members are accessed correctly.
Change-Id: I05b4765f1fa3f85acd005a0484349b467cff7c9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292703
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This changes the analyzer and CFE to use the real exhaustiveness
checking algorithm. The fallback algorithm is kept and will be
removed once we know that the real exhaustiveness algorithm sticks.
Change-Id: Ic9df92c1ca9f7dec4cbdfa138dc6ed39ef2d4df5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288703
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This removes the "unset" values and uses nullable types instead.
The names and uses of the pattern fields are normalized, using
`matchedValueType`, `requiredType` and `lookupType` consistently
between [Pattern] subclasses.
TEST=existing
Change-Id: Ic79ce17075aa8ce252e1c223b59bef660f32bb7c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288704
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This removes the use of [SwitchInfo], [SwitchCaseInfo] and
[ExhaustivessInfo] to pass on information for exhaustiveness checking
and instead uses the AST nodes directly in the constant evaluator.
Change-Id: Ie8d72b03e38334d1be9857794c38ed142dba5783
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288402
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
The key can only be an Expression but was unneedingly wrapped in
a ConstantPattern. Since the shared type analysis only handles
map pattern keys as expressions, the expected properties of
ConstantPattern were not set. Amongst these were the static type
of the key expression, which is know passed directly to the
handleMapPatternEntry method.
Change-Id: I705fc655e440d534ccc442c9c1359c377955b3b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288282
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@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 replaces the [Library] parameter from bounds checks and
type inference methods with a `isNonNullableByDefault` parameter,
enabling usage of these algorithms in library-agnostic code, like
features only available post-nnbd.
Change-Id: Id565d00e1c20d25e7e3388badbb2d7f11c015802
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284642
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
The representation field of an inline class is not part of the
generated code - it does not have a corresponding synthesized top-level
methods like the other inline class members. Therefore, to support
access to the representation field, a new `representationName` field
is added to `InlineClass` that holds the name by which the
representation field can be accessed.
An access to the representation field is at runtime an access of the
receiver itself. To show that the static type of the expression changes
from the inline type of the receiver to the declared representation
type, an `AsExpression` is inserted. Since this check is not needed
at runtime, this node is marked with the new `isUnchecked` flag, that
backends can use to skip the check.
TEST=pkg/front_end/testcases/inline_class/field_access.dart
Change-Id: I635af414af2ddc541352078766ce57a9d8ded601
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277983
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
For now it's only done for unevaluated constants as that's where an
issue has been observed.
This CL further more limits the default nesting depth for both
expressions and statements (e.g. when .toString() printing an ast node)
to 50. Again this has been shown in one case to be a good place to
stop an (exponential time) issue from happening.
Change-Id: I6affb2846a6587542ffce3f8d6914a4209b08322
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251103
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Adds a replacement visitor for Constant types using null as a
sentinel value for whether a subnode has changed or not (except
in the case of TreeNodes in order to match existing Visitor
semantics).
Change-Id: Iaaab1b1c608af07f36ece08071b3d703884cd91b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248944
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Johnni Winther