Eliminate uses of the comment syntax in lib/async. This is mostly
done simply by turning explicit (but commented) casts into implicit
casts to avoid regressing dart2js performance.
Bug:
Change-Id: I286c7bffbf609b5e2fa24b9d48b90876c2c45a9b
Reviewed-on: https://dart-review.googlesource.com/21566
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
* kernel-service.dart is moved to pkg/vm/bin and renamed to
kernel_service.dart
* LICENSE, pubspec.yaml and analysis_options.yaml added to pkg/vm.
* Kernel isolate name is corrected to be independent of URI passed
in --dfe VM option.
Change-Id: I5b7b860297314e240e557af80913e7ac3e6324ad
Reviewed-on: https://dart-review.googlesource.com/21260
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Previously, a ShadowSyntheticExpression was its own kind of Expression
unrelated to any of the Expression types defined in the kernel. It
responded to visit requests by forwarding the visit request to the
desugared expression. This had the advantage that for serialization
purposes, ShadowSyntheticExpressions would automatically disappear.
But it had the disadvantage that if a ShadowSyntheticExpression ever
needed to be replaced with another node (e.g. because an implicit
downcast was needed), the _ChildReplacer would get confused by the
visitor forwarding and fail to replace the node properly.
This CL fixes the problem by changing ShadowSyntheticExpression to a
Let node of the form `let _ = null in desugaredExpression`. Since
this is a genuine kernel expression, it no longer needs special
visiting semantics, and node replacement works properly.
In most circumstances, we replace the ShadowSyntheticExpression with
its desugared equivalent during type inference, so the final
serialized kernel representation is unchanged. However, in a few rare
circumstances involving error recovery, a ShadowSyntheticExpression
remains in the tree. Semantically this shouldn't be a problem, since
the behavior of `let _ = null in x` is the same as the behavior of
`x`. Nonetheless, I hope to get rid of these rare circumstances in
follow up CLs.
Change-Id: Iacf8c0028c424ac9ef98ef8302680e289bf7a017
Reviewed-on: https://dart-review.googlesource.com/21571
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Casts for function types got moved off of the generic path, and hence
are missing the memo cache. Added a second function type cast cache.
Fixes#31392
Bug:
Change-Id: Ie1b87adf630f5059b57d01956778f5adde0533fc
Reviewed-on: https://dart-review.googlesource.com/21525
Reviewed-by: Vijay Menon <vsm@google.com>
For ObjectFormatter right now we just show the class name. Some objects,
e.g. Int64, have descriptive toString() operations that are much more
informative than their internal structure.
This changes the default header to be
Instance of 'Thing'
rather than just
Thing
which is a little worse, but it's much better for these kinds of classes.
For Int64 we will now show
12345 (Int64)
We also clip the toString() if it's too long.
Bug:
Change-Id: Iae6a8e66fdbe1d9f5c157ecdb983a833e26d00f4
Reviewed-on: https://dart-review.googlesource.com/21522
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Alan Knight <alanknight@google.com>
The new front end doesn't support generic comment syntax yet, so it's
getting the wrong type for LineSplitter in strong mode. Since we no
longer to preserve legacy mode semantics for LineSplitter, we can just
use the correct strong mode types without generic comment syntax.
Change-Id: If2dcb2fb3fae9eb49685838e4e84958e545650c7
Reviewed-on: https://dart-review.googlesource.com/21286
Reviewed-by: Florian Loitsch <floitsch@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Kernel represents break and continue in Dart uniformly as break. When
compiling to JavaScript we would like to use continue where possible and
avoid labeling statements that do not need to be labeled.
The basic idea is: at compile time maintain a list of Kernel targets
(LabeledStatements) that can be compiled to JS break without a label at a
given point in the program, and a list of Kernel targets that can be
compiled to JS continue without a label, and a map from Kernel targets to
the 'effective' target that will be labeled if necessary when compiled to
JS, and a mapping from effective targets to their label names if they must
be labeled.
Change-Id: Ie660cf3dd68399ebff128116fe38c250cb6b7f35
Reviewed-on: https://dart-review.googlesource.com/21120
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
This lets us benchmark separately:
- IKG implementations (the default based on kernel-driver or the minimal implementation)
- strong and non-strong mode
This also adds commands to try_benchmarks that highlight how these options will be used.
Change-Id: I5ce2c4563b7e79c33d78df7fd87be76f5d47e3f4
Reviewed-on: https://dart-review.googlesource.com/21320
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Sigmund Cherem