Add tests for generic methods in strong mode

tests/language_strong/generic_methods_overloading_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_boundaries_test;

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

Might as well use a library name that matches the file name, like the other
tests, and the file name might as well avoid the word 'overloading' (which is
usually associated with 'static', and Dart does not have static overloading in
the usual sense --- multiple members in the same scope with the same name, but
different types).

Maybe 'generic_methods_overriding_test.dart'?

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

Yep, the library name is wrong here. Thanks for the 'overloading -> overriding'
suggestion. Done.

+
+import "package:expect/expect.dart";
+
+class A {}
+
+class B extends A {}
+
+class C {
+  String fun<T extends B>(T x) => "C";
+}
+
+class D extends C {
+  @override
+  String fun<T extends A>(T x) {

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

I believe we have maintained that generic function subtyping does not allow for
differences in the bounds on type arguments. I would be surprised if this
shouldn't apply to overriding as well.

In that case this is a compile time error, the bound on T must be B.

[Leaf, 2017/03/09 19:17:27]

I had forgotten we'd agreed to this, but it seems like we did.

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

Then I change it to multi-test to check for compile-time error in case of '<T
extends A>' and for normal behavior in case of '<T extends B>'.

Thanks! Done.

+    if (x is B) {
+      return super.fun<B>(x as B);

[Leaf, 2017/03/09 05:51:19]

Cast is unnecessary in strong mode.

[asgerf, 2017/03/09 10:36:51]

It seems to me that 'B' is not more specific than 'T'.

How does type promotion work here?

[Leaf, 2017/03/09 19:17:26]

Currently in strong mode, if we have a type variable `T` with bound `A`, and a
variable `x : T extends A`, then `x is B` where `B <: A`, promotes `x` to `x : T
extends B`.

It's a little weird, since it associates bounds with uses of type variables
instead of just with the declaration, but the analyzer does that already, and it
makes some examples like this work out better.

[asgerf, 2017/03/10 09:20:24]

Ah, I remember seeing that when adding strong mode to dartk, but I thought it
was just a quirk in the analyzer.

I have some more questions about this, but I'll start an email thread instead of
discussing it here.

I still think it makes sense to keep the downcast to make the test independent
of type promotion.

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

I think I reorganize this, so that we have both versions (with and without the
downcast) in the multi-test.

Thanks! Done.

+    }
+    return "D";
+  }
+}
+
+class E extends C {
+  @override
+  String fun<T>(B x) => "E";

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

This would again be a compile time error, there must be a bound on T and it must
be B.

(But using `B` as the parameter type is no problem: we always know that T <: B,
so this is just contravariance).

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

Marked it as a compile-time error in multi-test. Also implemented an 'ok'
version 'String fun<T extends B>(B b)'.

Thanks! Done.

+}
+
+main() {
+  A a = new A();
+  B b = new B();
+  C c = new C();
+  D d = new D();
+  E e = new E();
+
+  Expect.isTrue(c.fun<B>(b) == "C");
+  Expect.isTrue(d.fun<A>(b) == "C");
+  Expect.isTrue(d.fun<A>(a) == "D");
+  Expect.isTrue(e.fun<B>(b) == "E");
+}