Mark await expressions as caught or uncaught

src/ast/ast-numbering.cc

 // Copyright 2012 the V8 project authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "src/ast/ast-numbering.h"
 
 #include "src/ast/ast.h"
 #include "src/ast/scopes.h"
 
 namespace v8 {
@@ skipping 231 matching lines @@
   IncrementNodeCount();
   VisitVariableProxy(node->proxy());
   VisitFunctionLiteral(node->fun());
 }
 
 
 void AstNumberingVisitor::VisitCallRuntime(CallRuntime* node) {
   IncrementNodeCount();
   node->set_base_id(ReserveIdRange(CallRuntime::num_ids()));
   VisitArguments(node->arguments());
+  // To support catch prediction within async/await:
+  //
+  // The AstNumberingVisitor is when catch prediction currently occurs, and it
+  // is the only common point that has access to this information. The parser
+  // just doesn't know yet. Take the following two cases of catch prediction:
+  //
+  // try { await fn(); } catch (e) { }
+  // try { await fn(); } finally { }
+  //
+  // When parsing the await that we want to mark as caught or uncaught, it's
+  // not yet known whether it will be followed by a 'finally' or a 'catch.
+  // The AstNumberingVisitor is what learns whether it is caught. To make
+  // the information available later to the runtime, the AstNumberingVisitor
+  // has to stash it somewhere. Changing the runtime function into another
+  // one in ast-numbering seemed like a simple and straightforward solution to
+  // that problem.
+  if (node->is_jsruntime() &&
+      node->context_index() == Context::ASYNC_FUNCTION_AWAIT_CAUGHT_INDEX &&
+      catch_prediction_ == HandlerTable::ASYNC_AWAIT) {
+    node->set_context_index(Context::ASYNC_FUNCTION_AWAIT_UNCAUGHT_INDEX);

[jgruber, 2016/09/12 09:29:00]

This still raises flags for me. I understand why it can't be done in the parser,
but what about e.g. creating a new visitor just for catch prediction and
rewriting? 

But if no one else objects I'll concur.

[jgruber, 2016/09/12 12:22:27]

After speaking with Nikolaos about this, a new visitor might be a bad idea due
to performance reasons. Let's land it like this for now and clean up later
(possibly with the NonPatternRewriter?).

[Dan Ehrenberg, 2016/09/12 14:07:46]

Catch prediction runs in the AstNumberingVisitor, which is after all the
rewriters. It could hypothetically be moved there, but I don't see how that
would make anything cleaner.

+  }
 }
 
 
 void AstNumberingVisitor::VisitWithStatement(WithStatement* node) {
   IncrementNodeCount();
   DisableCrankshaft(kWithStatement);
   node->set_base_id(ReserveIdRange(WithStatement::num_ids()));
   Visit(node->expression());
   Visit(node->statement());
 }
@@ skipping 325 matching lines @@
 }
 
 
 bool AstNumbering::Renumber(Isolate* isolate, Zone* zone,
                             FunctionLiteral* function) {
   AstNumberingVisitor visitor(isolate, zone);
   return visitor.Renumber(function);
 }
 }  // namespace internal
 }  // namespace v8