Optimize dynamic call tracking using random sampling.
Apply source maps to improve dynamic call tracking accuracy.
Dynamic calls within the sdk are now attributed correctly.
Fix bug formatting modules where we were incorrectly flagging them as JS.
BUG=
R=jmesserly@google.com, vsm@google.com
Review-Url: https://codereview.chromium.org/2811343002 .
This doesn't fix the entire problem, there's still a Chrome issue that it's not clear we can work around, but it helps some. https://bugs.chromium.org/p/chromium/issues/detail?id=676388
There are three distinct issues here affecting Chrome sourcemap usage for DDC programs with single-line lambdas.
1 - We may introduce a synthetic "as SomeType" in a parameter. The synthetic token ends up with a large negative length, from its offset to the beginning of the file, which can confuse sourcemaps.
2 - We have no entry for the blank line following the lambda. The devtools asks for the mapping from (selectedLine, 0) to (selectedLine +1, 0) and if there's no mapping for either it refuses to set the breakpoint. So this artificially forces the mapping from the last character on the line to be to the beginning of the next line instead.
3 - With a lambda we introduce a constructed Return JS node and make a block. Those nodes weren't getting annotated, so they had no source information.
BUG=
R=jmesserly@google.com
Review-Url: https://codereview.chromium.org/2815443003 .
Before landing, two issues to resolve:
(1) We appear to allow sideways casts now without static error - e.g.,
List<Object> -> FutureOr<List<String>>
Is that intended? If so, it breaks an assumption that implicit casts
are from supertype to subtype.
(2) LUB and FutureOr
It appears that the LUB of, e.g., String and Future<String> is Object.
See fixes in tests to record casts back to FutureOr.
Fixes#29251R=leafp@google.com
Review-Url: https://codereview.chromium.org/2801683004 .
Re-enable formatter test that had been disabled when someone changed type
name display for Foo<dynamic> types.
Fix bug in how type names were displayed for JS interop types.
BUG=
R=vsm@google.com
Review-Url: https://codereview.chromium.org/2789663005 .
This is an alternative to the other CL. It just uses the result of
dart.mixin instead of declaring a new class. That preserves the assumption (at least at runtime) that the mixin class directly inherits from Object.
We were also not declaring interfaces for ClassTypeAliases.
R=jmesserly@google.com
Review-Url: https://codereview.chromium.org/2783443002 .
fixes#27625, Object constraints were not tracked in inference
fixes#27933, pin return type from downwards inference
We now prefer to pick the bound (lower or upper) that had some information on, and it also improves inference error messages somewhat (still a ways to go).
The way this works is we now have a type representing an unknown type: ?. We use ? when performing downward inference steps, instead of `dynamic`. This allows more accurate tracking of type constraints.
For example: given:
var x = await Future.wait([a, b]);
Future.wait<T>'s argument type is Iterable<Future<T>>. Since we didn't know T, we previously pushed down Iterable<Future<dynamic>>. The dynamic caused loss of information. Now we push down Iterable<Future<?>>, allowing us to infer the right type there.
R=leafp@google.com, vsm@google.com
Review-Url: https://codereview.chromium.org/2456803004 .
See internal bug 36371258.
We're hitting type errors of the form:
CastError: Casting value of type '_Future' to incompatible type 'FutureOr<int>'
I suspect these type errors were there but just ignored before - does this seem a reasonable extension to the whitelist?
R=jmesserly@google.com
Review-Url: https://codereview.chromium.org/2752203003 .
This gives a noticeable 5-10% boost to startup on large internal apps
in Chrome. We may want to consider for AMD at some point. It doesn't
apply to es6 or common as those are top-level (and either the browser
or linker would hopefully parse accordingly).
R=jmesserly@google.com
Review-Url: https://codereview.chromium.org/2753623002 .
This makes the source files a little easier to read anyway and the JSON
is not typically that nested so there should be a minimal statup performance hit.
Do not return the JSON as an escaped String to work around a strange v8 bug.
BUG=
R=vsm@google.com
Review-Url: https://codereview.chromium.org/2747733003 .
In DDC, if the receiver is typed and the target method simply forwards to a JS call, invoke that call directly instead of via a symbol.
This is a step toward #28307.
Paul: can you look the the analyzer / summary code change?
dart:html uses "native". other libraries (e.g., typed_data) use "external" for more or less the same thing. The analyzer element model doesn't provide a way to test for "native" methods, but it does for "external". I map native to external here. Not sure if it's better to treat them as separate (I believe native predated external). Longer term, it may make sense to try to remove "native" in favor of "external".
R=brianwilkerson@google.com, jacobr@google.com, jmesserly@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2748713002 .
Make DDC a better platform for debugging by ensuring that stack traces
generated by DDC even when using the raw dart:core StackTrace class
apply JS source maps and benefit from the polish provided by the
stack_trace package.
stack_trace_mapper.dart needs to be compiled to js and included on your
page to benefit from this functionality. Otherwise you will still see
regular JS stack traces as usual.
BUG=
R=vsm@google.com
Review-Url: https://codereview.chromium.org/2735303002 .
Our internal tooling is complaining about this when building / checking the ddc sdk. It appears to use the analyzer's summary builder tool which seems less forgiving about dangling references / missing files.
R=srawlins@google.com
Review-Url: https://codereview.chromium.org/2740573003 .
Vijay Menon