Fixes #2383. Add more constant evaluation tests

[sgrekhov]

No description provided.

[eernstg]

Looks good!

I was a little bit worried that the tests in LanguageFeatures/Extension-types/static_analysis_extension_types_A20_t02.dart would be duplicates of language tests that Lasse has added (or is about to add) to $SDK/tests/language/..., but we should in any case check all combinations so I listed a few that I couldn't find currently.

For the function test we'd probably need yet another test library: The current one is fine, but it doesn't test the processing of parameter types.

In particular, we should verify that types like void Function(int) and void Function(ExtInt1) and void Function(ExtInt2) are identical as constants. The reason why this is important is that the canonicalization of function types might use different parts of the implementation to reduce void Function(ExtInt1) to void Function(int) than the parts that we have already exercised with the other tests in this PR.

However, this additional test could certainly be a separate PR, if that's more convenient.

On the other hand, it's probably not important to have additional cases where the function types are nested in other types (that is, tests about Map<ExtFuncInt, ...> and such), because we have tested in the previous test that processing of Map<..., ...> does reach the type arguments. So if the function types work as the outermost part of a type then they probably also work as type arguments of Map. So it's fine that we have List<List<ExtFuncInt>> in a test here, but there's no need to expand on this kind of type in the new test.

But one function type as a subterm of another function type is a case that we need to cover.

I also think it's important that we express those types as function types directly: It is probably going to exercise different locations in the implementation when it handles void Function([ExtInt1]) vs. void Function([int]), compared to the situation where it handles F<ExtInt1> vs. F<int> where typedef F<X> = void Function([X]);.

So we might have a test that succeeds using F, but the test that contains the function types written out in full might still fail.

In summary, for this PR I think we just need to add a few cases that are missing, and then it's a different PR that adds a bunch of extra function type tests.

[eernstg]

Oops, I forgot one thing: Assuming the following declaration:

typedef T GenFunction<T>();

GenFunction<T> is an extra case (it will touch some other parts of the implementation than int Function(int)), but it is not a generic function, it's just a different way to produce the type int Function(int). So it would make sense to have some generic function types as well, in that extra test which is probably going into a separate PR.

Edit: ".. a different way to produce the type T Function(T) for a specific T which is the actual type argument to GenFunction (and int Function(int) was just an example)".

[sgrekhov]

@eernstg why typedef T GenFunction<T>(); is not a generic function type? Will typedef void GenFunction<T>(T t); be a generic function type?

I'm going to add all missing parts (including parametrized function types) to this PR if ypu don't mind

[eernstg]

why typedef T GenFunction<T>(); is not a generic function type?

GenFunction is a compile-time function that maps a type argument T into a non-generic function type. For instance, GenFunction<int> is the same thing as int Function().

A generic function type is the type of a function that accepts one or more actual type arguments at each invocation. For instance, X Function<X>(X) is a generic function type, and a function f with that type can be called as f<T>(t) where T is some term that denotes a type (which may or may not be known at compile time, so the passing of actual type arguments to f must be a run-time phenomenon), and t is an expression of type T.

The old-style type alias declaration cannot declare a generic function type, it can only declare a family of non-generic function types where each reference to the type alias must provide actual type arguments (or they will be selected using instantiation to bound).

In order to declare a generic function type using a type alias, use the new syntax: typedef F = X Function<X>(X);. For comparison, typedef G<X> = X Function(X); has the same meaning as typedef X G<X>(X);, and both of these declare a family of non-generic function types.

[eernstg]

add .. to this PR

OK!

[sgrekhov]

@eernstg is Ok that we have no error for ExtFuncGen2 below?

typedef T GenFunction1<T>(T t);
typedef GenFunction2<T> = T Function<T>(T t);

extension type const ExtFuncGen1<T>(GenFunction1<T> _) {} //  Error: An extension type parameter can't be used non-covariantly in its representation type.
extension type const ExtFuncGen2<T>(GenFunction2<T> _) {} // No error

[eernstg]

Yes, that's OK: The type parameter T of GenFunction2 is never used, because every occurrence of T on the right hand side of = is a reference to, or a declaration of, a type parameter of a generic function type. So it might as well have been defined as follows, which would arguably have been more readable:

typedef GenFunction2<T> = X Function<X>(X t);

[sgrekhov]

Updated. Please take another look

[eernstg]

Maybe I forgot where it is, but I think we don't cover canonicalization of function types where extension types occur as subterms. So we can do it here or in a separate PR, whatever fits best for you.

[sgrekhov]

Updated. Please take another look

[eernstg]

LGTM!