Add tests for generic methods in strong mode

tests/language_strong/generic_methods_boundaries_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;
+
+import "package:expect/expect.dart";
+
+class A {
+  int answer() => 42;
+}
+
+class B {
+  int answer() => 42;
+}
+
+class C {
+  int fun<T extends A>(T t) => t.answer();

[karlklose, 2017/03/09 09:16:59]

Remove answer and replace it with some integer.

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

Done.

+}
+
+main() {

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

I don't know what the conventions are for these tests, but I find it super
useful when reading tests if they include a short comment describing what they
are testing, e.g.

/* Test that a dynamic call to a generic function checks the type argument
against its bound */

[karlklose, 2017/03/09 09:16:59]

Agreed, please add a short comment in the beginning of the file and/or
individual lines.

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

Yes, that's a good idea. I've added comments that describe the purpose of each
test.

+  dynamic obj = new C();
+  Expect.throws(() => obj.fun<B>(new B()), (e) => e is TypeError);

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

We give type argument B which is a violation of the bound, and since malbounded
instance creation (`new SomeClass<WrongTypeArguments>()`) is a compile-time
error, I would expect malbounded method calls to be a compile-time error if
detectable, and dynamic cases (like this one) to be run-time errors (though
https://github.com/dart-archive/dev_compiler/blob/master/doc/STATIC_SAFETY.md
doesn't make this explicit).

We should never reach the body of `fun`, so it does not matter that the B
actually has an `answer` and that the invocation in `fun` statically implies
that we are calling `A.answer` or an overriding implementation thereof.

I think it would be useful to adjust the test to focus on the malbounded
invocation and then cover both the static and the dynamic case. And I agree that
it would be better if the test stated this purpose explicitly.

Then there could be other test statements focusing on passing a `B` to an
invocation of `fun<A>` (checking that the given type argument is used when
checking actual arguments, statically and dynamically), and possible more.

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

Yes, I agree. I removed the 'answer' methods, because they don't add anything to
the test itself and is merely an artifact of the test writing history.
Done. And agree about the comments.
Yes, agree on the usefulness of such tests. There are some examples of such
checks in other files.

+}