Special bits in this block:
int_parse_radix_test: Converted to a check only on TypeError (since this is raised at runtime based on user data)
iterable_element_at_test.dart: Split into multitest with compile errors.
iterable_fold_test.dart: add4 and a couple of other cases here cause problems for some compilers, split out into multitests and annotated in
status file.
BUG=
R=bkonyi@google.com
Review-Url: https://codereview.chromium.org/2997533002 .
There are far too many files here to review everyone carefully.
Spot checking most of the diffs look good as test code is generally written
with less care than application code so lots of ugly formatting get through.
If people notice files where the automated formatting bothers them feel free
to comment indicating file names and I'll move spaces within comments to make
the formatting cleaner and use comments to force block formatting as I have
done for other case where formatting looked bad.
BUG=
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2771453003 .
in checked mode.
It also checks at the end in all cases.
Iteration only goes from 0 to the original length of the list.
This ensures that iterating a list while adding to it (like by x.addAll(x))
is caught instead of growing until out-of-memory.
For well-behaved programs this makes no difference since length and original
length stay the same.
Also, it means that calling moveNext again later, after increasing the length,
will not make iteration continue. After returning false, iteration is always
done.
However, it means that reducing the length causes an out-of-range read before
reaching the end, and before a concurrent modification error can happen.
R=sra@google.com
Review URL: https://codereview.chromium.org//1024843002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45198 260f80e4-7a28-3924-810f-c04153c831b5
Bob Nystrom