[DAS] Review of `FunctionType.call` member

[FMorschel]

FunctionType.call member is not coloured as a method, and hover shows dynamic, but we get errors like not_enough_positional_arguments and completion for it and named parameters.

Repro:

void f(int i) {
  f.call();
}

[FMorschel]

I know where to mess with the colouring, but how do we infer the type for it? I think this will solve the colouring problem. I'd like to give it a try if it is not too hard.

I guess that this is the actual type, but we could special-case this since we know it should be exactly equal to the instance calling it.

CC @bwilkerson @scheglov

[FMorschel]

The completion is also incoherent; it shows the result type (differently than the actual function) and not the actual FunctionType:

FYI @DanTup

[scheglov]

The best I know out of head is that we resolve using MethodInvocationResolver.
Also might be related to MethodElement.CALL_METHOD_NAME references.

[DanTup]

The completion is also incoherent; it shows the result type

Yeah, the first screenshot looks completely wrong to me here. I think the second and third mostly make sense (the difference being that foo is a function, whereas fn is a variable of type void Function(...). That we show "..." in some places and the full signature in the other isn't consistent, but I think there might be an open issue for that somewhere?

[FMorschel]

I think there might be an open issue for that somewhere?

I brought it up, that issue has been closed, and we (kind of?) decided to keep it as that (see #60099 (comment), we never opened another issue to discuss this specifically).

I was just wondering whether we wanted to consider call to be a method or something like a getter with a FunctionType return, but from your answers above, I believe the implicit definition being a method is what is more consistent.

[DanTup]

I was just wondering whether we wanted to consider call to be a method or something like a getter with a FunctionType return, but from your answers above, I believe the implicit definition being a method is what is more consistent.

I wasn't sure about this, but I searched in the Dart language spec and found this:

(17.15.3), where T0 is a class with interface I, is also considered to have interface
I. Similarly, when T is T0 bounded where T0 is a function type, T is considered
to have a method named call with signature m, such that the function type of
m is T0.

I'm not great at reading this spec, but I think this is describing the situation here and it refers to it as a method.

I did start looking at this to see if it was a fix in the server or not, and started a fix for the Hover part at https://dart-review.googlesource.com/c/sdk/+/448980 but I'm not sure it's the right fix so I'll wait for feedback before going any further.

[FMorschel]

Just as a note, I also noticed that there was no quick-fix to add ?.call before a function invocation at #42762. So here is the CL https://dart-review.googlesource.com/c/sdk/+/449142.

[FMorschel]

Also, what do you feel like the best highlight would be? For all other FunctionType.call? Or for the declaring function/method? Or even a mix of both, like what we have with destructing patterns. I noticed it doesn't do highlighting at all, either.