Migrate block 162 to Dart 2.0.

tests/language_2/type_variable_bounds4_test.dart

Index: tests/language_2/type_variable_bounds4_test.dart
diff --git a/tests/language_2/type_variable_bounds4_test.dart b/tests/language_2/type_variable_bounds4_test.dart
new file mode 100644
index 0000000000000000000000000000000000000000..9e149b0817ff9df8c317a9a040efb3e6a9ffed98
--- /dev/null
+++ b/tests/language_2/type_variable_bounds4_test.dart
@@ -0,0 +1,53 @@
+// Copyright (c) 2013, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+// Test instantiation of object with malbounded types.
+
+class A<
+    T
+          extends num //# 01: compile-time error

[eernst, 2017/09/04 17:05:01]

It seems wrong to mark this point as a compile-time error, but I can see that it
is the most concise way to get two relevant variants: One where class `B` is a
compile-time error, and one where it is correct.

However, this would presumably mean that we never test each case: If we run the
subtest `none` then class B and all instance creations are OK, but if we run
subtypest `01` then B is a compile-time error, and we will probably get a
successful test run even if we get a compile time error just for line 12, but
not for line 21 (malbounded), line 24 (creates an instance of a faulty class),
line 27 (creates an instance of a class which is faulty because its superclass
is faulty, and we also don't have a guarantee that `C<T>` itself is
well-bounded), etc.

In general, as long as _any_ non-empty subset of the expected compile-time
errors arise, I think we'll declare victory and ignore that other errors may be
missing.

We might create an issue or add a `TODO` comment in order to remember that this
test is so easy to cheat.

For now, I'll just see if we can make it work reasonable well in spite of that.

+    > {}
+
+class B<T> implements A<T> {}
+
+class C<
+    T
+          extends num //# 01: continued
+    > implements B<T> {}
+
+class Class<T> {
+  newA() {
+    new A<T>(); //# 01: continued

[eernst, 2017/09/04 17:05:00]

During subtest none this is fine, so why omit this line outside subtest 01?

+  }
+  newB() {
+    new B<T>(); //# 01: continued

[eernst, 2017/09/04 17:05:01]

Like line 21.

+  }
+  newC() {
+    new C<T>(); //# 01: continued

[eernst, 2017/09/04 17:05:01]

Like line 21.

+  }
+}
+
+void test(f()) {
+  var v = f();
+}
+
+void main() {
+  test(() => new A<int>());
+  test(() => new B<int>());

[eernst, 2017/09/04 17:05:01]

In subtest 01, class B has a compile-time error. As mentioned earlier, it is not
obvious whether it should be a compile-time error to create an instance of such
a class.

+  test(() => new C<int>());

[eernst, 2017/09/04 17:05:00]

Same issue: In subtest 01, class C implements a class which has a compile-time
error. Should it be a compile-time error to create an instance of such a class?

+
+  test(() => new A<String>()); //# 01: continued
+  test(() => new B<String>()); //# 01: continued
+  test(() => new C<String>()); //# 01: continued

[eernst, 2017/09/04 17:05:00]

In subtest none, all instance creations in lines 40-42 are OK, statically and
dynamically. Why should these lines then be deleted from that test run?

+
+  dynamic c = new Class<int>();
+  test(() => c.newA());
+  test(() => c.newB());
+  test(() => c.newC());
+
+  c = new Class<String>();
+  test(() => c.newA()); //# 01: continued
+  test(() => c.newB()); //# 01: continued
+  test(() => c.newC()); //# 01: continued

[eernst, 2017/09/04 17:05:01]

During subtest 01 we are expecting a compile-time error, but these lines do not
have any compile-time errors (neither in subtest none nor in subtest 01), so
they might as well have been unmarked (delete '//# 01..').

+}