Technically, ResolveVariableReferencesTask only requires the
information guaranteed by RESOLVED_UNIT1 to do its job. However,
later tasks, such as ResolveFunctionBodiesInUnitTask, require the
information computed by ResolveUnitTypeNamesTask (which produces
RESOLVED_UNIT3). Normally this is not a problem, because
ResolveFunctionBodiesInUnitTask depends (via a rather complex
dependency chain) upon LIBRARY_ELEMENT5, which in turn depends on
ResolveLibraryTypeNamesTask, which depends on RESOLVED_UNIT3. So
ResolvuUnitTypeNamesTask winds up getting run.
However, it's possible that due to analysis cache pressure, the
resolved unit will get thrown away, while the library element is
preserved. If this happens, then when the resolved unit is being
recomputed, it won't be necessary to run ResolveLibraryTypeNamesTask
in order to recompute LIBRARY_ELEMENT5 (becase LIBRARY_ELEMENT5 is
still cached). As a result, nothing is left that depends on
RESOLVED_UNIT3, so there is nothing to force ResolveUnitTypeNamesTask
to run.
The outward manifestation of this problem is that when trying to
resolve a library, a TypeName will be found whose ".type" property is
unexpectedly null, causing an exception in the ResolverVisitor.
The easy fix is to make ResolveVariableReferencesTask depend on
RESOLVED_UNIT3, so there is a complete dependency chain through all
the RESOLVED_UNIT[N] results that doesn't rely on any
LIBRARY_ELEMENT[N] intermediates.
This is not an ideal fix because it forces us to compute
RESOLVED_UNITs 2 and 3 even if they might not be needed. Fortunately,
computing these RESOLVED_UNITs should be fast, so I don't expect a
significant performance penalty.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1386363002 .
Note that we are not pulling in the latest version of analyzer_cli,
since there is additional work to do in analyzer_cli before the pull
request can be merged into master (in particular, lint support needs to
be fixed--see https://github.com/dart-lang/analyzer_cli/pull/67).
Instead we pull in the commit from the pull request itself, which
enables the new task model but makes no other changes.
R=pquitslund@google.com
Review URL: https://codereview.chromium.org/1386233002 .
This change add the ability to restart the vm through the service
protocol. All isolates are killed, and then the main isolate is
restarted cooperatively by the embedder.
This change also fixes the message handler to prevent it from
accidentally ignoring vm shutdown messages.
Previously, we would stop handling messages whenever we hit an error
(such as a compile error or an unhandled exception). This would leave
shutdown requests sitting the oob queue, neglected.
We now process *all* oob requests, up to the first shutdown request.
When we hit a shutdown request, we clear the oob queue and process no
more messages.
To make all of this work, we had to change the return value of
HandleMessage from bool to a new enum type, allowing the message
handler to distinguish *normal* error cases from the more rarified
shutdown and restart cases.
R=johnmccutchan@google.com, zra@google.com
Review URL: https://codereview.chromium.org/1371193005 .
Some of these values could be literal values and end up in the VM isolate heap. Later when these values are referenced in a constant list we try to ensure that all the objects in the list are canonical and try to canonicalize them. When these Mint objects are encountered they do not have the canonical bit set and canonicalizing them won't work as the VM heap is read only now. In these cases we clone the object into the isolate and then canonicalize it.
BUG=
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1391433002 .
The optimizer runs constant propagation once before inserting boxing- and unboxing
conversions. Therefore, operations that take unboxed input operands may still have
mismatched representations.
This has to be considered so that no invalid 'unknown' constants appear during propagation.
The invariant during constant propagation is that if all inputs of an operation
are known (constant or non-constant), the output must be known (constant or
non-constant. It must not become unknown in these cases.
i.e. the input of a MintToDouble/Int32ToDouble/SmiToDouble could be a double constant at
this stage. This can occur as a result of polymorphic inlining of arithmetic operations on
constants, where some variants are unreachable.
For now, the solution is to mark the operation as non-constant.
(the inserted conversion would always deoptimize - making the operation unreachable)
BUG=
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1380203004 .
