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>
This builds on the VM's support for constants, and brings dartdevk to
parity with dartdevc. Also, constants are computed with arithmetic
operations that match runtime behavior (JS numbers).
Constants are limited in some cases right now: when building outline
kernel files (via pkg/dev_compiler/tool/build_pkgs.dart), constant field
initializers are not preserved, and this fact is not recorded, making
these fields appear to be implicitly null. dartdevk will recognize this
and avoid inlining the constant in these cases.
Change-Id: I5e6d95ccc32799da3bec1667ed16078a1a87d0bd
Reviewed-on: https://dart-review.googlesource.com/53121
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@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>
We no longer eagerly enqueue defineProperty, toStringForNativeObject,
or hashCodeForNativeObject. We only enqueue convertDartClosureToJS
when needed.
For the following 'Hello World' program, code size dropped from 33175 to 10066:
```
import 'dart:html';
main() {
window.console.log('Hello World');
}
```
Change-Id: I47860b44b572f7a162fc95c9cccefdc9012810dd
Reviewed-on: https://dart-review.googlesource.com/54500
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Harry Terkelsen <het@google.com>
This is complicated by the fact that the normal factory method for creating
Invocation objects references the arguments descriptor to determine how many
type arguments are passed. This doesn't work for partially instantiated
closures, because the arguments descriptor will say "0" type arguments even when
there may be delayed type arguments attached to the closure from partial
instantiation. The arguments descriptor can't be modified, so we have a new
factory method which takes the number of delayed type arguments directly.
Change-Id: Ic9a35a482b3b7ef80564e674cc6207873e255111
Reviewed-on: https://dart-review.googlesource.com/54245
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Removing this directory as it is mostly unused.
Closure conversion still relies on VariableAccessor, so I moved it
there.
We should consider removing closure conversion. I don't believe we
actually use it.
Change-Id: I885620b310c4d1bf3a9b9b805188921bc242a993
Reviewed-on: https://dart-review.googlesource.com/54221
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
I want to merge the class hierarchy, for example, merge Accessor and
FastaAccessor into a class called named ExpressionGenerator.
I also plan to get rid of all the _FooAccessor classes by merging them
with their non-private subclass.
I also plan to rename all the Accessor classes to use the word
Generator instead of Accessor.
Change-Id: I271f56077d02f98cc5981760e370ff91c0864400
Reviewed-on: https://dart-review.googlesource.com/54201
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@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>
Second try. First try was reverted because a previously empty URL (the
default 'always there' one) is now a null url instead, which wasn't
handled properly in the frontend_server.
See 47e9039512 for original details.
This reverts commit 4c9b712052.
Change-Id: I717eb927cbe29b6388e72f7e270428d234d44e4d
Reviewed-on: https://dart-review.googlesource.com/53580
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Johnni Winther