Library reference is added for private names in order to resolve them correctly.
Invocation kind byte supersedes VM-specific name mangling and makes
ConstantICData more uniform with ConstantStaticICData.
Change-Id: I66542356209d98b3d0cf0e6b8eb19bda052c6b7e
Reviewed-on: https://dart-review.googlesource.com/57485
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
When the constant transformation is enabled on annotations, we need to fix handling
of @ExternalName annotations in the kernel_loader to ensure that we are setting
is_external = false on native methods.
The original revision is in patchset 1.
# Test Plan
The only regression was on benchmarks, Golem results are pending.
Change-Id: Ib80bb9f532299056e770a3b378cc5ad9ee451f57
Reviewed-on: https://dart-review.googlesource.com/56960
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Kernel mixin transformation desugars mixin applications into normal
classes. Mixed-in type is pulled into interfaces list.
However, dart:mirrors needs to know the original mixed-in type of
a mixin application.
This change solves this problem by propagating a 'isTransformedMixinApplication'
attribute of a class through kernel AST, kernel binary and VM objects
into dart:mirrors implementation.
Fixes: https://github.com/dart-lang/sdk/issues/33240
Change-Id: I98ca69294e1ad445402a5ca91d90c30447aabcb2
Reviewed-on: https://dart-review.googlesource.com/56721
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This reverts commit 3e50ea32b5.
Reason for revert: Severe performance regressions on many aot-v2 benchmarks.
Original change's description:
> [vm] Support definition of entry-points via @pragma('vm.extern') annotations.
>
> The `@pragma` annotations are evaluated by the constants transformation and
> visible to TFA and the precompiler, which match on the "options" field of the
> annotation to determine whether to mark the class/procedure as a root.
>
> This required enabling the transformation of annotation constants by default.
>
> # Test Plan
>
> The "vmservice_io.main" entry-point is removed from `main.cc` and annotated with
> `@pragma`. All precompiler tests will crash if "vmservice_io.main" is not
> available at runtime.
>
> Debug/release precompiler bots are visible in "cl-linux" button.
>
> Change-Id: I03c5d6ba7918672ed9905fcaee8dabe675a93a5d
> Reviewed-on: https://dart-review.googlesource.com/56660
> Commit-Queue: Samir Jindel <sjindel@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,alexmarkov@google.com,sjindel@google.com
Change-Id: I779c17d003659129a4b3fcf284423104948f60e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/56820
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Samir Jindel <sjindel@google.com>
The `@pragma` annotations are evaluated by the constants transformation and
visible to TFA and the precompiler, which match on the "options" field of the
annotation to determine whether to mark the class/procedure as a root.
This required enabling the transformation of annotation constants by default.
# Test Plan
The "vmservice_io.main" entry-point is removed from `main.cc` and annotated with
`@pragma`. All precompiler tests will crash if "vmservice_io.main" is not
available at runtime.
Debug/release precompiler bots are visible in "cl-linux" button.
Change-Id: I03c5d6ba7918672ed9905fcaee8dabe675a93a5d
Reviewed-on: https://dart-review.googlesource.com/56660
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This change adds tracking of number of invocations with the same
selector but different arguments. If this number reaches certain limit,
all subsequent invocations with such selector are approximated.
On Flutter gallery, 1 selector is approximated:
dart.core::Object::==
On Analyzer, 2 selectors are approximated:
analyzer.dart.ast.ast::AstNode::visitChildren
dart.core::List::[]=
Flutter gallery Total(CodeSize): +11 K.
Fixes https://github.com/dart-lang/sdk/issues/33199
Change-Id: I3598555194262a4f08fe1bc207d10880a25eb432
Reviewed-on: https://dart-review.googlesource.com/56420
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The option is not used by any client at this time and removing it simplifies the
next stack of changes I'll be making on how we compose file systems.
I also don't believe we will necessarily add this back as an option, but instead
it might be that clients requriing hermeticity will provide a custom file system
that helps with that.
Change-Id: I401efb042920d234382b6c041b13d40ffae5c908
Reviewed-on: https://dart-review.googlesource.com/56462
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This CL updates the frontend_server to allow specifying what dill
file to initialize from.
Normally, it tries to initialize from the same dill file as is the
output. This is fine in many cases (e.g. flutter run always says it
should output to build/app.dill): The first time it compiles
everything, subsequent times (across restarts) it only recompiles
what's needed.
When running tests, however, the output is in a temporary directory,
so it doesn't work across restarts. The startup time for tests is
always rather high, because it always has to recompile everything.
This CL updates the frontend_server to allow specifying what dill
file to initialize from. Flutter can thus save the compiled test
file in a centralized location (e.g. build/test.dill) and load from
that across restarts.
Plumbing this into flutter yields the following result, when running
a single test (the one automatically created when creating a new
flutter project):
Before: ~5.5 seconds
Now, first run: ~5.5 second (unchanged)
Now, subsequent runs: ~3.4 seconds
Approximate breakdown:
Startup cost (e.g. if there's no test directory): ~ 800 ms
Starting up the actual frontend server: ~150 ms
Reading source from old dill, loading all relevant files
and invalidating source: ~ 300 ms
Compiling everything (or, rather, nothing as it's all
from the dill at this point): ~ 650 ms
Serializing: ~ 250 ms
Copying files: ~ 50 ms
Running the actual test: ~1100 ms
Total: ~3300 ms
`time flutter test --local-engine=host_debug --preview-dart-2`
says ~3.4 seconds...
To compare, --no-preview-dart-2 takes ~2.2 seconds,
so dart2 still has a (significantly) higher startup cost.
Moves the needle on https://github.com/flutter/flutter/issues/15767.
Change-Id: I36a2d05bc76e0193d369df42eb3b9f08416dd78f
Reviewed-on: https://dart-review.googlesource.com/51820
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL adds experimental option --drop-ast to the gen_kernel tool in
order to remove AST bodies of members with bytecode.
Change-Id: Ib5f02eb189ec1ccd9fa77159c175fc3774998ce5
Reviewed-on: https://dart-review.googlesource.com/55262
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@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 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>
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>
This reverts commit 039e8a1755.
Reason for revert:
Blocks the roll into Flutter.
See https://github.com/dart-lang/sdk/issues/33095
Original change's description:
> [vm/kernel] Enable kernel2kernel "constants" transformation in AOT mode (after running TFA)
>
> This CL also uses the newer `onProblem` error reporting mechanism, which supports contexts.
>
> The errors by the constant evaluator are formatted e.g. like this:
>
> .../language_2/compile_time_constant_o_test_01.dart:14:8: Error: Duplicate keys are not allowed in constant maps (found duplicate key "StringConstant(foo)").
> "foo": 499
> ^
> .../language_2/compile_time_constant_o_test_01.dart:32:24: Context: While analyzing:
> Expect.identical(m1, m3);
>
> Change-Id: I463416e14686e218b0f08903bd6aa0bca7392260
> Reviewed-on: https://dart-review.googlesource.com/53021
> Commit-Queue: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Aske Simon Christensen <askesc@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
TBR=vegorov@google.com,kustermann@google.com,alexmarkov@google.com,askesc@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I1af0200dcb0aef03c7bd9ba3b5aead1565f05708
Reviewed-on: https://dart-review.googlesource.com/54720
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Todd Volkert <tvolkert@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
This change adds experimental option '--import-dill' to front-end server
to specify existing kernel file to import when compiling a new one.
Newly generated kernel file will depend on the imported one and will
omit libraries available in the imported dill file, as well as platform
libraries.
Caveat: the new option is not compatible with '--incremental'.
Change-Id: Id637908afdb12f1829e5f634251fa9ad82676baf
Reviewed-on: https://dart-review.googlesource.com/54309
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This CL also uses the newer `onProblem` error reporting mechanism, which supports contexts.
The errors by the constant evaluator are formatted e.g. like this:
.../language_2/compile_time_constant_o_test_01.dart:14:8: Error: Duplicate keys are not allowed in constant maps (found duplicate key "StringConstant(foo)").
"foo": 499
^
.../language_2/compile_time_constant_o_test_01.dart:32:24: Context: While analyzing:
Expect.identical(m1, m3);
Change-Id: I463416e14686e218b0f08903bd6aa0bca7392260
Reviewed-on: https://dart-review.googlesource.com/53021
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Instead of simply throwing an exception when a compile-time error was
discovered during constant evaluation, we report the error and continue
transforming.
This also collects a context, which can be used by error reporters to
show users in which context an error occured.
The reason for using an interface for reporting errors is to be able to
report reasonable nice error messages, keep the transformation inside
package:kernel and allow users of the transformation to possibly report
nicer error message, e.g. by adding quotes of source positions (which
will come in another CL). This makes it slightly verbose.
Change-Id: I965cafc690dddb525b20368d03bb978e18a6ee58
Reviewed-on: https://dart-review.googlesource.com/52447
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
While generating bytecode, avoid flattening of type arguments used for
instance allocations (and thus avoid creating new types when substituting
type parameters). This is a workaround to limitation of kernel metadata
which is unable to serialize references to nodes (such as DartType)
not reachable from root Component.
Change-Id: I52c5e21873d0159d389895dc570a9e7283f2a6ff
Reviewed-on: https://dart-review.googlesource.com/52643
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
To enable bytecode generation, toggle kEnableKernelBytecode flag at
the beginning of pkg/vm/lib/bytecode/gen_bytecode.dart.
This will also enable generation of bytecode in platform dill files.
Also, bytecode generation can be enabled using --gen-bytecode option of
pkg/vm/tool/gen_kernel.
In kernel binaries, the generated bytecode and constant pool are
placed into 'vm.bytecode' metadata attached to members.
pkg/vm/tool/dump_kernel tool can be used to disassemble
bytecode and print constant pool.
Differences between generated bytecode and original DBC are
described in pkg/vm/lib/bytecode/dbc.dart.
Format of constant pool is described in
pkg/vm/lib/bytecode/constant_pool.dart.
Currently, only a small subset of Dart language is supported.
Bytecode generator will not emit vm.bytecode metadata for a
member if its body has an unsupported operation.
Change-Id: I27d9a361dc779ea115e5676508ee757c1754e05d
Reviewed-on: https://dart-review.googlesource.com/49600
Reviewed-by: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Original revision is in Patchset 1.
Run against failing kernel-precomp tests in "cl-linux-try".
Change-Id: I997de294150ef7dd0874eeccb8b6187ae64ea813
Reviewed-on: https://dart-review.googlesource.com/51220
Reviewed-by: Erik Corry <erikcorry@google.com>
Ryan Macnak