Analyzer rejects tests/language_2/generic_methods_generic_function_result_test.dart

[crelier]

The errors reported by the analyzer for tests/language_2/generic_methods_generic_function_result_test.dart does not look correct.

ERROR|STATIC_WARNING|LIST_ELEMENT_TYPE_NOT_ASSIGNABLE|/b/build/slave/azrs-be/build/sdk/tests/language_2/generic_methods_generic_function_result_test.dart|14|44|3|The element type '(int, T) → T' can't be assigned to the list type '(S, T) → T'.
ERROR|STATIC_WARNING|LIST_ELEMENT_TYPE_NOT_ASSIGNABLE|/b/build/slave/azrs-be/build/sdk/tests/language_2/generic_methods_generic_function_result_test.dart|14|49|3|The element type '(int, T) → T' can't be assigned to the list type '(S, T) → T'.
ERROR|STATIC_WARNING|ARGUMENT_TYPE_NOT_ASSIGNABLE|/b/build/slave/azrs-be/build/sdk/tests/language_2/generic_methods_generic_function_result_test.dart|21|35|3|The argument type 'int' can't be assigned to the parameter type 'S'.

[bwilkerson]

@leafpetersen Can you confirm that this is an error?

[leafpetersen]

The first error is correct, at least that it is an error. To put foo into the list, we need to show that it's type is a subtype of T Function<T extends num>(S, T). That is,

T foo<T extends num>(int i, T t) <: T Function<T extends num>(S, T)

Note that all of the T occurrences here refer to the bound T in the types, not the outer T from the enclosing context.

To show this, we must show that T <: T which is true, and that S <: int which is not true (since all we know is that S <: num.

The error doesn't print the generic parameters on the types though, which doesn't seem ideal.

[leafpetersen]

The second error is, I believe a repeat of the first for the second occurence of foo, so also correct.

[leafpetersen]

The third error looks incorrect. The inferred type of list should be List<T Function<T extends num>(int, T)> , so list[1] should have type T Function<T extends num>(int, T), so list[1]<int> should have type int Function(int, int) and the application should be fine.

At the point of the application of list[1], S should have been substituted away, and shouldn't appear in the error anyway, even if it was an error.

[crelier]

Thanks Leaf!
I guess I should change the upper bound of S from num to int to satisfy static analysis in strong mode.
Of course, S cannot take many different type values then, but the goal of this test is to verify proper resolution of S, which is unrelated to these analysis errors.
The 3rd error remains, which does not invalidate this bug report even if I correct the test.

I also realize that the comment is wrong. It should be
// "<T extends num>(int, T) => T" when reifying generic functions.

[leafpetersen]

cc @jmesserly

[jmesserly]

fyi #29778 is a possibly related substitution problem

[eernstg]

The test should actually be rejected at compile-time because it uses a generic function type as an actual type argument (at all), not because of any particular missing subtype relationships.

We have the following in the informal spec of the new inline function types, which is the construct that introduces support for specifying the type of a generic function: 'It is a compile-time error if a generic function type is used as a bound for a formal type parameter of a class or a function. It is a compile-time error if a generic function type is used as an actual type argument'. Issue #29484 provides more background.

[crelier]

I do not think any of these restrictions apply to this test. No generic function type is used as bound or as type argument. Here is the source of the test to avoid confusion:

import "package:expect/expect.dart";

T foo<T extends num>(int i, T t) => i + t;

List<T Function<T extends num>(S, T)> bar<S extends int>() {
  return <T Function<T extends num>(S, T)>[foo, foo];
}

void main() {
  var list = bar<int>();
  print(list[0]
      .runtimeType); // "<T extends num>(int, T) => T" when reifying generic functions.
  Expect.equals(123, list[1]<int>(100, 23));
}

[leafpetersen]

Ah, right, I completely missed that. @eernstg is correct - we have a predicativity restriction: " It is a compile-time error if a generic function type is used as an actual type argument", so List<T Function<T extends num>(S, T)> should be an error.

[crelier]

Oops, sorry, I see it now. The type argument of List in the return type is a generic function type.
The VM should reject it and obviously does not.
I will make this test a negative sub-test of a multi-test, with another simpler sub-test actually testing the proper resolution of S in the result type as was intended.

[crelier]

The test has been updated, but the analyzer fails to report a compile time error in non-strong mode (multi test '01') and wrongly reports a compile time error in strong mode (multi test 'none').

[jmesserly]

merging this into #29778

[MichaelRFairhurst]

Reopening this. The analyzer correctly reports an error where it should, but, as Leaf had said:

The third error looks incorrect. ... At the point of the application of list[1], S should have been substituted away, and shouldn't appear in the error anyway, even if it was an error.

This is still an issue in the test

[srawlins]

SG