[esnext] prototype runtime implementation for async functions

src/builtins.cc

Index: src/builtins.cc
diff --git a/src/builtins.cc b/src/builtins.cc
index 7609de8aaffc160d37535d2ce5c8e59f556f5342..6c9c1b5f362bcbc719947932da4b7db0560254b6 100644
--- a/src/builtins.cc
+++ b/src/builtins.cc
@@ -2478,6 +2478,17 @@ void Builtins::Generate_GeneratorPrototypeThrow(CodeStubAssembler* assembler) {
                                     "[Generator].prototype.throw");
 }
 
+void Builtins::Generate_AsyncFunctionNext(CodeStubAssembler* assembler) {
+  Generate_GeneratorPrototypeResume(assembler, JSGeneratorObject::kNext,
+                                    "AsyncFunctionNext");
+}
+
+// ES6 section 25.3.1.4 Generator.prototype.throw ( exception )
+void Builtins::Generate_AsyncFunctionThrow(CodeStubAssembler* assembler) {
+  Generate_GeneratorPrototypeResume(assembler, JSGeneratorObject::kThrow,
+                                    "AsyncFunctionThrow");
+}

[Dan Ehrenberg, 2016/05/04 22:52:36]

Just to make sure I understand, these are separate builtins just so they can be
marked native? Might be good to note in a comment, as our stack trace strategy
could change in the future as the implementation is changed for performance.

[Benedikt Meurer, 2016/05/05 19:04:45]

From my POV, these are separate primarily because they are a temporary
work-around to connect async function resume to promise.js. G.p.next and friends
are frontends for generators. This whole dance is just to find a non-intrusive
way for now to call the ResumeGenerator builtin from promise.js. So separation
helps us to easily remove these unnecessary indirections (also the driver
closures in async-await.js) once we're there.

+
 // -----------------------------------------------------------------------------
 // ES6 section 26.1 The Reflect Object