Improve parsing of function expressions.

pkg/front_end/lib/src/fasta/kernel/body_builder.dart

Index: pkg/front_end/lib/src/fasta/kernel/body_builder.dart
diff --git a/pkg/front_end/lib/src/fasta/kernel/body_builder.dart b/pkg/front_end/lib/src/fasta/kernel/body_builder.dart
index 283adcb7163dd835a9dd638aa8b8a32a58c0ea3d..0c6996914ff6e315f1f432d1ccbf497730df3b30 100644
--- a/pkg/front_end/lib/src/fasta/kernel/body_builder.dart
+++ b/pkg/front_end/lib/src/fasta/kernel/body_builder.dart
@@ -2412,20 +2412,26 @@ class BodyBuilder extends ScopeListener<JumpTarget> implements BuilderHelper {
   }
 
   @override
-  void beginFunction(Token token) {
-    debugEvent("beginFunction");
+  void beginFunctionDeclaration(Token token) {
+    debugEvent("beginNamedFunctionExpression");
     enterFunction();
   }
 
   @override
-  void beginUnnamedFunction(Token token) {
-    debugEvent("beginUnnamedFunction");
+  void beginNamedFunctionExpression(Token token) {
+    debugEvent("beginNamedFunctionExpression");
     enterFunction();
   }
 
   @override
-  void endFunction(Token getOrSet, Token endToken) {
-    debugEvent("Function");
+  void beginFunctionExpression(Token token) {
+    debugEvent("beginFunctionExpression");
+    enterFunction();
+  }
+
+  @override
+  void endNamedFunctionExpression(Token endToken) {
+    debugEvent("NamedFunctionExpression");
     Statement body = popStatement();
     AsyncMarker asyncModifier = pop();
     if (functionNestingLevel != 0) {
@@ -2433,16 +2439,39 @@ class BodyBuilder extends ScopeListener<JumpTarget> implements BuilderHelper {
     }
     FormalParameters formals = pop();
     List<TypeParameter> typeParameters = typeVariableBuildersToKernel(pop());
-    push(formals.addToFunction(new FunctionNode(body,
-        typeParameters: typeParameters, asyncMarker: asyncModifier)
-      ..fileOffset = formals.charOffset
-      ..fileEndOffset = endToken.charOffset));
+
+    exitLocalScope();
+    KernelFunctionDeclaration declaration = pop();
+    VariableDeclaration variable = declaration.variable;
+    var returnType = pop();
+    returnType ??= const DynamicType();
+    pop(); // Modifiers.
+    exitFunction();
+
+    variable.initializer = new KernelFunctionExpression(formals.addToFunction(
+        new FunctionNode(body,
+            typeParameters: typeParameters, asyncMarker: asyncModifier)
+          ..fileOffset = formals.charOffset
+          ..fileEndOffset = endToken.charOffset))
+      ..parent = variable
+      ..fileOffset = formals.charOffset;
+    push(new Let(variable, new VariableGet(variable)));
   }
 
   @override
-  void endFunctionDeclaration(Token token) {
+  void endFunctionDeclaration(Token endToken) {
     debugEvent("FunctionDeclaration");
-    FunctionNode function = pop();
+    Statement body = popStatement();
+    AsyncMarker asyncModifier = pop();
+    if (functionNestingLevel != 0) {
+      exitLocalScope();
+    }
+    FormalParameters formals = pop();
+    List<TypeParameter> typeParameters = typeVariableBuildersToKernel(pop());
+    FunctionNode function = formals.addToFunction(new FunctionNode(body,
+        typeParameters: typeParameters, asyncMarker: asyncModifier)
+      ..fileOffset = formals.charOffset
+      ..fileEndOffset = endToken.charOffset);
     exitLocalScope();
     var declaration = pop();
     var returnType = pop();
@@ -2469,8 +2498,8 @@ class BodyBuilder extends ScopeListener<JumpTarget> implements BuilderHelper {
   }
 
   @override
-  void endUnnamedFunction(Token beginToken, Token token) {
-    debugEvent("UnnamedFunction");
+  void endFunctionExpression(Token beginToken, Token token) {

[danrubel, 2017/07/06 15:43:34]

rename token to endToken? Or is it tokenAfterExpression?

[ahe, 2017/07/06 19:54:18]

Now that I think about it, I think I've been rather consistent about not calling
it endToken. It's always "token" for the current position in the token stream,
and if there's more than one token, the other tokens get a name.

I need to think more about this.

[danrubel, 2017/07/06 19:58:42]

Naming the current token 'token' sounds good to me.

[Paul Berry, 2017/07/06 20:06:57]

Not a blocking issue, just food for thought: I have been thinking of the
parser's "current token" as an implementation detail of the parser that
shouldn't be exposed to its clients.  E.g. if the language contains an ambiguous
construct whose interpretation depends on the tokens that follow, the client
shouldn't care whether the parser addresses the ambiguity by peeking ahead, then
calling the callback, then consuming additional tokens, or by consuming enough
tokens to resolve the ambiguity, then calling the callback.  All the client
cares about is what callbacks are called and what their parameters are.

So I'd personally favor using the name "endToken" in all cases.

However, I'm already used to interpreting "token" as "endToken" when writing
parser clients, so I am ok with whatever you decide.

[ahe, 2017/07/06 20:58:53]

That's actually what I do for type variables. And a really good point.
But, the slightly more terse "token" is my favorite so far, simply for being
shorter.

+    debugEvent("FunctionExpression");
     Statement body = popStatement();
     AsyncMarker asyncModifier = pop();
     exitLocalScope();