TFA has suboptimal handling of tearoffs

[sjindel-google]

We currently treat any method tearoff as an all-dynamic call to the function.

We can instead treat the tearoff as an inline closure (a, b, ...) => m.foo(a, b, ...) to at least regain some information about the parameters.

/cc @alexmarkov @mkustermann

[alexmarkov]

All-dynamic are narrowed using static types, so we're getting static types of parameters in case of tear-offs. Closures are treated similarly - all their parameters are approximated using static types.

Could you elaborate how you'd like to improve handling of tear-offs?

I created a separate issue #39692 to track work related to more accurate handling of closure calls, which may also include more accurate handling of tear-offs.

[sjindel-google]

This is actually not TFA's fault. I rewrote:

List<int>.generate(...).reduce(min)

as

List<int>.generate(...).reduce((x, y) => min(x, y))

Type-inference triggers in the second case and fills in the types of x and y as int, so TFA can infer that the calls to < inside min are against ints.