Fix for parsing EmptyFunctionBody with Fasta.

pkg/front_end/lib/src/fasta/parser/listener.dart

Index: pkg/front_end/lib/src/fasta/parser/listener.dart
diff --git a/pkg/front_end/lib/src/fasta/parser/listener.dart b/pkg/front_end/lib/src/fasta/parser/listener.dart
index 0df837074403df545660ff6ecfbeadbe4eb2fa7d..9b1fb463807f7c62207a60634e3813e52f5c0e54 100644
--- a/pkg/front_end/lib/src/fasta/parser/listener.dart
+++ b/pkg/front_end/lib/src/fasta/parser/listener.dart
@@ -559,6 +559,10 @@ class Listener {
 
   void beginReturnStatement(Token token) {}
 
+  void endEmptyFunctionBody(Token semicolon) {

[ahe, 2017/03/13 09:20:19]

Overall, I think it might be simpler to add a boolean to endFunctionBody.

However, if you prefer this approach, you should add a comment to both
beginFunctionBody and endFunctionBody that this method might be called instead
of endFunctionBody. See lines 22-24.

[scheglov, 2017/03/13 15:48:40]

  It depends.
  This way we get at least some documentation about tokens in form of parameter
names.
  It does not look that endFunctionBody() or most of the other methods have
documentation. So, any reader should expect to use search to learn anything.

  Actually, beginFunctionBody() is not what it says at all.
  It is not consistent with the language specification.
  It is more like beginBlockFunctionBody().
  So search and thoughtful reading is a must.

[Paul Berry, 2017/03/13 16:55:16]

I agree that the current state of the documentation in the Fasta code base isn't
great--often the developer has to read the code carefully to understand what's
going on.  But it sounds like you're making the argument that since the
developer has to read the code carefully, there's no point in writing
documentation.  I think that's a dangerous line of thinking--applied
universally, it would mean that we never got around to adding documentation to
code that lacked it.

I think that whenever one of us learns something by reading code, or a subtlety
is discussed in a code review that would have been nice to have been in a
comment, we should add comments.  If we keep doing this consistently, the code
base will eventually have good enough documentation that developers can
consistently rely on it.

+    logEvent("EmptyFunctionBody");
+  }
+
   void endExpressionFunctionBody(Token arrowToken, Token endToken) {
     logEvent("ExpressionFunctionBody");
   }