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 .
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 .
Really, this works around them, but the workaround is all round better
code.
Remove the Dart implementations of min() and max() and just forward to
the JS ones. In DDC, all numbers are double, so the type checks to
handle them specifically aren't meaningful. Also, we don't need the
other special case checks in there to help dart2js optimize them.
R=vsm@google.com
Review URL: https://codereview.chromium.org/2386493003 .
- Get rid of JSMutableIndexable since it isn't useful.
- Make JSIndexable generic. (I think dart2js already did.)
- Add .length to NativeTypedArray since it no longer inherits it from
JavaScriptIndexingBehavior.
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/2378423003 .
Also travis support for testing FF. See:
https://travis-ci.org/dart-lang/sdk/builds/159331789
On FF 48, 1965 out of 1979 tests are passing. Run locally:
DDC_BROWSERS=Firefox npm test
On Safari 10 (tech preview), it fails immediately due to a static method named "caller". We disallow it as a field, but not a method right now. If I hack that out, 1972 out of 1979 tests appear to pass.
Run locally by installing tech preview and running:
DDC_BROWSERS=Safari SAFARI_BIN=/Applications/Safari\ Technology\ Preview.app/Contents/MacOS/Safari\ Technology\ Preview npm test
R=jmesserly@google.com, rnystrom@google.com
Review URL: https://codereview.chromium.org/2334763002 .
If a comparer isn't provided, it was silently assuming the element type
implements Comparable, even though that isn't required. Fixed to add a
manual cast at each comparison.
A stricter faster approach might be to check that the type argument
itself is a type that implements Comparable, but I don't know if that's
too pessimistic, or even possible to do.
R=vsm@google.com
Review URL: https://codereview.chromium.org/2311513002 .
Vijay Menon