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 .
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 .
Bob Nystrom