Mark await expressions as caught or uncaught

src/ast/ast-numbering.cc

Index: src/ast/ast-numbering.cc
diff --git a/src/ast/ast-numbering.cc b/src/ast/ast-numbering.cc
index d0101828d6897f99c91e069024460c4aae10ebf6..20225858011c910181e4d7001a20721de24b5acb 100644
--- a/src/ast/ast-numbering.cc
+++ b/src/ast/ast-numbering.cc
@@ -249,6 +249,27 @@ 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 { }

[adamk, 2016/09/09 18:46:28]

Nit: remove the semicolon, it's distracting since it suggests that that's one of
the differences between the first and second.

[Dan Ehrenberg, 2016/09/10 01:54:14]

Added the semicolon to the other case

+  //
+  // 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);
+  }
 }