Analyzer: Missing check for well-boundedness

[eernstg]

Consider the following program:

class A<X> {}
typedef F1<X extends A<X>> = X Function(X x);
typedef F2<X extends A<X>> = void Function();

void main() {
  void foo(
    F1 f1, // Error: Instantiation to bound failed.
    F2 f2, // Error: Instantiation to bound failed.
  ) {}
}

The raw types F1 and F2 that are used as parameter types in foo are completed by instantiation to bound, yielding F1<A<dynamic>> and F2<A<dynamic>> respectively.

However, those two types are not well-bounded: The type argument A<dynamic> doesn't satisfy the bound (A<dynamic> is not a subtype of A<A<dynamic>>), so the types are not regular-bounded. They are also not correctly super-bounded, because the type parameter is invariant respectively unused, so the substitution step where extreme types are replaced by the "opposite" type when occurring in a position with the right variance doesn't change anything. So F1 and F2 simply can't be used raw anywhere.

The same type can also not be used explicitly, because it still isn't well-bounded:

class A<X> {}
typedef F1<X extends A<X>> = X Function(X x);
typedef F2<X extends A<X>> = void Function();

void main() {
  void foo(
    F1<A<dynamic>> f1, // Error: Type not well-bounded.
    F2<A<dynamic>> f2, // Error: Type not well-bounded.
  ) {}
}

However, dartanalyzer from commit de3779e does not report any of these errors, so it seems that there is a missing check for such types being well-bounded (or the check occurs, but it replaces dynamic by Null/Never even when it occurs in a position that isn't covariant).

[srawlins]

I believe this is a duplicate of #36870

[eernstg]

Thanks for highlighting this issue. I took a look at #36870, and it is actually quite different. I changed #36870 to indicate the problem there more precisely (it's a missing scope in generic function types).

[eernstg]

With the spec update in dart-lang/language#1133, in code with null safety, the compile-time errors described above are no longer errors, because invariant and unused type variables are treated the same as covariant type parameters.

At this point we do not introduce breaking changes for code without null safety.

So I'll close this issue.