Possibly unintended runtime error in patterns tests

[chloestefantsova]

In the following tests the first positional argument to the invocations of getType is cast to the inferred type argument of the invocation. However, the type of the first formal positional parameter of getType is Object?, which leads to a difference between the inferred type argument to getType and the inferred type argument to [] passed as the first positional argument.

co19/LanguageFeatures/Patterns/type_inference_A07_t01.dart

Line 53 in 7b4f3e7

var <B>[A v1, B v2, v3] = getType([], (String s) {log += s;});

The stack trace is as follows:

stderr:
Unhandled exception:
type 'List<dynamic>' is not a subtype of type 'List<C>' in type cast
#0      getType (file:///b/s/w/ir/tests/co19/src/LanguageFeatures/Patterns/patterns_lib.dart:47:12)
#1      main (file:///b/s/w/ir/tests/co19/src/LanguageFeatures/Patterns/type_inference_A07_t01.dart:64:15)
#2      _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:297:19)
#3      _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:189:12)

Another similar case is the following:

co19/LanguageFeatures/Patterns/type_inference_A08_t01.dart

Line 49 in 7b4f3e7

var <String, C>{} = getType({}, (String s) {log += s;});

[eernstg]

Looks like getType should be adjusted to have type T rather than Object? for the first formal parameter.

The point is that getType can "measure" the context type schema (or at least its greatest closure), in order to verify that the initializing expression gets the right context type schema. But at run time we should also have an object with that type, and Object? won't communicate the value of T to the actual argument. So we can specify the type arguments explicitly on that first argument, as in <String, C>{}, or we can change getType to give {} that context type, whatever works.

[eernstg]

That was wrong! ;-)

The parameter type will need to be separated from the type parameter after all: The point is that the getType invocation must faithfully reflect the actual context type schema. If we use the formal parameter type T for the first parameter of getType then getType(d, ...) will infer as getType<D>(d, ...) even though the context type should be _. So we'll have to return to T getType<T>(Object? o, ...) and then write those type arguments on the first actual argument of getType manually, where needed.

[alexmarkov]

LanguageFeatures/Patterns/type_inference_A08_t01 was mentioned above but it wasn't fixed:

co19/LanguageFeatures/Patterns/type_inference_A08_t01.dart

Line 49 in 5463a0b

var <String, C>{} = getType({}, (String s) {log += s;});