Add Subtyping tests for function types with covariant-by-declaration parameters

[sgrekhov]

Add Subtyping tests for function types with covariant-by-declaration parameters

[eernstg]

Ah, I'm afraid I don't understand what that would be. A function type that contains covariant is always a compile-time error, we can only put the modifier covariant on parameter declarations in instance method or instance setter declarations, and on instance variable declarations that have a setter.

Tear-offs of those instance methods do have a function type, but it doesn't contain covariant. Similarly, member signatures of such instance methods and setters do have a function type which is used for override checks and combined member signature computations, but we strip off covariant in order to compute that function type (and possibly change some parameter types, e.g., for override checks).

Could you clarify this a bit?

[sgrekhov]

Ah, we strip covariant when we tear-off a method. I didn't know that. But ok, then let's have the test that the following is an error

class A {
  void foo(num n) {
    print("A");
  }
}

class C implements A {
  void foo(covariant int n) {
    print("C");
  }
}

main() {
  C c = C();
  void Function(num n) f = c.foo; // Error. `covariant` doesn't allow us to override function type restrictions
}

[sgrekhov]

When I was filling this issue I supposed an opposite test. That tear-off of void foo(covariant int n) {} can be used everywhere where we expected void foo(num n). But ok, let's check that we are not allowed to do this

[eernstg]

let's have the test that the following is an error

Yes, that's a compile-time error because the member c.foo is considered to have the function type void Function(int) (so for the computation of the static type we ignore covariant). However, it is not a run-time error, because the actual run-time type of the tear-off will have the parameter type Object? (because that's always the case for a covariant parameter). So we can do this:

class A {
  void foo(num n) => print("A");
}

class C implements A {
  void foo(covariant int n) => print("C");
}

main() {
  A a = C();
  void Function(num n) f = a.foo; // OK at compile time; succeeds at run time, too.
  f(1.5); // But this throws.
}

The unusual bit here is that the static type of the tear-off is different from the dynamic type of the tear-off, even in the case where the static type of the receiver is exactly the run-time type of the receiver as well. The reason for this is that it is safer to assign the tear-off to a variable whose type won't cause the built-in argument type check to throw.

In other words, we can assign a.foo to a variable of type void Function(Object?) (using void Function(Object?) f = a.foo as dynamic;) because the given function object does actually have that type at run time, but unless we treat it as a void Function(int), it will throw when it is called.

In some cases we don't know the exact type of the receiver and in that case we can't see the potential dynamic error at compile time (as in a.foo where a has type A), but we're at least giving the developer a heads-up in the cases where it is possible to see the problem at compile time.