New type of AST nodes RedirectingFactoryConstructor is added to Kernel.
The goal is to keep the information about redirecting factory
constructors in the class for the linking phase.
Change-Id: I7477c617fa7fd4935ceb23098ec7c056d1f286ca
Reviewed-on: https://dart-review.googlesource.com/14740
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This fixes some incorrect asserts that were breaking the debug bots.
The original revision is available in Patchset 1.
This reverts commit 26735519cb.
Bug:
Change-Id: Ifa599b7bff752dec4c505e10fd6db206e1abd977
Reviewed-on: https://dart-review.googlesource.com/23820
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Samir Jindel <sjindel@google.com>
This reverts commit f13f772bb2.
Reason for revert: dartk(p)-strong debug mode is completely broken
because we convert int values non-representable as Smi to Smi, which
triggers that assert. The code that does tagging checks that
Untag(Tag(x)) == x, however for our purposes this identity does not
need to hold because we only care about lower bits and ignore the sign.
Reverting to restore green-ness of DEBUG builds.
TBR=sjindel@google.com
Bug:
Change-Id: Id436cbe000d6dec8db3469070ed531327cc82d89
Reviewed-on: https://dart-review.googlesource.com/23661
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The code for reading dill files via dart has a "debugPath" list that is
continously added and removed to in order to be able to debug what went
wrong if something goes wrong (e.g. if the dill file is invalid or the
reading code is wrong etc).
This CL wraps the updates of this list in assert so that we don't pay
for what we don't use in the general case. In a debug setting we can get
the functionality back via --checked.
On a benchmark of 10 runs, the time it takes to read vm_outline.dill 100
times after a 2 second warmup changes by -2.77% +/- 1.21%.
Bug:
Change-Id: I643b8dd778972621046fe76b536fd95e9bb66d1c
Reviewed-on: https://dart-review.googlesource.com/18820
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL adds the bare minimum of source map generation for the kernel
pipeline in DDC.
It additionally introduces a testing framework that compiles dart files
with DDC (with or without kernel), steps through it via D8 and compares
the positions stopped at to the expected stop positions.
Bug:
Change-Id: Ie9e06164d8e51c973b83c46a8472e044876e4317
Reviewed-on: https://dart-review.googlesource.com/20662
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The changes in this CL include:
* handle interface targets also on this dispatch (which happens due
to mixins)
* preserve class members if interface targets refer to them
* remove references to shaken elements in `Library.additionalExports`
* support handling of typedefs
Change-Id: Id8df6fbf5c3428ae9c9f8b11ee9bf80c35a7a091
Reviewed-on: https://dart-review.googlesource.com/21640
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Currently we produce 'partial dills' for the VM when compiling through
kernel, i.e. we only include the user-code and whatever canonical names
the user refers to. That's perfectly fine for the VM as it always loads
the platform.dill file too.
We cannot currently print it though.
(Technically we should be able to concatenate it with platform.dill and
print that).
This CL allows us to print these partial dills without concatenating
anything first.
Bug:
Change-Id: I7d5f12332e16623d02531ad46e2dc103222f59e9
Reviewed-on: https://dart-review.googlesource.com/19002
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
The introduced "constants" transformation can evaluate constant expressions. The
original use-sites of constant expressions are replaced by a new [ConstantExpression]
node, which points to a subclass of a new [Constant] class hierarchy. Constant
[Field]s and [VariableDeclarations]s will be removed, since all use-sites are
re-written.
The [Constant] class hierarchy is, similarly to the [DartType] class hierarchy, not
part of the AST tree (also has no parent pointer). The constants form a
DAG (directed acyclic graph).
There is no canonicalization requirement of the [Constant] objects referenced by the
AST (via [ConstantExpression]). Although it is beneficial to canonicalize them during
construction, since it reduces time spent in operator==/hashCode.
This CL furthermore adds support for a constant table in the binary format. Similarly
to [String]s, we canonicalize the constants before writing the table to the binary.
The constant table entries in the binary are written in a post-order way, to ensure
easy construction on the backend side.
The text format will be augmented with a "constants { ... }" section at the end,
which lists the constants in the same order as in the binary format.
The transformation can be used by those backends who choose to do so. It is not
enabled by default atm. It should therefore not affect analyzer, fasta or other
components.
Change-Id: I57cd9624fedcf537ab6870db76246149647bed21
Reviewed-on: https://dart-review.googlesource.com/14382
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
The VM creates context objects even though it's only applicable in a
non-taken branch. This CL moves such a branch into its own function
and thus avoids the context object creation when loading a dill file
eagerly.
This CL further more reduces the number of context creations by not
lazy loading basically non-existing function node bodies (e.g. the body
of a FunctionNode in the outline).
The change has the following effect when loading platform/outline
100 times after 2 seconds warmup (statistics on 5 runs):
Outline, lazy loading disabled: -12.8133% +/- 2.26214%
Outline, lazy loading enabled: -40.9197% +/- 1.50042%
Platform, lazy loading disabled: No difference proven at 95.0% confidence
Platform, lazy loading enabled: -44.3347% +/- 0.613235%
Bug:
Change-Id: I9634e0a81f43efeb4e2524edb765d36072074f1e
Reviewed-on: https://dart-review.googlesource.com/18220
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Loading vm_platform.dill 100 times after 2 seconds warmup:
Statistics on 5 runs:
It varies to much to tell on the runs I did.
Loading vm_outline.dill 100 times after 2 seconds warmup:
Statistics on 5 runs:
-7.84428% +/- 1.21335% at 95.0% confidence
Bug:
Change-Id: I34bbdca555ec50e1d16a5994c5cb46f845b4a4a3
Reviewed-on: https://dart-review.googlesource.com/18183
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Changes in runtime:
Running python tools/test.py -m release -cdartk language -j6
Statistics on 3 runs:
real -1.21% +/- 1% at 95.0% confidence
user -2.01% +/- 0.29% at 95.0% confidence
sys No difference at 95%
Loading vm_platform.dill 100 times after 2 seconds warmup:
Statistics on 5 runs:
-15.3209% +/- 1.26028% at 95.0% confidence
Loading vm_outlin.dill 100 times after 2 seconds warmup:
Statistics on 5 runs:
-21.9672% +/- 0.48754% at 95.0% confidence
Bug:
Change-Id: I16474e32715df57922376d88baddd17a1cf73663
Reviewed-on: https://dart-review.googlesource.com/17788
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Dart2JS and the VM prefer for Enum names to be stored inline in the Enum
object to avoid having the static array of all Enum values. A base class
for Enums is provided to avoid repeating the common fields and accessors
between Enum definitions.
Bug:
Change-Id: I783f863015b45f13317fda06e627d14844fe2ddf
Reviewed-on: https://dart-review.googlesource.com/16526
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
The kernel format has been designed so that one can concatenate several
dill files into one file and then load it. For instance the dart
function BinaryBuilder.readProgram supports this.
Currently a dill file contains one or more programs.
In the VM each of these programs are called either program or subprogram.
Technically a dill "program" isn't necessarily a program at all (e.g. it
could be missing a library).
This naming snafu should probably be cleaned up at some point, but that's
for another CL.
When loading a dill file via BinaryBuilder.readProgram what happens is
this:
- Each program in the dill file ends in 4 bytes that indicates the size
of the program.
- Reading the input from the end one can then read the size, skip back
that amount of bytes, if we have more data (i.e. there's another
program), read another size and so on, and continue until we have
accounted for all bytes in the input.
- We then read each program from the start, and basically overwrite any
library, class, procedure etc. we find.
The first main reference found is the one used though.
(Saying that we overwrite is not completely true, but when the library
is a non-external library that's basically what happens).
This CL introduces (some) support on the C++ side for the same thing.
So far the C++ side could only handle single-program-dills, and trying
to load anything else would probably crash the VM.
The support added is this:
- Assume the SDK (i.e. vm_platform.dill) is not a concatenated file
(error out if it is).
- For user provided input, loop over each contained program one-by-one,
for each individual one behave as normal.
- The way LibraryLoad is implemented (i.e. it skips if the library is
already loaded) this means that it currently would behave differently
than the dart version (i.e. the first one is used, not the last one).
For now it is assumed that that's not a problem.
- There is a possibly snafu if the same script is included several times.
This could probably mostly be remedied by not creating scripts up front,
but only as needed. By the "keep only one" (and fixing the above point,
probably by simply loading in the opposite order, i.e. last program
in the binary first) the (theoretical) problem would probably do away.
Note that we will have separate string tables, canonical name tables etc
per "sub program" and that there might be some duplication.
The implementation was tested as indicated below, but introduces no tests.
$ cat test_lib1.dart
import "test_lib2.dart" as lib2;
String lib1field = "lib #1 field!!";
main() {
foo();
lib2.foo();
print("From lib2: ${lib2.lib2field}");
}
foo() {
print("Hello, Foo, from test_lib1!");
var x = 42;
print(x);
}
$ cat test_lib2.dart
String lib2field = "Lib #2 field!!!!";
foo() {
print("Hello, Foo, from test_lib2!");
var y = 34;
print(y);
}
$ out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart --packages=.packages --platform=out/ReleaseX64/vm_platform.dill test_lib1.dart
$ ls -lha test_lib1.dart.dill
[...] 4.2M Oct 26 14:42 test_lib1.dart.dill
$ dart pkg/kernel/bin/split.dart test_lib1.dart.dill
Wrote test_lib1.dart.dill.part1.dill
Wrote test_lib1.dart.dill.part2.dill
$ ls -lha test_lib1.dart.dill.part{1,2}.dill
[...] 811 Oct 26 14:42 test_lib1.dart.dill.part1.dill
[...] 582 Oct 26 14:42 test_lib1.dart.dill.part2.dill
$ cat test_lib1.dart.dill.part1.dill test_lib1.dart.dill.part2.dill > test_lib1.dart.dill.concat.dill
$ ls -lha test_lib1.dart.dill.concat.dill
[...] 1.4K Oct 26 14:44 test_lib1.dart.dill.concat.dill
$ out/ReleaseX64/dart --kernel-binaries=out/ReleaseX64 --packages=.packages test_lib1.dart.dill.concat.dill
Hello, Foo, from test_lib1!
42
Hello, Foo, from test_lib2!
34
From lib2: Lib #2 field!!!!
Change-Id: I233a033aa3042b202dd4708908a5be3089474588
Reviewed-on: https://dart-review.googlesource.com/16820
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Otherwise we might match up a getter to a setter and crash.
The test cases indirectly verify that mixin resolution does the right
thing by checking the semantics of the generated code. These tests do
not pass yet, because covariance checks are not yet implemented in the
VM.
Change-Id: Ibe6d8b7479f86151c515c45c20ed7c880bf2ad43
Reviewed-on: https://dart-review.googlesource.com/16686
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Karl Klose <karlklose@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This will allow it to be used by front_end unit tests.
Also plumb through the "ignoreSdk" boolean, since we will need to use
it when invoking the naive type checker from front_end unit tests.
Change-Id: I9ae50f48e24a5c45e93f4218e6b61f193f549e7a
Reviewed-on: https://dart-review.googlesource.com/16601
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously lazy loading was done in Procedure by lazy loading functionNode,
now lazy loading is done (only through Procedure) in the functionNode by
lazy loading the body.
Bug:
Change-Id: I25cc86d038123ed4992162b65aa95781ea2c56e8
Reviewed-on: https://dart-review.googlesource.com/15560
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Before: mixin application classes could not have methods of their
own.
After: type inference will sometimes insert forwarding stubs in mixin
application classes. In the mixin elimination transformation, these
forwarding stubs are replaced with the methods of the mixin class if
they have the same name, but the parameter flags from the forwarding
stub are retained. The other forwarding stubs are left as methods of
the class.
Change-Id: I5ee89d6b1fc83194df82009c2800b54ce856e8c5
Reviewed-on: https://dart-review.googlesource.com/15887
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Jens Johansen