From ES6 rev20 draft, closed generator returns completed object (the
value is `undefined` and done is `true`).
Since a error thrown in generator is propagated to the caller without
setting status of a thrown generator to "completed", once a generator is
suspended by a error, status becomes "executing" forever. This is filed
as v8:3096
LOG=N
BUG=v8:3097
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/136003003
Patch from Yusuke Suzuki <yusukesuzuki@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18591 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The current specification has GeneratorFunction() be like Function(),
except that it makes generator instances. This commit implements that
behavior. It also fills in a piece of the implementation where
otherwise calling GeneratorFunction or GeneratorFunctionPrototype would
cause an abort because they have no code.
R=mstarzinger@chromium.org
TEST=mjsunit/harmony/generators-iteration
TEST=mjsunit/harmony/generators-runtime
BUG=v8:2355,v8:2680
Review URL: https://codereview.chromium.org/15218004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15084 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The current specification has GeneratorFunction() be like Function(),
except that it makes generator instances. This commit implements that
behavior. It also fills in a piece of the implementation where
otherwise calling GeneratorFunction or GeneratorFunctionPrototype would
cause an abort because they have no code.
R=mstarzinger@chromium.org, rossberg@chromium.org
TEST=mjsunit/harmony/generators-iteration
TEST=mjsunit/harmony/generators-runtime
BUG=v8:2355
BUG=v8:2680
Review URL: https://codereview.chromium.org/14857009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14684 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Ideally this would have been implemented via desugaring at parse-time,
but yield* is an expression, and its desugaring includes statements like
while and try/catch. We'd have to have BlockExpression in the AST to
support that, and it's not worth it for this feature.
So instead we implement all of the logic in
FullCodeGenerator::VisitYield. Delegating yield AST nodes now have a
try handler index, for the try/catch. Otherwise the implementation is
straightforward.
R=rossberg@chromium.org
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14582007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14669 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Ideally this would have been implemented via desugaring at parse-time,
but yield* is an expression, and its desugaring includes statements like
while and try/catch. We'd have to have BlockExpression in the AST to
support that, and it's not worth it for this feature.
So instead we implement all of the logic in
FullCodeGenerator::VisitYield. Delegating yield AST nodes now have a
try handler index, for the try/catch. Otherwise the implementation is
straightforward.
R=mstarzinger@chromium.org
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14666 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL extends the generator suspend and resume implementation to
capture values on the operand stack.
It factors out some helpers to measure and access the operand stack into
the JavaScriptFrame class. It also refactors the suspend and resume
helpers to avoid handle allocation.
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14348003
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14458 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch makes it so that suspending generators always saves the
context. Previously we erroneously assumed that if the operand stack
was empty, that the context would be unchanged, but that is not the case
with "with".
Fixing this brought out an interesting bug in the variable allocator.
Yield inside with will reference a context-allocated temporary holding
the generator object. Before the fix, this object was looked up in the
with context instead of the function context, because with contexts were
not being simulated during full-codegen. Previously this was OK as all
variables would be given LOOKUP allocation instead of CONTEXT, but the
context-allocated temporary invalidated this assumption. The fix is to
simulate the context chain more accurately in full-codegen.
R=mstarzinger@chromium.org
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14416011
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14454 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously there has been no reason to context-allocate the receiver, so
access to the receiver always goes through the stack. This was failing
with generators, which assumed that forcing context allocation would
relieve the need of storing anything but the context and the function on
the stack.
This CL adds a slot in generator objects to capture the receiver, and
restores it when resuming a generator.
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14158006
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14434 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The generator object methods "next", "send", and "throw" now
include some inline assembly to set up a resumed stack frame. In some
common cases, we can just jump back into the frame to resume it.
Otherwise the resume code calls out to a runtime to fill in the operand
stack, rewind the handlers, and possibly to throw an exception.
BUG=v8:2355
TESTS=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14066016
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14415 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
