Tests for `void`.

tests/language/generic_function_typedef_test.dart

Index: tests/language/generic_function_typedef_test.dart
diff --git a/tests/language/generic_function_typedef_test.dart b/tests/language/generic_function_typedef_test.dart
new file mode 100644
index 0000000000000000000000000000000000000000..eb8fb183d0d5cc8f5793cb8c6ad5149daea9cdf9
--- /dev/null
+++ b/tests/language/generic_function_typedef_test.dart
@@ -0,0 +1,24 @@
+// 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.
+// Dart test for a function type test that cannot be eliminated at compile time.
+
+import "package:expect/expect.dart";
+
+class A {

[Lasse Reichstein Nielsen, 2017/02/21 09:37:03]

Isn't used.

+}
+
+typedef F<T> = Function<S>(List<S> list, Function<A>(A), T);

[Lasse Reichstein Nielsen, 2017/02/21 09:37:03]

This defines a generic function that requires a generic function as second
argument.

+
+foo(List<dynamic> x, bar(String y), int z) {}
+foo2(List<int> x, bar(String y), int z) {}

[Lasse Reichstein Nielsen, 2017/02/21 09:37:03]

Neither of these functions are generic or take a generic function as second
argument, so they can't satisfy F<T> for any T (except when we ignore the
generic function type and treat it as Function(dynamic)).

If you are testing Dart 1 semantics, document that, so nobody thinks this should
work in strong mode.

[eernst, 2017/02/21 13:39:11]

I believe we haven't yet written any CLs for extending the spec to include the
`Function` based function type syntax in Dart 1 (I haven't done that, and I
couldn't find a CL doing that), so we would need to decide on the missing
pieces. For instance, it seems useful to erase generic function types like
`Function<A>(A)` to `Function(dynamic)` and then just go from there, so that
would most likely be part of such a specification.

So do we just go ahead here and assume some semantics, and then write a spec for
it later? We could still adjust the test if we end up wishing to have a slightly
different semantics.

+
+main() {
+  Expect.isTrue(foo is F);
+  Expect.isTrue(foo is F<int>);
+  Expect.isFalse(foo is F<bool>);
+
+  Expect.isTrue(foo2 is F);
+  Expect.isTrue(foo2 is F<int>);
+  Expect.isFalse(foo2 is F<bool>);
+}