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 .
My initial goal was just to move some of the HTML tests off unittest,
but that ended up slurping in some other changes as well. I haven't
finished going through all of the tests, but this puts the
infrastructure in place and fixes a batch of them. I'll do more next.
Changes:
- Add a "minitest" package. This shims just enough of the unittest/test
API to make it easy to swap it out for unittest without having to
rework the entire test.
- Go through the HTML tests from A-J and change them to use minitest
when possible. The ones that aren't possible use asynchrony.
Minitest doesn't support async tests (yet, maybe).
- Triage those tests and enable ones that are passing. Mark them failing
if failing. Filed a couple of tracking bugs for the common issues,
but for other cases, I just left a comment.
- In the process of this, I went ahead and make some of the affected
tests strong mode clean if they weren't already and it was easy.
- Synchronize changes between dev_compiler's fork of expect and
pkg/expect. We'll want to unfork those at some point. D-:
This gets dev_compiler from 1985 tests to 2042.
R=jacobr@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/2413073002 .
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 .
This reverts commit 4cf8eebec783fbc3ac8e027bf5a64b5bf2178ad3.
apparently we use it for code coverage. go figure.
Review URL: https://codereview.chromium.org/2261183004 .
Brian Wilkerson