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 .
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 .
Vijay Menon