Implement AstBuilder integration for method/function invocations.

pkg/analyzer/lib/src/fasta/resolution_applier.dart

Index: pkg/analyzer/lib/src/fasta/resolution_applier.dart
diff --git a/pkg/analyzer/lib/src/fasta/resolution_applier.dart b/pkg/analyzer/lib/src/fasta/resolution_applier.dart
index 3624811ffc8b13a58491e1bbf1402c078eabc927..6ee190ce6ac81956df2dbcaee2609f175faf3e12 100644
--- a/pkg/analyzer/lib/src/fasta/resolution_applier.dart
+++ b/pkg/analyzer/lib/src/fasta/resolution_applier.dart
@@ -38,10 +38,11 @@ class ResolutionApplier extends GeneralizingAstVisitor {
   @override
   void visitMethodInvocation(MethodInvocation node) {
     node.target?.accept(this);
+    node.methodName.staticType = _getTypeFor(node.methodName);

[scheglov, 2017/07/21 04:03:03]

Could we move this statement after arguments, so avoid deferring types in
storer?

[Paul Berry, 2017/07/21 17:40:11]

Unfortunately, your suggestion would break a different case:

void test(f) {
  f(args);
}

In this case, the analyzer AST treats `f(args)` as a method invocation with no
target and a methodName of `f`, but kernel treats it as a method invocation with
a target of `f` (kernel calles it the "receiver") and a method name of `call`,
i.e. equivalent to `f.call(args);`.  So we would still have to reorder types in
storer, we would just have to reorder these implicit "call" cases instead of
reordering ordinary method calls.

I spent some time working out both cases on pen and paper, and IMHO reordering
ordinary method calls is less work.

[scheglov, 2017/07/21 17:43:58]

OK, thank you for the explanation.

     // TODO(paulberry): store resolution of node.methodName.
     // TODO(paulberry): store resolution of node.typeArguments.
     node.argumentList.accept(this);
-    node.staticType = _getTypeFor(node.methodName);
+    node.staticType = _getTypeFor(node.argumentList);
   }
 
   @override