This reverts commit 3a23e604e2.
The problem was unrelated to the CL; it appears to be a dart:async break of package:async.
In the meantime we have turned on --unsafe-force-compile to DDC's shapshotting step
Review-Url: https://codereview.chromium.org/2869733006 .
Side effect of this:
Fix bug where helpers in js_mirrors were specifying that name had to have type String when it could really also be a JS Symbol as well.
Fix bug where top level JS interop members using the external keyword but no @JS keyword were not implemented.
Update js_typed_interop_test.dart so it can work in DDC.
Add regression test for jsify call with native function type arguments.
BUG=
R=vsm@google.com
Review-Url: https://codereview.chromium.org/2827333003 .
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 .
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 .
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 .
There's some changes in strong mode errors we may want to follow up on.
Unforks the following: async, collection, convert, core, developer, internal, io, isolate, math, mirrors.
Does not unfork: html, indexed_db, js, js_util, svg, typed_data, web_audio, web_gl, web_sql.
R=vsm@google.com
Review-Url: https://codereview.chromium.org/2698353003 .
Vijay Menon