Previously, the front end recovered from an invalid assignment by
producing an "as" expression, e.g.:
int x;
String y;
x = y;
Would produce an "invalid assignment" error, as well as this kernel
code:
int x;
String y;
x = y as{TypeError} int;
The rationale was that the "as" check was guaranteed to fail, so this
code would produce a runtime error at the correct location. However,
there were two problems:
1. (Minor problem) the "as" doesn't actually fail if the RHS is null.
2. (Major problem) for type inference, the type of an assignment
expression is defined to be the type of the RHS. This means that if
the invalid assignment gets used for type inference, we generate
mal-typed kernel code, e.g.:
int x;
String y;
var z = (x = y);
Gets compiled to:
int x;
String y;
String z = (x = y as{TypeError} int);
This CL addresses both problems by changing the kernel representation
so that it evaluates the RHS and then throws an exception. Since a
"throw" expression has type Bottom, the kernel representation is
guaranteed to be properly typed. This also ensures that an exception
gets thrown if the RHS is null. Finally, as a side bonus, it makes
the error-recovered kernel code more similar to the kernel code we
generate in other error recovery scenarios.
Change-Id: Iac74e0c726ce029ac0560d271413e85c15bfec5c
Reviewed-on: https://dart-review.googlesource.com/24140
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL creates the initial DDC-specific CFE entry point.
It is currently mostly a matter of copying the DDC code for running the
front-end into the front-end, although it also applies a workaround for
making batch-mode faster.
Local timings of running
tools/test.py -mrelease -cdartdevk -rnone --strong --checked language_2
before and after change:
* Before: [05:49 | 100% | + 5136 | - 0]
* After: [00:20 | 100% | + 5136 | - 0]
Change-Id: I799b54b406970c4aa8653b71aaffa2ba476ee9d9
Reviewed-on: https://dart-review.googlesource.com/24921
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
We change the type of FileUriNode.fileUri from String to Uri, which in principle
doesn't change the binary format. However, we did notice that LibraryParts
weren't serialized as specified in binary.md, so we also fixed that.
Since fileUris are stored as strings in a separate table, Uri.parse is only called
once per unique URI.
Fasta only uses relativizeUri when printing diagnostics, and URIs stored in
expectation files (golden files) are relativized using String.replaceAll.
Change-Id: Ib2dc1b80c03a0cdaf84e48b8b3ba73b16bdf8a40
Reviewed-on: https://dart-review.googlesource.com/25421
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This CL deprecates the front-end API and moves it into src/api_prototype.
For now all usages have been updated to point to the new location,
but they should be updated to use custom-client invocations instead (e.g.
one specific way for DDC, another for dart2js etc.)
Bug:
Change-Id: I9b4f41f6ebf55d42510fd35240d942d1dc7292d6
Reviewed-on: https://dart-review.googlesource.com/24822
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This brings IKG recompilation time from 20-30 ms range to 5-10 ms range,
i.e. 3-4 times faster.
Of course performance of the system in general starts depending now
on how how many libraries we need to send to VM, and how fast the client
of IKG can serialize the returned libraries.
1. Leaf library.
Compilation: 10 ms
Returned libraries: 8
Serialization time: 1 ms.
2. A deep library.
Compilation: 10 ms
Returned libraries: 222
Serialization time: 60 ms.
R=paulberry@google.com, sigmund@google.com
Bug:
Change-Id: I5eab99c0bd7916d605696696d5e570c5fa6f1978
Reviewed-on: https://dart-review.googlesource.com/21900
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This version does not store any compiled kernels into ByteStore.
We might get back to it, if we have time, and if it can be done without
slowing down returning results.
Here are numbers for the flutter_gallery sample.
Minimal KG.
1. Initial start: 3600 ms.
2. Change a leaf library (logic.dart): 30-40 ms.
3. Change a method body in a deep library (widgets/text.dart): 600-800 ms.
This IKG.
1. Initial start: 4300 ms.
2. Change a leaf library (logic.dart): 30-40 ms.
3. Change a method body in a deep library (widgets/text.dart): 30-40 ms.
4. Change API of a deep library: 600-800 ms.
So, this new version is very fast when you change a method body.
This is the most often and useful case.
We might want to create a new benchmark for it.
R=paulberry@google.com, sigmund@google.com
Bug:
Change-Id: I134050c5bafec195d8a1eceb2ee9ea1468c819fc
Reviewed-on: https://dart-review.googlesource.com/21282
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@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>
For now only getKernel() uses the new compilation method.
There are several new failing tests because redirection factories
are not serialized/deserialized correctly yet (but I saw kernel
support comming for it), and outlines don't include private fields (
which we want to work around by storing just names).
R=paulberry@google.com, sigmund@google.com
Bug:
Change-Id: I0d964862066ac0ee9e7b5c7b1d3802171a874aef
Reviewed-on: https://dart-review.googlesource.com/19440
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The reason to have both is that IKG needs kernels for all libraries,
potentially not even deserialized from bytes, if we eventually get this
optimization.
OTOH, Analyzer always needs just one library, with enough outlines
to make sense of the dependencies. For now, getKernel() is implemented
using getKernelSequence(), this will change with switching to
outline based compilation.
R=paulberry@google.com, sigmund@google.com
Bug:
Change-Id: Iba02bc3a4cdb67a896c4faa2f809c7cb8069aa9e
Reviewed-on: https://dart-review.googlesource.com/18509
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This moves several classes used only for testing purposes
out of the analyzer/lib directory tree and
into front_end/test/fasta/testing where they are used.
Change-Id: I294b20710de4b16e27fbea5d13be316a6ecda112
Reviewed-on: https://dart-review.googlesource.com/18200
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
This should help make sure that the front end is inserting all of the
necessary implicit downcasts.
The type checker is run after comparing to golden files, and before
running the test in the VM. So if a test case fails to match its
golden file, the test's status will be "Fail" regardless of whether it
type checks. If the test case matches its golden file but fails to
type chek, the test's status will be "TypeCheckError". Rationale: the
type checker is still under development; if it has bugs leading to
false failures, we don't want that to get in the way of comparing
against golden files.
Change-Id: I6764aa5c7f2aab92a10edfa41afcdb056946530b
Reviewed-on: https://dart-review.googlesource.com/17522
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
So, it can be used standalone, without wrapping into
MemoryCachingByteStore, and IKG can check for it to protect keys.
Bug:
Change-Id: I50635c773b73ad7e57d0dfe1fd9e3c4574f1a1aa
Reviewed-on: https://dart-review.googlesource.com/17560
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Sigmund Cherem