Fix previously broken AssertAssignable bytecode failing to throw.
Do not assume interpreter is never called on generic closure.
Propagate error after failed getter invocation in GetFieldForDispatch runtime
call.
Change-Id: I548a49829cc29addbbd310f1dc19ce8073738015
Reviewed-on: https://dart-review.googlesource.com/67922
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
This CL fixes errors 'NoSuchMethodError: The getter 'dartAsyncMarker' was called on null.'
while generating bytecode for async closures.
Change-Id: I0e5726e4bf6a385772060b2ddba3cf762572538a
Reviewed-on: https://dart-review.googlesource.com/68003
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Values of static fields with trivial initializers are pre-initialized
at load time, so such static fields do not have implicit getters.
Bytecode generator is fixed to treat double literal initializers as trivial
and avoid calling getters for such fields.
Also, this CL disables bytecode generation for static fields with trivial
initializers as their bytecode is not used.
Change-Id: I44b9d26ab2007e33d0d5b9f716e30848f0c38e8a
Reviewed-on: https://dart-review.googlesource.com/68005
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This is needed to convince pub to let Fuchisa have
a Dart 2 compliant version of protobuf.
Change-Id: Ie9f8460d231579c07735355262f16fb1dad9fef9
Reviewed-on: https://dart-review.googlesource.com/68100
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Rationale:
Having a non-speculative implementation avoids deopting
under JIT and enables AOT. Done for X64 and now also ARM64.
https://github.com/dart-lang/sdk/issues/33967
Change-Id: I83302a5950aa2dc1a7220367755af748cfaa4393
Reviewed-on: https://dart-review.googlesource.com/67920
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
IIUC this rewriting was done to internally check front-end better, but
it get in the way of running analyzer, and these errors are not mandated
by the spec. So, I decided that I don't want doing rewriting in
Analyzer / CFE integration.
R=brianwilkerson@google.com, paulberry@google.com
Bug: https://github.com/dart-lang/sdk/issues/34042
Change-Id: I1bb41b271d8d84eace9bd13a269bcac157e9f89b
Reviewed-on: https://dart-review.googlesource.com/68006
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Before this CL, Judgments save Tokens in final fields.
This can take up quite a lot of space, and isn't actually (currently)
used for anything. Eventually it will be used in Analyzer.
This CL changes it so Judgments instead carry a `box` that is in
`non-analyzer-mode` just null, and in `analyzer mode` stores the Tokens
directly.
When running dart2js through the VM, this decreases the memory footprint
quite a lot, and seems to make the compile faster.
Details:
Removing the Tokens decrease the memory usage by almost 50MB
("Maximum resident set size" (as reported by /usr/bin/time -v)),
and more than 66MB from the old space in the kernel isolate after
ended compilation and changed the compile time of dart2js by
-7.71201% +/- 6.22211% (presumably because of less pressure on the GC).
For more details see the review page comments.
Change-Id: I7a31927f104e111c1b16be10b35f4164959a2130
Reviewed-on: https://dart-review.googlesource.com/67720
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
When compiling dart2js this cuts down the old generation
(after forced GC, VM kernel isolate) from ~230 MB to ~217 MB.
Change-Id: Id06a2666d1849e49acc18c4142ab346f581e5b23
Reviewed-on: https://dart-review.googlesource.com/67520
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
On 64-bit platforms we use a field in the header to cache results of
Object.get:_identityHashCode. The very same field is also used to
cache String.get:hashCode result. Which means that their implementations
must be the same.
Fixes https://github.com/flutter/flutter/issues/20122
Change-Id: I98eef9eddf833c0d7c4c6f452728fe48e232efdc
Reviewed-on: https://dart-review.googlesource.com/68042
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
When logical expression is evaluated in the control context (e.g. if (cond) { ... })
avoid materializing a boolean value and then dispatching on it. Instead connect
true and false successors directly to then and else branches.
This CL also improves IL generated when logical expression is evaluated for value
(e.g. x = (cond)): we similarly avoid materializing intermediate results and also
avoid comparisons that are not needed, e.g. when evaluating x = A && B we construct
graph x = A ? B : false, instead of x = A ? (B == true ? true : false) : false style
of graph.
Change-Id: I204d414cc6751949641b6c46423a6319f6e2d89b
Reviewed-on: https://dart-review.googlesource.com/67562
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Closes#33878
Change-Id: Id4687f59c31adb1338643f86909bc5b6b7afb88a
Reviewed-on: https://dart-review.googlesource.com/68040
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Before this CL the test fails because the stacktrace was not as expected
when running in sync async mode.
This CL changes the test so async methods are not executed synchronously
by adding an "await null;" as the first thing in those methods.
An alternative fix would have been to pass --no-sync-async.
Bug: #29158
Change-Id: Idd9bd159610405bbdd479d50d823953a9ad1abde
Reviewed-on: https://dart-review.googlesource.com/63742
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This changes how we step out of async* functions slightly to match how
Dart1 behaves.
Bug: #29158
Change-Id: I8ee2df5eee8167fd1907a6e9f30c9dc7ab6939b1
Reviewed-on: https://dart-review.googlesource.com/63625
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This changes how we step into async* functions slightly to match how
Dart1 behaves.
Bug: #29158
Change-Id: I4969ca48f798bd51f9d2d5bc26dd224fa7eff627
Reviewed-on: https://dart-review.googlesource.com/63624
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The idea is to provide a flag that can be stable through time, even as we add
and remove certain optimizations.
Fixes https://github.com/dart-lang/sdk/issues/34044
Change-Id: Ic07bf2148308b7530f2a69d7ebecb8fd7bf2d4cc
Reviewed-on: https://dart-review.googlesource.com/67921
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
InstantiateType bytecode can only be used on a non-instantiated type.
Type literals for generic function types without free type variables
(e.g. '<X>(dynamic, X) => X') are now generated using PushConstant.
Change-Id: I5c26751de4b47a0b98b075d8df85060bf78157d8
Reviewed-on: https://dart-review.googlesource.com/67980
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Before this change, ConstantClosureFunction was holding a clone of original
FunctionNode without body (in order to omit body during serialization).
It is not correct: original FunctionNode, which is used to generate
closure's bytecode may reference original type parameters and those
type parameters could be used in types written into constant pool.
A cloned FunctionNode has its own cloned copies of type parameters
and it does not provide a sufficient serialization/deserialization context.
This resulted in 'Type parameter T is not indexed' errors.
This CL fixes this problem by removing cloning. In order to avoid
serialization of the FunctionNode body, body is temporarily dropped
while writing ConstantClosureFunction.
Also, this CL fixes type finalization of signature types of closure functions
read from bytecode. If signature type is not finalized, VM crashes with
'../../runtime/vm/object.cc: 18580: error: expected: IsFinalized()'.
Change-Id: Id88e99609ee387352fc011a8c297024d05e24037
Reviewed-on: https://dart-review.googlesource.com/67960
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
After this change, ICData map is always unpacked in CompileParsedFunctionHelper::Compile
regardless of the optimizing mode. The unpacked ICData array is passed
both to FlowGraphBuilder and to FlowGraphCompiler.
FlowGraphCompiler::FlowGraphCompiler no longer unpacks ICData array, and
the duplicated code for unpacking of ICData map is replaced with debug asserts.
Change-Id: Ib6864acdb6bcd02fe7acd1cb5bcf70d6c69808af
Reviewed-on: https://dart-review.googlesource.com/67505
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The named configurations aren't used yet, and checking that they agree
with the existing flags will now just print error messages, not make
the builder fail.
Change-Id: Ia0778855d3c45da8e3314f9cff0967ec1fc7893b
Reviewed-on: https://dart-review.googlesource.com/67807
Reviewed-by: William Hesse <whesse@google.com>
Negative tests are inflexible: they are expected to fail so they pass
if they fail and the fail if they pass. This requires strange status
file entries when they don't fail and aren't expected to (e.g., the
front-end's parser or the spec parser does not necessarily fail (i.e.,
pass)).
Change-Id: I1397b24fea63431472aa182f178bd14bc2afe8fe
Reviewed-on: https://dart-review.googlesource.com/67802
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
