Just creating an Error object is sufficient on FF,
Chrome, Safari, and Edge. Note that captureStackTrace
was not supported by other browsers so those browsers
were going down the even slower path of throwing an
exception.
BUG=
R=vsm@google.com
Review-Url: https://codereview.chromium.org/2668503002 .
This implements FutureOr<T> in strong mode, otherwise it's ignored (treated as `dynamic`.
Also fixes strong mode's inference subtype function incorrectly treating `void` as a malformed type. This had the consequence of allowing `void` to be inferred as a type argument.
R=leafp@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2647833002 .
Improvement on #28286 - this is still not quite right as we'll throw a
TypeError instead of a NSM in certain cases depending on the order.
The spec will only throw a TypeError if NSM doesn't apply.
R=leafp@google.com
Review-Url: https://codereview.chromium.org/2636313002 .
EventStreamSubscription.listen does a cast which is only working in
DDC because we're ignoring the failure. This wraps the listener to
check the argument rather than casting the function. Also picks up a
few misc changes to the main SDK that hadn't been merged into DDC.
BUG=
R=jacobr@google.com
Review-Url: https://codereview.chromium.org/2609633002 .
When I'm looking at the dynamic call profiles of an internal app test,
I see a bunch coming from the SDK itself. In fact, the top five most
common dynamic call sites are in the SDK.
This fixes four of them. (The fifth is in runUnary() in Zone, and I
don't think can be made typed yet.)
R=vsm@google.com
Review URL: https://codereview.chromium.org/2542723003 .
Any reason not to do this? I generally find when framework code wraps these errors, it just complicates finding the original bug. Better to just trap.
Perhaps should just inline the call to debugger though. I put in dart.debugger with the thought of making it configurable.
R=jacobr@google.com, jmesserly@google.com
Review URL: https://codereview.chromium.org/2519873004 .
The bots need to run these before running the tests, so I'm porting them
to Dart so they'll run on Windows.
As a nice bonus, they're much faster now, I'm assuming because we use
one warmed up VM for all of the packages.
build_test_pkgs.sh on my machine went from ~12 seconds to ~4.
R=jmesserly@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/2498673003 .
References to loadLibrary on a library prefix are compiled to a
helper function that returns a Future that always completes
successfully.
The deferred libraries aren't actually deferred, but code that uses
loadLibrary() now doesn't barf.
BUG=#27343
R=vsm@google.com
Review URL: https://codereview.chromium.org/2477673006 .
Here's a setup to test build of various SDK packages with DDC and strong mode per commit on travis.
It's not an ideal setup:
- If deps / files change, this will need updating.
- It only breaks on error, not warning.
- It doesn't actually run any package tests.
I haven't gone through all packages either. Might be worth automating something like this.
See try-run here:
https://travis-ci.org/dart-lang/sdk/builds/172066040R=jmesserly@google.com
Review URL: https://codereview.chromium.org/2465923003 .
Conor Reisman