Rationale:
Found by DartFuzz. One of the trickier bugs I had to debug.
While building the flow graph from kernel, the finalizer
builder expects the program context to be in the same state
as when the finalizer was seen first, not the context seen
by the breaking/continuing statement. This was done partially,
but only partially. Finding loop context or breakable
and switchable blocks was missing. Something only
a fuzzer can find :-)
https://github.com/dart-lang/sdk/issues/36076
Change-Id: Ie63912c5fad4d3c15f6559b60cc102b237949957
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95720
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Rationale:
The new modulo optimization assert fails when doing
the power-of-two-of-abs test on minint64 (since abs
of minint64 is minint64). Note that we could actually
optimize this case by masking with maxint64 pattern
but since it bails for non-smi masks right now, this
fix does the same.
https://github.com/dart-lang/sdk/issues/35815
Change-Id: Ic592dad89ff6ffcd84dba9e17d4bccd79dc01f18
Reviewed-on: https://dart-review.googlesource.com/c/91704
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
MethodInvocation nodes which have field or getter as interface target
actually correspond to 2 calls: 1) getter; 2) implicit call() on the result
of the getter.
While this was correctly modeled in summaries in TFA, it is not correct
to attribute such MethodInvocation nodes with results of the inference,
as results correspond to an each distinct call. To fix this, Call
statements in summaries are created without attaching them to a
corresponding kernel AST node.
Change-Id: I3ea28ed85550192f8b592a926cac0eae23810811
Reviewed-on: https://dart-review.googlesource.com/c/88424
Commit-Queue: Martin Kustermann <kustermann@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
For calls via getters and fields front-end generates MethodInvocation
node with interface target pointing to a getter/field.
Such target doesn't fully represent what is being called - it should
be implicitly chained by call(), so it is incorrect to use such
interface target for type propagation.
Change-Id: I76198b443474fdcb383671fbc9946b4938a4e1df
Reviewed-on: https://dart-review.googlesource.com/c/88260
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
This makes us report the following error
* in JIT:
Unhandled exception:
'test.dart': error: Type arguments must be instantiated in partial instantiation.
#0 main (...)
...
* in AOT:
test.dart:7:28: Error: The type '#lib1::C::T' is not a constant, only instantiated types are ...
const C({this.callback = _defaultCallback});
^
test.dart:7:17: Context: While analyzing:
const C({this.callback = _defaultCallback});
^
test.dart:5:37: Error: The type '#lib1::C::T' is not a constant, only instantiated types are ...
void foo([dynamic Function(T) f = _defaultCallback]) {}
^
test.dart:5:33: Context: While analyzing:
void foo([dynamic Function(T) f = _defaultCallback]) {}
^
test.dart:11:38: Error: The type '#lib1::bar::T' is not a constant, only instantiated types are ...
void bar<T>([dynamic Function(T) f = _defaultCallback]) {}
^
test.dart:11:34: Context: While analyzing:
void bar<T>([dynamic Function(T) f = _defaultCallback]) {}
Issue https://github.com/dart-lang/sdk/issues/32912
Change-Id: I05c7019119a50a9cc38939d9cb41aeaa06c853bc
Reviewed-on: https://dart-review.googlesource.com/c/81278
Auto-Submit: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Rationale:
Rather than relying on a separate loop detector, rely
on the new loop framework, which avoids code duplication
and ensures any improvement in loop detection/handling
will benefit this phase too. Note, most of the time, the
same loops are discovered with a few exceptions (which
is okay, since this is "just" heuristic usage). This CL
also simplifies loop detection a bit.
https://github.com/dart-lang/sdk/issues/34473
Change-Id: I1a1b19b99a698c74822473d2a1fe370287c1ade4
Reviewed-on: https://dart-review.googlesource.com/c/80523
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Similar to how we treat catch entry instructions, this cl adds new
function and osr entry instructions. The [FunctionEntry] and
[OsrEntry] - just like [CatchBlockEntry] - have now their own initial
definitions. The [GraphEntry] has only initial definitions for
constants.
Explicit phis are inserted for all parameter / special parameter
instructions if necessary.
Future work is:
a) Minimize parallel moves due to the phis on parameters
b) Cleanup frame setup: Move it entirely into FunctionEntry/CatchEntry
(instead of the split version we have now)
Fixes https://github.com/dart-lang/sdk/issues/34435
Fixes https://github.com/dart-lang/sdk/issues/34287
Change-Id: Iefa0280a709716f748d6fb0523b8d0f4d8de1fec
Reviewed-on: https://dart-review.googlesource.com/c/74782
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The added test in this CL causes code to be optimized with _Smi's and
eliminated field guards. Field guards were eliminated due to usage of Smi ops,
which get removed due to the WidenSmiToInt32 optimization.
A use of the code with _Mint's will then trigger a test failure.
The WidenSmiToInt32 optimization has been disabled for the time being.
Change-Id: I6f7dd003a875b0abd708b3b948cda44378c42198
Reviewed-on: https://dart-review.googlesource.com/c/79540
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The canonicalization of symbols needs to take library privacy into
account. Since the Symbol class itself only has a [_name] field but does
not reference in which library the symbol came from, the [_name] must be
mangled.
Mangling is done by backends and so we make a new [SymbolConstant] which
the backends can desugar by doing appropriate mangling and construction
of a [Symbol] instance.
Fixes https://github.com/dart-lang/sdk/issues/34396
Change-Id: I2e13288483c35f875d39eefdb73677b2cc03527a
Reviewed-on: https://dart-review.googlesource.com/74360
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The canonicalization of symbols needs to take library privacy into
account. Since the Symbol class itself only has a [_name] field but does
not reference in which library the symbol came from, the [_name] must be
mangled.
Mangling is done by backends and so we make a new [SymbolConstant] which
the backends can desugar by doing appropriate mangling and construction
of a [Symbol] instance.
Fixes https://github.com/dart-lang/sdk/issues/34396
Change-Id: I5ddb5331ce79a0b942807929d4b8f1050a9899e7
Reviewed-on: https://dart-review.googlesource.com/73883
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Rationale:
This improves JIT and AOT performance of unary minus
and also improves constant folding and range analysis
on negative constant (viz. x / -3 is often x / - (3)).
The SHIFT operator needed some special treatment, since
we have to avoid converting a NON-speculative shifts
back into a deopt.
https://github.com/dart-lang/sdk/issues/34072
Change-Id: I230c9cfda98297f683bbba53688e57c2cc659360
Reviewed-on: https://dart-review.googlesource.com/68434
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
Rationale:
While writing tests for the ongoing native 64-bit
MOD/TRUNCDIV support in AOT, I noticed a floating-point
crash in our VM due to evaluating the constant mod case:
Expect.equals(0, mod(minInt64, -1));
Expect.equals(minInt64, truncdiv(minInt64, -1));
This fixes the constant evaluation part.
https://github.com/dart-lang/sdk/issues/33967
Change-Id: I9a4e6b3cd4d0d0dee39c690d2b981b5812501be4
Reviewed-on: https://dart-review.googlesource.com/67281
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
Add simplified unittest replacement to package:expect.
(It is used in multi-tests, so it needs to be in an accessible place without using ".." in its path).
Change-Id: I60aa212ed67ffbdda17ca18fce1cdff16237f4fe
Reviewed-on: https://dart-review.googlesource.com/65700
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
This fixes an issue when a program got loaded via dill, a function
with a try-catch got optimized and the exception/stacktrace variables
got captured.
Change-Id: Icb8ea5f3557080f8274f7db2af09e33154820e5b
Reviewed-on: https://dart-review.googlesource.com/55721
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Aart Bik