Migrate block 162 to Dart 2.0.

tests/language_2/type_variable_bounds2_test.dart

Index: tests/language_2/type_variable_bounds2_test.dart
diff --git a/tests/language_2/type_variable_bounds2_test.dart b/tests/language_2/type_variable_bounds2_test.dart
new file mode 100644
index 0000000000000000000000000000000000000000..e396a666a39e63761186d93d5b0e8268726b04e4
--- /dev/null
+++ b/tests/language_2/type_variable_bounds2_test.dart
@@ -0,0 +1,63 @@
+// Copyright (c) 2012, 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.
+
+import "package:expect/expect.dart";
+
+// Test of parameterized types with invalid bounds.
+
+abstract class J<T> {}
+
+abstract class K<T> {}
+
+abstract class I<
+    T
+  extends num //# 00: continued
+  extends num //# 01: continued
+  extends num //# 02: continued
+  extends num //# 03: continued
+  extends num //# 04: continued
+  extends num //# 05: continued
+  extends num //# 06: continued
+    > {}
+
+class A<T> implements I<T>, J<T> {}

[eernst, 2017/09/04 17:04:59]

We have the following in the language specification section 19.8, Parameterized
types: 'Any use of a malbounded type gives rise to a static warning.'

Consequently, the declaration of class A should incur a static type warning in
Dart 1.x, and I would expected this to be a compile-time error in Dart 2 (as
usual for static type warnings in Dart 1.x).

Note that the commentary at the end of section 19.2 Dynamic Type System
explicitly indicates that a similar class A should give rise to a 'type warning'
indicating that 'T is not a subtype of num' (in reality that is: T may or may
not be a subtype of num, but we  can't promise that it is).

So we may never have expressed the test expectation explicitly that we get such
a static type warning, but I think we should now expect that this class
declaration is a compile-time error, with subtests 00-06.

As far as I can see, every test expectation in `main` below is concerned with
the dynamic behavior of Dart in a situation where a subtype relationship (for
assignments in checked mode, and for `is` expressions in all modes) between
`A<String>` and I/J/K is tested. 

This makes sense in Dart 1.x: We have an unusual situation because an
`A<String>` has a "built-in" malbounded type `I<String>` which will be "used" in
certain situations (such as checking whether the `A<String>` instance has type
`I`, which will go via `I<String>`).

But in Dart 2 we cannot create this situation: There will never be an instance
of `A<U>` for any `U` such that any subtype test will need to use a malbounded
type along the way.

Hence, I think we should derive a static-only test from this test, something
like the following:

```
abstract class J<T> {}

abstract class I<T extends num> {}

class A</*@compile-error=unspecified*/T> implements I<T>, J<T> {}

main() {
  // We are only interested in the instance creation, hence
  // the result is assigned to `dynamic`.
  dynamic a = /*@compile-error=unspecified*/ new A<String>();
}
```
We could choose different treatments in this situation: It could be a
compile-time error to create an instance of an erroneous class (maybe it hasn't
been entered into the namespace because it was faulty, or maybe it's marked as
faulty and all usages will be faulty as well). It could also be accepted
silently (in order to avoid that one fault gives rise to a large number of
derived error messages). Right now the test tool just checks for the _existence_
of `@compile-error` and hence it won't distinguish between the cases where we
get one or two errors.


I've been looking for ways to extract some dynamic behavior from this test which
is still relevant for Dart 2, but I think there is none. In that case we will
only have the new static test, and type_variable_bounds2_test disappears
entirely.

+
+main() {
+  // TODO(jcollins-g): Should this be a compile-time error as well?

[Bob Nystrom, 2017/08/30 20:02:44]

This looks OK to me.

+  dynamic a = new A<String>();

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

The static-only test was discussed in the comment on line 24.

The dynamic behavior which was tested by this test in Dart 1.x is more difficult
to preserve: It was concerned with the dynamic treatment of an instance of
`A<String>`, in particular during subtype tests; but we can't create any such
object in Dart 2, so there won't be any dynamic behaviors dealing with it.

When we cannot meaningfully preserve this line (but we could change it to
`dynamic a = null;`), the only meaningful thing to preserve in `main` is the
treatment of a variable of type `dynamic` when subjected to a type check against
I/J/K.

+
+  {
+    // Anything having to do with a here should point out that String does
+    // not extend num.

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

The static type of `a` is `dynamic`, so we shouldn't expect diagnostic messages
to mention `String` at all. The question is just whether `I`, `J`, and `K` can
be initialized with a value of type `dynamic`, and the answer would be 'yes'
(with --no-implicit-casts it would be 'no'; --no-implicit-dynamic does not
matter because `dynamic` is specified explicitly).

I expect that test to be covered elsewhere (but I would really like to know how
we make sure that everything we delete like this is actually covered).

+    I i = a; // //# 00: compile-time error
+    J j = a; // //# 01: compile-time error
+    K k = a; // //# 02: compile-time error

[Bob Nystrom, 2017/08/30 20:02:44]

I would expect to see a compile error at the declaration of A itself when I's T
has "extends num". In that case, it's not known at the declaration of A that A's
T will always implement num (since it has no constraint).

I'll start a thread with Leaf to see how this should behave.

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

Agreed.
This is probably concerned with the same issue that I mentioned above: We may or
may not make `new A<String>()` an error when class `A` itself has a compile-time
error.

However, we _can_ use J and K as type annotations, and if we have an
"instantiate-to-bound" mechanism in place then we can also use I. In that case
there is no way we could get a compile-time error in lines 33-35 (unless we
outlaw implicit downcasts, as mentioned).

I don't think we can adjust lines 33-35 to test anything useful, so we should
delete them (as mentioned, I don't think we can preserve _anything_ beyond that
which goes into the static only test).

+
+    // A<bool> is a subtype of I.
+    Expect.isTrue(a is I); // //# 03: compile-time error
+
+    // A<bool> is a subtype of J.
+    Expect.isTrue(a is J); // //# 04: compile-time error
+
+    // A<bool> is not a subtype of K.
+    Expect.isTrue(a is !K); // //# 05: compile-time error

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

I have no idea where `A<bool>` enters the situation (we have no such instance,
and I can't see why static analysis or ad-hoc human reasoning would expect one).

Again, it is not interesting to execute the checks in lines 37-44 (because we
can't get hold of an `A<String>`), and the static analysis is also not
interesting. Those lines can therefore be deleted as well.

+  }
+
+  a = new A<int>();

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

Now this is possible!

+
+  {
+    I i = a;
+    J j = a;
+    K k = a; // //# 06: compile-time error

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

But it should not be a compile-time error to initialize a `K` variable with a
`dynamic` expression (modulo --no-implicit-casts).

In any case, that kind of cast cannot be unique to this test, so we can also
delete these lines.

+
+    // A<int> is a subtype of I.
+    Expect.isTrue(a is I);
+
+    // A<int> is a subtype of J.
+    Expect.isTrue(a is J);
+
+    // A<int> is not a subtype of K.
+    Expect.isTrue(a is! K);

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

When we don't have a compile-time error, `A` is just a generic class and
`A<int>` is just a normal (well-bounded) instantiation of `A`, so tests on the
behavior of `is` would be covered elsewhere.

So we can delete these lines as well.

This means that there is nothing in the dynamic test which isn't already covered
by the static-only test. This means that we should only have the static-only
test.

I went back and adjusted the comments to make this point up front.

+  }
+}