Change a pair of package tests that relied on the existence of the
VM's Dart 1 platform Kernel binary. Use the Dart 2 platform instead,
becuase the VM will stop supporting Dart 1 in the future.
Change-Id: Ic93488974d9ed53cd205dcc24e0455a26b5f71b2
Reviewed-on: https://dart-review.googlesource.com/71246
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Before this CL, if initializing from a dill file containing a class,
say A, but it wasn't used, and then later using it as a type, say
'A a = new A()', the class hierarchy would complain about not knowing A.
This was caused by the class hierarchy initially being constructed using
the full component of the first compile (i.e. in the example above
without any usage of A and thus without including A), and subsequent
compiles telling the class hierarchy about new classes created in that
compile. The problem was, that if the class was loaded from a dill file
(in the example above 'A' was such a class) it would never be included
if not a part of the first full component.
This CL fixes it by changing the interface to the class hierarchys
`applyTreeChanges` function and letting the class hierarchy know about
libraries too: It will now basically just be given the full component
when asked to update, and just update with the libraries it doesn't
already know about. In the example above that would - once using 'A' -
include 'A'.
Change-Id: I895100b51659938636da0bca6c80516d87b57a24
Reviewed-on: https://dart-review.googlesource.com/69302
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL turns the ClassHierarchy incremental and use that in two places:
* When compiling incrementally
* When performing the second ClassHierarchy computation after adding
forwarding stubs.
Change-Id: I7046d6be9d7673dc0783a98789b5a25183b44799
Reviewed-on: https://dart-review.googlesource.com/53804
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Metadata is no longer written ahead of all nodes. Instead, metadata for
each node is written in the same context as the node itself (into a separate
buffer). This allows metadata to contain (serialize) arbitrary nodes
(for example, arbitrary DartTypes) and use serialization context of parent
nodes (such as declared type parameters).
However, with this change metadata looses the ability to reference
arbitrary AST nodes. This ability was overly restricted and had no
practical uses. (It was not possible to reference nodes which are not
reachable from root Component. As a consequence, it was not possible to
write references to arbitrary DartTypes.)
This change aligns the serialization capabilities of metadata with
how kernel AST nodes are serialized.
Change-Id: I027299a33b599b62572eccd4aa7083ad1dd2b3b3
Reviewed-on: https://dart-review.googlesource.com/54481
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL:
* Removes unused functions in the ClassHierarchy
* Turns the data structures used in the ClassHierarchy upside down
(nodes have a lists of supers instead of lists of subs)
* Factors some things that needs the original list-of-subs into another
class that the user can ask the ClassHierarchy to compute if needed.
It appears that it isn't generally.
This is step #1 in turning the ClassHierarchy into an incremental
ClassHierarchy.
Change-Id: I48c5731c01c1b0e8bf1fcd4ddba7f2bf7ce3b9c9
Reviewed-on: https://dart-review.googlesource.com/53662
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This CL adds a test that bootstraps from a dill with a deferred library
in it. Before this CL it crashed, see bug #32245.
This CL "double fixes" the problem:
a) When lazy loading a dill file the _currentLibrary variable wasn't set
properly. This has been fixed.
b) When bootstrapping from a dill file, (almost) everything in the dill
will be included in the output so lazy loading it doesn't make sense.
Bug: 32245.
Change-Id: I94980608e19633fd31b522651a4a05b9cf7beabd
Reviewed-on: https://dart-review.googlesource.com/42600
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This change helps in confining flag manipulation to just the embedder.
When we are ready to turn all dart 2 flags to true by default, the
change can be confined to just the VM.
Change-Id: I4ac550c331b1f236a2bd9d0453b7c567eb0c05d3
Reviewed-on: https://dart-review.googlesource.com/38881
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Implemented more efficient way to iterate ClassSet in class_hierarchy.dart,
ClassSet becomes Iterable<Class>. This considerably improves speed of
ClosedWorldClassHierarchy.getSingleTargetForInterfaceInvocation() and
CHA-based devirtualization.
Time of CHA-based devirtualization on Flutter Gallery reduced
from ~13.4s to ~1.2s.
Also, ClassHierarchy used in devirtualization is configured to ignore
ambiguous supertypes to avoid crashes on Flutter Gallery.
Change-Id: Iaca251ca268aad3d8bb652247650096f19c25839
Reviewed-on: https://dart-review.googlesource.com/38960
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Since 'DartType's overload equality with a structural comparison, we cannot
store metadata for them in a 'Map', as is done for 'TreeNode's. Since there is
no use-case yet for storing metadata on types, we remove this ability and the
restrict the metadata test.
Bug:
Change-Id: I825f55a5fd48da2c615b3154f909dd666baf5a33
Reviewed-on: https://dart-review.googlesource.com/14640
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This method is no longer needed, since the front end iterates through
members directly to find cross overrides.
Change-Id: Ibc5180962a097c4d6194dbf4cbd1a0dea15050c2
Reviewed-on: https://dart-review.googlesource.com/13582
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This separates compiling platform.dill files from the patch_sdk.dart
script. The motivation for that is that I'm working on reading patch
files directly from Fasta, so we can completely remove the build step
for generating patched_sdk and dart2js_patched_sdk.
Short-term this should allow Paul to add a strong-mode version of
platform.dill without causing to many conflicts with my work on
patches.
Change-Id: I1150845b2986348d4fffe27092701d8a9b57ea54
Reviewed-on: https://dart-review.googlesource.com/11506
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This allows creating strong mode TypeEnvironments without actually subclassing
it.
Make SubtypeTester.isBottom treat Null as Bottom in strong mode.
Bug:
Change-Id: Icdd1a4b736ce0fe839a6ef30cf24487111f32d25
Reviewed-on: https://dart-review.googlesource.com/11882
Reviewed-by: Paul Berry <paulberry@google.com>
This section contains a linear mapping between offsets of serialized nodes
and associated opaque binary metadata.
Note: this CL does not yet update C++ reader and only implements metadata in Kernel package.
C++ implementation will be updated if we agree that format seems flexible enough.
Bug:
Change-Id: Id433458afc6c2ea76c72f6a1901b9dc55b8f1696
Reviewed-on: https://dart-review.googlesource.com/9340
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
1. We no longer remove type parameters on functions.
2. We no longer remove type arguments at call sites.
3. We allow non-captured function type parameters to be used outside closures.
Bug:
Change-Id: I116ec54c90b04be90e1157042c22797e57a7c51c
Reviewed-on: https://dart-review.googlesource.com/9342
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This CL adds the ability to create a list of "forwarding nodes" for a
source class. A forwarding node is a data structure that will later
be resolved to either an explicitly declared member in the class or a
superclass, or to a forwarding stub. The idea is that we will create
the forwarding nodes at the time of outline building, and later,
during type inference, we will resolve each forwarding node as it is
encountered.
The reason we need to defer resolution of the forwarding nodes until
inference is because we may need to use the results of type inference
to determine which member a given forwarding node resolves to. For
example:
num f() => 1;
class A {
final x = 1; // Inferred type: int
}
class B {
final x = f(); // Inferred type: num
}
abstract class C implements A, B {}
We cannot determine at the time of building the outline for C whether
it inherits its x from A or B, because we need the results of type
inference to determine which of the two x's has a more specific type.
Note that some refactoring of ClassHierarchy was necessary in order to
allow the front end to maintain member lists in the same order used
internally by ClassHierarchy. This will let us avoid unnecessary
redundant sorting of methods.
Change-Id: Iee754957e0ad3b16c4b60608e17a4a7b0006dfb4
Reviewed-on: https://dart-review.googlesource.com/7851
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This will allow tests that use batch_util.dart to be run inside
google3, where package layout conventions are more strictly enforced
(files in test/ cannot import files in bin/ or vice versa).
Change-Id: I046b864bc3b1c4e78b984b0047b7567873146c52
Reviewed-on: https://dart-review.googlesource.com/7340
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Note that the parser used for unit tests in kernel didn't have a
notation for promoted bounds. I chose `T & A` to mean "type parameter
T with promoted bound A", following Leaf's convention (the rationale
is that semantically, a promoted bound functions like an intersection
type).
It was also necessary to change the test infrastructure so that we
could specify the (non-promoted) bounds of type parameters when
running a subtype test.
Fixes#30833.
Change-Id: Ic62722df63c5ed5288b23560745a1cd0869b63fb
Reviewed-on: https://dart-review.googlesource.com/7628
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL adds a new target for kernel front-end, vm_precompiler. This is
an experimental target for new Dart VM precompiler pipeline which
will fully exploit strong mode type system and perform whole-program
optimizations.
As an example of such whole-program optimization, this CL adds
draft implementation of devirtualization of method invocations, which
uses single target computed by closed-world class hierarchy analysis.
Corresponding null checks (required for correctness) are not generated
yet.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I704cd16843a08f036a188b1188c80ee4dfbeab3b
Reviewed-on: https://dart-review.googlesource.com/3402
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This reverts commit e81deebfd8.
My reasoning in the above commit was wrong. Consider the following code:
class A {
void foo() {}
}
abstract class B extends A {
void foo([x]);
}
class C extends B {}
main() {
B b = new C();
b.foo(42); // BAD: A.foo can't accept arguments.
}
To ensure soundness, this code needs to be disallowed, and the current
mechanism for doing that is to use forEachOverridePair. Note that
forEachOverridePair is a bit of a misnomer; in addition to yielding
all pairs of methods (M1, M2) for which M1 overrides M2, it also
yields pairs of methods (M1, M2) for which the target class inherits
the concrete implementation M1, and M2 is part of the interface.
Technically this latter case is not an "override" but rather an
"implementation" (thanks to Lasse for pointing out this distinction).
However in both cases we need to do the same compile-time check to
ensure soundness: we need to check that the type of M1 is a subtype of
M2 (unless the check is suppressed by a "covariant" keyword). Hence
it makes sense for forEachOverridePair to cover both cases.
To ensure that the above example is properly rejected, it is crucial
that some invocation of forEachOverridePair yield the pair (A.foo,
B.foo). Prior to e81deebfd8,
forEachOverridePair(B) would not yield this pair, but
forEachOverridePair(C) would. After
e81deebfd8, both calls yield this pair.
When I made e81deebfd8, I failed to
notice that forEachOverridePair(C) would yield the pair, so I thought
there was a problem. So my "fix" was unnecessary. And it created a
fresh problem: it meant that the following code would be disallowed:
class A {
void foo() {}
}
abstract class B extends A {
void foo([x]);
}
class C extends B {
void foo([x]) {}
}
main() {
B b = new C();
b.foo(42); // OK: C.foo can accept an argument.
}
There is no a priori soundness reason for rejecting this code, and
according to Lasse, it has not yet been decided whether Dart 2.0 will
allow it.
This CL restores the old behavior. Rather than remove the test case
in e81deebfd8, it modifies it to
demonstrate why the old behavior was correct.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/3004023002 .
ClassHierarchy.forEachOverridePair contains special logic for unusual
cases like this one:
class A {
void foo() {}
}
class B extends A {
void foo();
}
main() {
B b = new B();
b.foo();
}
In this case, A.foo is considered to override B.foo (contrary to the
usual situation where the derived class method overrides the
superclass method). The reasoning is that calling foo on a concrete
instance of B will cause A.foo to be executed (as illustrated in
main); therefore A.foo is callable via the interface of B.foo, thus in
a sense A.foo "overrides" B.foo.
The code contained a questionable optimization, however; it only
executed this special logic if the derived class was concrete.
Presuambly the reasoning was that if B were abstract, then a concrete
instance of B could never be created, so this situation could never
arise.
However, there is nothing to stop a concrete class from being derived
from B, e.g.:
class A {
void foo() {}
}
abstract class B extends A {
void foo();
}
class C extends B {}
main() {
B b = new C();
b.foo();
}
Now, calling foo on a concrete instance of C will cause A.foo to be
executed (as illustrated in main); therefore A.foo is callable via the
interface of B.foo, as before. So we still need to report this as an
override pair even though B is abstract.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2998383002 .
Summary:
Previously, we use the "Vector" type in the kernel tree for the result of the
"VectorCreation" operation as as the parameter type for converted closure
functions. In the VM, we use the "Context" type instead, which the VM treats a
little differently than normal Dart-visible types, and it doesn't not handle
type checks against it correctly, breaking all closure converted code running in
checked mode.
Now, Since we are forced to use dynamic to represent the types of elements of
the context, we may as well just use dynamic for the context type itself.
Previously, we did not correct handle converted closure type checks for closures
that capture type parameters. The way we handled these type checks also had
several latent bugs that prevented type parameters being handled properly.
Now, we handle type parameters for converted closures similarly to normal
closures, and the places we treat them specially are fewer and more integrated
with the rest of the closure type checking code.
There is still a problem where assignments to captured variables are not
checked, because they are transformed to assignments into the context, whose
elements are necessarily untyped. This breaks many co19 tests, which expect type
errors on these assignments. The example below should error in checked mode, but
after closure conversion is runs with no errors.
int b;
bool c;
(() { b = c; })()
Test Plan:
- All test cases in "pkg/kernel/testcases/closures" now run in checked mode.
- Added a test "closures_types.dart" to check that captured type parameters are
handled correctly in the converted closures' signature types.
R=dmitryas@google.com
Review-Url: https://codereview.chromium.org/3007623002 .
The front end will need to use this method to iterate through the
interface of a class in order to determine when to create forwarding
stubs.
The functionality already exists; this CL merely exposes it and adds
tests.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/3003913002 .
Kevin Millikin