Type equality inconsistency for generic functions.

[lrhn]

When we generate a Type object for a generic function, dart2js normalizes dynamic bounds to be the same as Object bounds, and the VM doesn't even consider structurally equal types to be equal Type objects.

Example:

Type type<T>() => T;
main() {
  var t0 = type<void Function<X extends Object>(X) Function()>();
  var t1 = type<void Function<X extends Object>(X) Function()>();
  var t2 = type<void Function<X extends dynamic>(X) Function()>();
  var t3 = (<D>() => type<void Function<X extends D>(X) Function()>())<dynamic>();
  print(t0 == t1);  // false in VM, true in dart2js, even though it is *exactly* the same type.
  print(t1 == t2);  // false in VM, true in dart2js
  print(t2 == t3);  // false in VM, true in dart2js
  print(t1 == t3);  // false in VM, true in dart2js
  print(t1); // () => <T1>(T1) => void
  print(t2); // () => <T1>(T1) => void
  print(t3); // () => <T1 extends dynamic>(T1) => void in VM, () => <T1>(T1) => void in dart2js.
}

The VM is definitely wrong about equality of the structurally same type.
As to considering dynamic and Object as the same bound, I guess that's reasonable, even though a little inconsistent (a bound of void is not equal).

[eernstg]

Note the overlap with #32782 / #32783, which is associated with the test language_2/type_alias_equality. That test uses type aliases as well, but the bug is actually in the treatment of the underlying type, which includes generic function types and also has a case with differently named type variables.

[vsmenon]

@lrhn is this a language bug to clarify the spec?

[eernstg]

The spec was updated in #34447 to say that Type.== must evaluate to true iff the arguments are subtypes of each other. So the spec already requires the equalities t0 == t1, t2 == t3.

For the bounds of type parameters of generic function types, the spec relies on renaming (generic function types are explicitly considered to be the same type if they only differ by choice of names), and this is not sufficient to establish a subtype relationship like Function<X extends Object>() <: Function<X extends dynamic>(). We might consider that to be an unintended distinction (it seems inconsistent to me), and we could then change the subtype rules to say that also bounds must just be mutual subtypes.

This would also be a non-breaking change, according to the following test (which has no errors with the analyzer, also with --no-implicit-casts, and also not with dart or dart2js):

main() {
  void Function<X extends Object>(X) Function() f1 = null;
  void Function<X extends Object>(X) Function() f2;
  void Function<X extends dynamic>(X) Function() f3;
  void Function<X extends D>(X) Function() f4pre<D>() => null;
  var f4 = f4pre<dynamic>();
  f2 = f1; f1 = f2; f3 = f2; f2 = f3; f3 = f4; f4 = f3;
  f3 = f1; f1 = f3; f4 = f2; f2 = f4; f4 = f1; f1 = f4;

  void Function<X extends List<dynamic>>(X) f6;
  void Function<X extends List<FutureOr<void>>>(X) f7;
  f6 = f7; f7 = f6;
}

So I believe we can extract a spec change issue here: Change the subtype rules to use mutual subtyping for generic function type bounds—if we want to do that. If we don't want to change the subtype rules then dart2js is wrong on t1 == t2 and t1 == t3.

Other than that, there is still the issue with the VM.

[lrhn]

Even if we change the specifiction to be "Type objects are == equal if they are the the same type" (which might be a good idea since that's almost what everybody implmenets), then "the same type" for structural types like function types still means that void Function<T>(T) Function() is the same type every time you write it. There is only one function type with that structure.

So, this is a VM bug.
Hardly a high priority one, though.

[eernstg]

PS: Unless we change the subtype rules, it is also a dart2js bug.