tear-off of function's call method might be expensive

[rakudrama]

dart2js would like to minimize the extra metadata required for generic methods.

The Kernel instruction Instantiation, used to bind generic type arguments of a generic closure, currently is inserted at specific points - tear-off of instance method, escape of local or top-level method, use of an anonymous closure. At these points we can identify the target or set of targets fairly precisely and thus create metadata for supporting instantiation for specific methods.

However, there is a leak - the call method of functions can be torn off. Since get:call for a function returns the function itself, this means that any generic function that can flow to the tear-off site might be partially-applied by the injected Instantiation instruction. This would mean that more generic functions would need to support being instantiated - e.g. any function compatible with fun below:

int Function(int) g;
void foo(R Function<R>(R) fun) {
  g = fun;  //  g = Instantiate<int>(fun);
}

I propose that we disallow tear-offs of the call method until we can measure the impact of this information leak.

Related: #31665

[stereotype441]

It seems reasonable to me to disable implicit instantiation of function call methods for now, especially considering that the ability to refer directly to a function's call method is probably going to be removed from the language anyhow.

CL to disable implicit instantiation of function call methods is here: https://dart-review.googlesource.com/#/c/sdk/+/31751

[lrhn]

There are no restrictions on accessing call on functions. It's now the canonical way to do a null-aware invocation, fn?.call(args).