This finishes going through the dev_compiler HTML tests and switches
out unittest for minitest wherever possible.
In the process, it gets another 10 tests strong mode clean, and gets
several more passing, and more not skipped. With this CL, we're running
another 50 more HTML tests (though some are expected to fail, mostly
because of #27578).
R=jacobr@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/2419863002 .
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 .
- increase timeout so we load all tests
- mark a few more failures
- skip unittest tests until we re-triage them
Review URL: https://codereview.chromium.org/2279053002 .
This should catch tests that suddenly start failing (or passing).
This is an admittedly contrived approach to track compilation failures in
the same runtime logic: the statically failing tests are now compiled
to a trivial output that throws a particular exception. Ideally, we
wouldn't run these, but it's beneficial to keep status in the same
place.
On my laptop, this only adds ~8s to presubmit (which takes ~2:30 min).
Ideas on alternative approaches welcome. :-)
R=jmesserly@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/2079373002 .
Added 'tag' type StrongModeError, implemented by all errors that are
specific to strong mode semantics.
Failed casts throw CastError(Implementation) or StrongModeCastError.
Failed type assertions and reified coercions throw TypeError or
StrongModeTypeError.
Triaged some tests. Some pass due to now throwing a TypeError, many
pass for unknown reasons.
R=leafp@google.com
Review URL: https://codereview.chromium.org/2026133002 .
we still have an init method, for better or worse, to break out of ES6 restrictions
The idea here is default Dart constructor (really an initialization method) is always called `new` instead of the class name. We already do this for unnamed factory.
R=leafp@google.com
Review URL: https://codereview.chromium.org/1965213003 .
We initially hard coded a few of these. That worked until native_typed_data and html were added. Those two libraries have a lot of native types.
This also fixes TypeRep to extend dart:core Object, and fixes the dart:_runtime so we can write Dart classes. Cleans up a few of the JS builtins as well.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1962823002 .
I started trying to get the convert tests all cleaned up and passing
but realized I was going down a rathole. So, for now, all of the slow
or failing ones are just skipped.
BUG=
R=sra@google.com
Review URL: https://codereview.chromium.org/1965563003 .
Vijay Menon