Migrate test block 10 to Dart 2.0.

Migrate test block 10 to Dart 2.0.

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

Committed: https://github.com/dart-lang/sdk/commit/e6b3fb5b054442c0cfc625f3a43589f133597a7f

[jcollins, 2017-08-08 15:41:15]

Description was changed from

==========
Migrate test block 10 to Dart 2.0.

BUG=
==========

to

==========
Migrate test block 10 to Dart 2.0.

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=
==========

[jcollins, 2017-08-08 15:41:16]

jcollins@google.com changed reviewers:
+ bkonyi@google.com

[bkonyi, 2017-08-08 18:03:13]

https://codereview.chromium.org/2997533002/diff/20001/tests/corelib_2/int_par...
File tests/corelib_2/int_parse_radix_test.dart (right):

https://codereview.chromium.org/2997533002/diff/20001/tests/corelib_2/int_par...
tests/corelib_2/int_parse_radix_test.dart:117: Expect.throws(() =>
int.parse(source, radix: radix, onError: (s) => 0), //# badTypes: ok
Any reason for these annotations? If it does actually throw in strong mode, we
shouldn't need them.

https://codereview.chromium.org/2997533002/diff/20001/tests/corelib_2/iterabl...
File tests/corelib_2/iterable_fold_test.dart (right):

https://codereview.chromium.org/2997533002/diff/20001/tests/corelib_2/iterabl...
tests/corelib_2/iterable_fold_test.dart:179: testModification([3, 2, 1], add4,
(x) => x.reversed); //# 02: ok
Why all the 'ok's? Does something complain otherwise?

[jcollins, 2017-08-08 20:01:58]

https://codereview.chromium.org/2997533002/diff/20001/tests/corelib_2/int_par...
File tests/corelib_2/int_parse_radix_test.dart (right):

https://codereview.chromium.org/2997533002/diff/20001/tests/corelib_2/int_par...
tests/corelib_2/int_parse_radix_test.dart:117: Expect.throws(() =>
int.parse(source, radix: radix, onError: (s) => 0), //# badTypes: ok
On 2017/08/08 18:03:13, bkonyi wrote:
> Any reason for these annotations? If it does actually throw in strong mode, we
> shouldn't need them.

It throws something, but (I think) not the right exception.  This extracts the
failing lines into a multitest so that only the failing cases have to be marked
in the status file.

https://codereview.chromium.org/2997533002/diff/20001/tests/corelib_2/iterabl...
File tests/corelib_2/iterable_fold_test.dart (right):

https://codereview.chromium.org/2997533002/diff/20001/tests/corelib_2/iterabl...
tests/corelib_2/iterable_fold_test.dart:179: testModification([3, 2, 1], add4,
(x) => x.reversed); //# 02: ok
On 2017/08/08 18:03:13, bkonyi wrote:
> Why all the 'ok's? Does something complain otherwise?

I have to mark all lines that use add4 to extract add4 into its own multitest. 
Some compiler/runtime combinations don't work with this function.  This is what
I spent most of my time head scratching on in this block.

[bkonyi, 2017-08-08 20:06:55]

LGTM!

https://codereview.chromium.org/2997533002/diff/20001/tests/corelib_2/iterabl...
File tests/corelib_2/iterable_fold_test.dart (right):

https://codereview.chromium.org/2997533002/diff/20001/tests/corelib_2/iterabl...
tests/corelib_2/iterable_fold_test.dart:179: testModification([3, 2, 1], add4,
(x) => x.reversed); //# 02: ok
On 2017/08/08 at 20:01:58, jcollins wrote:
> On 2017/08/08 18:03:13, bkonyi wrote:
> > Why all the 'ok's? Does something complain otherwise?
> 
> I have to mark all lines that use add4 to extract add4 into its own multitest.
 Some compiler/runtime combinations don't work with this function.  This is what
I spent most of my time head scratching on in this block.

Ahhhh, okay, this is just so these parts have names that you can reference in
the status files? That makes sense!

[jcollins, 2017-08-09 15:47:55]

Description was changed from

==========
Migrate test block 10 to Dart 2.0.

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=
==========

to

==========
Migrate test block 10 to Dart 2.0.

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

Committed:
https://github.com/dart-lang/sdk/commit/e6b3fb5b054442c0cfc625f3a43589f133597a7f
==========

[jcollins, 2017-08-09 15:47:56]

Committed patchset #4 (id:60001) manually as
e6b3fb5b054442c0cfc625f3a43589f133597a7f.