Tests for `void`.

tests/language/void_type4_test.dart

Index: tests/language/void_type4_test.dart
diff --git a/tests/language/void_type4_test.dart b/tests/language/void_type4_test.dart
new file mode 100644
index 0000000000000000000000000000000000000000..f0e6e68f53efa250b4a71373e8b22be3bbeb3e11
--- /dev/null
+++ b/tests/language/void_type4_test.dart
@@ -0,0 +1,125 @@
+// 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.
+
+// Dart test for type checks involving the void type.

[Leaf, 2017/02/23 21:30:52]

Are these strong mode, Dart 1.0, or both?

[eernst, 2017/07/10 16:05:34]

In Dart 1.x it is a static warning if m2 overrides m1 and the type of m2 isn't a
subtype of the type of m1. So we won't get an error there. But we should get a
static warning for the cases where a non-void return type is overridden by a
`void` return type (lines 26, 32, 38).

For strong mode I would expect `void` to be the same type as `Object` so no
issues arise due to subtyping in these cases. With voidness preservation checks
in place we should get a voidness preservation violation when a `void` return
type overrides a non-void return type.

We might introduce voidness preservation rules in several steps: Top-level
occurrences of `void` could be handled in an early step (e.g., overriding
`Object` as a return type by `void`), and nested occurrences could be handled
later (e.g., overriding `A<Object>` as a return type by `A<void>`). Similarly,
overriding relations could be handled earlier than data flow relations
(assignments, parameter passing).

So we could end up treating the return type override `Object` --> `void` as an
error in strong mode "soon".

But I certainly expected these tests to be for Dart 1.x semantics, because
they're located in tests/language.

+
+import 'package:expect/expect.dart';
+
+use<T>(T x) {}
+
+class A<T> {
+  T x;
+  Object y;

[Leaf, 2017/02/23 21:30:52]

Is it worth also have a dynamic version to make it clear that dynamic is treated
the same way as Object in all of these cases?

+  int z;
+
+  T foo() => null;
+  void bar() {}
+  void gee(T x) {}
+
+  f(A<Object> a) {}
+  g(A<void> a) {}
+  h(A<T> a) {}
+}
+
+class B implements A<Object> {
+  void   /// 00: error

[eernst, 2017/07/10 16:05:34]

This would be a static warning for Dart 1.x.

+  /*     /// 00: continued
+  var
+  */     /// 00: continued
+  x;
+
+  void   /// 00b: error

[eernst, 2017/07/10 16:05:34]

This would be a static warning for Dart 1.x.

+  /*     /// 00b: continued
+  var
+  */     /// 00b: continued
+  y;
+
+  void   /// 00c: error

[eernst, 2017/07/10 16:05:34]

This would be a static warning for Dart 1.x.

+  /*     /// 00c: continued
+  int
+  */     /// 00c: continued
+  z;
+
+  // Overriding an Object function with a void function is an error.
+  void  /// 01: error

[eernst, 2017/07/10 16:05:34]

This would be a static warning for Dart 1.x.

+  foo() => null;
+
+  int bar() => 499;
+  void gee(void x) {}
+  f(A<void> a) {}
+  g(A<void> a) {}
+  h(A<void> a) {}

[eernst, 2017/07/10 16:05:34]

(Just noting that these overriding declarations are OK because `void` as a
parameter type is considered to be `Object` for subtyping, and we have no
voidness preservation in place at this point; and because `A<void>` counts as
`A<Object>` for overriding.)

+}
+
+class C implements A<void> {
+  void x;
+  Object y;
+  int z;
+
+  void foo() {}
+  void bar() {}
+  void gee(void x) {
+    use(x);  /// 03: error
+  }
+
+  f(C c) {}
+  g(C c) {}
+  h(C c) {}
+}
+
+class D implements A<void> {
+  Object x;  /// 04: ok?   should be ok, but the setter goes from void to Object.

[Leaf, 2017/02/23 21:30:53]

I think not ok, at least not as we've formulated this.  I still feel like we're
in a bit of a state of confusion as to whether we want void to be equivalent to
Object and dynamic + some lints, or void to be a supertype of Object and
dynamic.  But current thinking seems to be in favor of the supertype treatment,
and I think it's just weird to special case out things like this one.

[eernst, 2017/07/11 08:45:43]

The informal spec of generalized void is built on the following foundation:
`void` is the same type as `Object`, except (1) expressions of type void cannot
occur in certain locations, (2: in the future) voidness preservation, and (3)
function types with `void` as the return type preserve their special placement
in the subtype lattice.

For Dart 2 we will drop (3), which is the only case where `void` is considered
to be a proper supertype of `Object`. Actually, I'd prefer to say that the
special subtype rule for `void Function(...)` is just an explicitly specified
exception; it is not helpful to actually make `void` a proper supertype of
`Object`, because that in turn will require many new exceptions to "undo" that
placement of `void` (such that `void` and `Object` are considered to be the same
type everywhere else).

+  Object y;
+  int z;
+
+  Object foo() => null;
+  void bar() {}
+  void gee(
+    Object  /// 05: error

[eernst, 2017/07/11 08:45:43]

We will only get an error here if we introduce a notion of voidness preservation
for overriding. (In that case the supertype `gee` receives an argument of type
`void` which implies that "the argument is unused", but D.gee grabs the right to
use that argument anyway).

So this is not an error by the current informal spec, but we could add some
simple voidness preservation rules for overriding and make it an error.

+    x) {}
+
+  f(A<Object> a) {}
+  g(
+    A<Object>  /// 06: error

[eernst, 2017/07/11 08:45:43]

This parameter type was declared as `A<void>` in `A<T>`, so it's an override
`A<void>` --> `A<Object>` in a contravariant position.

We will only get an error here with some kind of voidness preservation for
overriding, and it must be the "full" kind that takes `void` into account also
when it is not the top-level type (that is, when `void` occurs in the actual
type arguments of a generic type or in the argument types or return type of a
function type).

I can't see how it would make sense to add that kind of voidness preservation
checking for overrides without also adding full voidness preservation checking
for data flow (assignments, parameter passing, etc.).

This should then not be an error.

+    a) {}
+  h(
+    A<Object>  /// 07: error

[eernst, 2017/07/11 08:45:43]

This parameter type was declared as `A<T>` in `A<T>`, so it's an override
`A<void>` --> `A<Object>` in a contravariant position: Same as line 84, should
not be an error.

+    a) {}
+}
+
+void instantiateClasses() {
+  var a = new A<void>();
+  var b = new B();
+  var c = new C();
+  var d = new D();
+
+  a.foo();
+  b.foo();
+  c.foo();
+  d.foo();
+  a.bar();
+  b.bar();
+  c.bar();
+  d.bar();
+  a.gee(499);
+  b.gee(499);
+  c.gee(499);
+  d.gee(499);
+}
+
+void testAssignments() {
+  A<void> a1 = new A<Object>();
+  A<Object> a2 = new
+      A
+      <void>   /// implicit_downcast: error

[Leaf, 2017/02/23 21:30:53]

What does this mean?  Implicit downcasts aren't errors?

[eernst, 2017/07/11 08:45:43]

This can only be an error with full support for voidness preservation, so it
should not be an error at this point.

+      ();
+  A a3 = new A<void>();  /// raw_assignment: ok?

[Leaf, 2017/02/23 21:30:53]

There should be no difference between this one and the previous one.

[eernst, 2017/07/11 08:45:43]

Since we don't have voidness preservation at this point this is not an error in
any case (considered as `A<dynamic> a3 = new A<Object>();`).

I made the distinction between "strict" and "normal" voidness preservation
rulesets: The strict ones would disallow assignments where `void` derived
expressions were retyped as `dynamic` (e.g., `new A<void>().foo()` is `void` but
`a3.foo()` is `dynamic`), but I always considered the strict systems to be for
discussion only because everybody else seemed to think that this transition
would obviously be OK.

In that case it is not an error, even with full voidness preservation: It's `ok`
now and in the future.

+  A<dynamic> a4 = new A<void>();  /// A_dynamic_assignment: ok?

[Leaf, 2017/02/23 21:30:53]

ditto.

[eernst, 2017/07/11 08:45:43]

Same as line 117.

+  dynamic a5 = new A<void>();  /// dynamic_assignment: ok?

[eernst, 2017/07/11 08:45:43]

Since we don't have voidness preservation at this point, this is not an error in
any case.

However, this would never be a voidness preservation violation, no matter which
one of the voidness preservation rulesets we'd use. The point is that it is an
upcast that eliminates the class `A` from the type of the target object (and all
supertypes where its type argument is propagated, which is the empty set), so
we've "forgotten the voidness provided by the type argument to `A`".
 

It is true that `a5.foo()` is an untyped invocation of type `dynamic`, and `new
A<void>().foo()` has type `void`, but we cannot consider that to be a voidness
preservation violation. If we had considered it to be a violation then all data
flows (assignments, parameter passings, returns, etc) from a type containing
void to `dynamic` would be violations, which is even more strict than the
"strict rulesets" I mentioned above.

So this should be OK now and in the future.

+}
+
+main() {
+  instantiateClasses();
+  testAssignments();
+}