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 .
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 .
Peter von der Ahé