Add tests for generic methods in strong mode

tests/language_strong/generic_methods_closure_test.dart

+// Copyright (c) 2017, 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.
+
+library generic_methods_closure_test;
+
+import "package:expect/expect.dart";
+
+class A {}
+
+void bubbleSort<T extends Comparable<T>>(List<T> list) {

[karlklose, 2017/03/09 09:17:00]

Could you make this test a bit simpler? I don't think we actually need to do a
sort here (and below).

[Dmitry Stefantsov, 2017/03/10 13:21:52]

Yep, makes sense. Originally I was thinking about how some situations may happen
in real life, and the simplest case I could think of was sorting.

But I guess it's better to reduce these examples to something more abstract, so
that the checks are more evident for future readers.

+  var swap = <S extends Comparable<S>>(List<S> list, int i, int j) {
+    S s = list[i];
+    list[i] = list[j];
+    list[j] = s;
+
+    Expect.isTrue(list[i] is S);
+
+    A a = new A(); // A does not extend Comparable<A>, so A != S

[floitsch, 2017/03/09 11:27:17]

Finish with "."

[Dmitry Stefantsov, 2017/03/10 13:21:53]

Done.

+    Expect.isTrue(a is! S); // fails if S is substituted with dynamic

[karlklose, 2017/03/09 09:17:00]

Please remove references to substitution with `dynamic` where it is no longer
relevant (for strong mode) (also below).

[floitsch, 2017/03/09 11:27:17]

Start comment with uppercase. Finish it with ".".

[eernst, 2017/03/09 14:55:02]

I'm not sure about the purpose of this check: It could be a trap which forces
Dart 1 (non-strong mode) executions to fail, but I don't see why we would have a
strong mode test which is (among other things) designed specifically to fail
when run in non-strong mode. It's usually an organizational issue that we keep
this file in a certain (language_strong) directory, and it doesn't matter
whether any of those tests are guaranteed to fail in Dart 1, they just need to
test strong mode behavior correctly. We would have a separate (and possibly
quite different) test for Dart 1.

If this is intended to confirm that the class A does not satisfy `A extends
Comparable<A>` then A needs to be given as a type argument where the check would
be performed statically (for instance creation and statically known generic
function calls) or dynamically (only for dynamic function invocations passing
actual type arguments). In this position it will just test that A is not a
subtype of the particular S which was passed in the given invocation, i.e., it
would still fail even in the case where `A extends Comparable<A>`. So the test
does not make much sense in strong mode.

I'd recommend that lines 19-20 are removed.

[Dmitry Stefantsov, 2017/03/10 13:21:52]

Done.

[Dmitry Stefantsov, 2017/03/10 13:21:52]

Done.

[Dmitry Stefantsov, 2017/03/10 13:21:53]

Yes, that's Dart 1 specific, so I think I should remove these lines.

+  };
+
+  for (int n = list.length; n > 1; n--) {
+    for (int i = 1; i < n; i++) {
+      if (list[i - 1].compareTo(list[i]) > 0) {
+        swap<T>(list, i - 1, i);
+      }
+    }
+  }
+}
+
+main() {
+  List<int> list = <int>[5, 4, 3, 2, 1];
+  bubbleSort<num>(list);
+
+  Expect.isTrue(list[0] == 1);

[floitsch, 2017/03/09 11:27:17]

Expect.listEquals([1, 2, 3, 4, 5], list);

[Dmitry Stefantsov, 2017/03/10 13:21:53]

Thanks! I should have done that. Anyway, after the simplification suggested by
Karl, these lines are gone.

+  Expect.isTrue(list[1] == 2);
+  Expect.isTrue(list[2] == 3);
+  Expect.isTrue(list[3] == 4);
+  Expect.isTrue(list[4] == 5);
+}