For now we don't have state transitioning and perform all work in a
single loop. Later we will break the loop and wait for the "has work"
stream after each operation. BTW, I don't like this stream approach,
but I don't know yet anything better.
The promise to produce the resolved CompilationUnit for every added
file does not scale well for initial results. I want to weaken it to the
promise that only priority and getResult() results get full content/unit.
For all other files we need only errors, which can be cached.
For index we need to use another apporach. I have a plan :-)
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2446803003 .
This strengthens
t1 = s == null || t == null;
if (t1) return;
known-here: t != null
There are not many hits since the 'interesting' tests are usually
earlier in the short-circuit expression.
R=sigmund@google.com
Review URL: https://codereview.chromium.org/2438543004 .
Add `rethrow` as one of the statements that are allowed to end a switch case
without a warning.
Change wording to not claim that `throw` is a statement.
Also allow wrapping case statements in a block statement without causing
more warnings. Currently, a `case 4: { break; }` is required to warn because
the last statement is a block statement, not a break statement.
Fixes issue #27650
BUG= http://dartbug.com/27650R=eernst@google.com, floitsch@google.com, rnystrom@google.com
Review URL: https://codereview.chromium.org/2447613003 .
Start by removing all get:runtimeType overrides in the patch files to have a single point computing the runtime type - Object.get:runtimeType. Handle string, double and integer types inside both intrinsic and runtime call to unify their handling and guarantee that code works even with intrinsifier disabled.
With overrides removed we can easily check that get:runtimeType is unique function name within the application that is being precompiled and use that to convert InstanceCall(get:runtimeType, ...) into StaticCall even nothing is known about the receiver.
This enables us to check if both left side and right side of comparison are StaticCall(Object.get:runtimeType, ...) when specializing InstanceCall(==, x, y). If they are we convert InstanceCall(==, StaticCall(get:runtimeType, a), StaticCall(get:runtimeType, b)) into StaticCall(Object._hasSameRuntimeType, a, b). A canonicalization rule will later delete unused get:runtimeType invocations.
Object._hasSameRuntimeType is implemented in C++ and intrinsified. It operates without creating new runtime types (except for Closures - where it does for simplicity). Cases of different class ids (i.e. a.[cid] != b.[cid]) and non-parameterized types are handled completely in the intrinsic. The rest is handled in the runtime code.
Microbenchmarking results:
Same parameterized classes: 15x improvement
Different parameterized classes: 300x improvement
Different/same non-parameterized classes: 2x improvement
BUG=
R=fschneider@google.com, regis@google.com
Review URL: https://codereview.chromium.org/2379733002 .
I considered removing it altogether, but reading unlinked bundles costs
something. So, we might consider caching this graph information.
OTOH, I agree that we might want to delay adding caching until we solve
the extra invalidation problem in _verifyUnlinkedSignatureOfChangedFiles.
TBR
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2447903002 .
GN is unhappy when a rule that consumes a file generated by
another rule doesn't depend directly on that rule.
This change also quiets output from invoking Dart to follow the
rule of GN builds that a successful build generates no output.
Review URL: https://codereview.chromium.org/2446473002 .
This CL makes the following improvements:
- When visiting an executable element, local variables and labels are
rebuilt rather than matching them up to the old element model. This
ensures that if the element model was resynthesized from an API
summary (which doesn't contain local variables or labels), these
elements are not lost.
- When matching up existing elements, if the elements did not
previously contain offsets, offsets are recorded. If they did
previously contain offsets, the offsets are compared to verify that
they match. This ensures that if the element model was
resynthesized from an API summary (which doesn't contain offsets),
the offsets will be correct.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/2435313002 .
