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 .
Update all tests
Support //# multitests for better dartfmt compatibility and fewer multitest false positives
All files under tests were manually updated with
find . -iregex '.*\.dart$' -print0 | xargs -0 perl -pi -e 's/(\S\s+)\/\/\/ /$1\/\/# /'
For now both old and new styles are allowed to accommodate CO19 tests.
R=efortuna@google.com
BUG=
Review-Url: https://codereview.chromium.org/2765693002 .
Review-Url: https://codereview.chromium.org/2765893003 .
Support //# multitests for better dartfmt compatibility and fewer multitest false positives
All files under tests were manually updated with
find . -iregex '.*\.dart$' -print0 | xargs -0 perl -pi -e 's/(\S\s+)\/\/\/ /$1\/\/# /'
For now both old and new styles are allowed to accommodate CO19 tests.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2765693002 .
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 .
Bazel build rules now place the sdk summary in a different directory
than the summary root directory. Fix the ddc compiler running in the
browser to match.
BUG=
R=vsm@google.com
Review-Url: https://codereview.chromium.org/2753723002 .
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 .
Vijay Menon