New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 184 users

Issue metadata

Status: Fixed
Closed: Sep 2014
HW: ----
NextAction: ----
OS: ----
Priority: ----
Type: FeatureRequest

Blocked on:
issue 3566

Sign in to add a comment

Issue 2355: Implement generators

Reported by, Oct 2 2012

Issue description

Generators have been approved for

Firefox currently implements the `yield` keyword, but not the function*() {} syntax. I think v8 should do the same for now.

I searched everywhere and I can't find any existing bugs or plans for the `yield` keyword. This is a significant feature for javascript, one of the few that introduces a new semantic that is very difficult to simulate without native support.

This would have a big impact on node.js as well, allowing better style for async code.

Comment 1 Deleted

Comment 2 by, Jan 17 2013

+1. While for some people this will be just a "nice to have", for complex JS code and especially in node.js it would make all the difference in the world. It will enable people to write coroutine-like code instead of crufty and sometimes convoluted callback boilerplate. 

Edit: forgot to add - for example, something like task.js + V8 would mean pure awesome (especially for node)

Comment 3 Deleted

Comment 4 by, Jan 21 2013

I would give all Harmony features for only the support for generators. I believe it will bring ssjs to a comletely new level. So... WHEN??? :)

Comment 5 by, Mar 26 2013

Please, for the love of all that is good, yes. Sooner than later.

Comment 6 by, Mar 27 2013

Status: Accepted

Comment 7 by, Mar 27 2013


Comment 8 by, Mar 27 2013

Thanks all gods!

Comment 9 by, Mar 27 2013


Comment 10 by, Mar 27 2013

Thank you!

Comment 11 by, Mar 27 2013

Please make it an expression  so one can conveniently pass a value to generator, e.g.:

  var x;
  x = yield;


  return yield MyAsyncFunction();

Comment 12 by, Mar 27 2013

The specs already has yield as an expression, so they should implement it that way.

Comment 13 by, Mar 27 2013

Labels: Harmony

Comment 14 by, Mar 27 2013

Labels: Type-FeatureRequest
Summary: Implement generators (was: Implement `yield` for generators)

Comment 15 by, Mar 29 2013

>Firefox currently implements the `yield` keyword, but not the function*() {} syntax. I think v8 should do the same for now.

Uh very bad idea. Please stick with the spec.

Comment 16 by, Apr 1 2013

No worries, I already changed the original bug title to reflect that we intend to implement the spec properly.

Comment 17 by, Apr 2 2013

Any ETA on this one :)?

Comment 18 by, Apr 2 2013

@17: Feature requests generally don't have ETAs other than "when it's done".
You can bet that none of the ES6 features will be enabled by default before the ES6 spec has been finalized.

Comment 19 by, May 9 2013

+1 so I can stay up to date.  This will be much appreciated.

Comment 20 by, May 27 2013


Comment 21 Deleted

Comment 22 by, May 27 2013

Short update on the status of generators: A first experimental implementation is available on bleeding edge (and Chrome Canary releases), as usual the feature is hiding behind a flag (i.e. the separate --harmony-generators or the more broad --harmony). Kudos go to Andy Wingo for his efforts in pushing this feature and contributing the majority of the implementation.

The following is a short list of known issues or missing features:
- Support for compiling generators with Crankshaft.
- Generators don't have an 'iterate' method.
- The usual assortment of bugs.

As always, feedback (e.g. in the form of bug-reports) is very much appreciated.

PS: Harmony iterators (i.e. the for-of feature) is tracked separately by  issue 2214  and is work in progress. Also the ability to iterate over Maps and Sets is tracked separately by  issue 1793 .

Comment 23 by, Jun 9 2013

It looks like the EcmaScript spec had some changes recently that differ from V8's implementation:

- There is no send() method in generators anymore. It's replaced by next(value).
- close() was also removed.

Comment 24 by, Jun 9 2013

ticket for removing "close" method:
ticket for removing "send" method:

Comment 25 by, Jun 20 2013

Found a slight bug… Example code:
> ({ ok: true, fn: function*(a) { this.ok } }).fn(0).next();

This code works fine on x64 builds, but crashes on ia32 when it attempts to run "this.ok", because "this" appears to be in "the hole".
I tracked the problem down to that the EmitGeneratorResume-function appears to be pushing two arguments onto the stack for every formal argument defined on the function, making the example code create a stack like:
  [02] : 0x5a0080a1 <the hole>
  [01] : 0x5a0080a1 <the hole>
  [00] : 0x22714589 <an Object with map 0x5fc0ae71>#3#

`this` then gets assigned to the value at 01 instead of 00.. I ran a test where i fixed the stack up afterwards which appears to fix the problem and verified that on x64 where the code works, the stack looks right.

Comment 26 by, Jun 20 2013

Thanks for the excellent report,!  I'll rustle up a fix.

Comment 27 by, Jun 20 2013 Your bug is fixed in  Thanks again for the report.

Comment 28 by, Jun 20 2013

Thanks for the fast fix!

Comment 29 by, Dec 25 2013

I am using node v0.10.24. How do I enable generators?

Comment 30 by, Dec 25 2013

I don't think that Node version uses a V8 recent enough to have the generators implementation.

Comment 31 Deleted

Comment 32 by, Dec 25 2013

You should use nodejs >= 0.11.2.

Comment 33 Deleted

Comment 34 by, Dec 25 2013

That's not a V8-related question and you can easily google it. Please, don't overuse the bug tracker, you're spamming everyone subscribed. Please, try to find answers for your questions by yourself before asking (and even if you can't find it, this is not the place to ask about Node release dates). Thanks.

Comment 35 by, Sep 16 2014

Project Member
The following revision refers to this bug:

commit a76fe0a2cff7bf34f632e987445498c8d5325b7c
Author: <>
Date: Tue Sep 16 12:30:39 2014

Enable ES6 generators

BUG= v8:2355 

Review URL:

git-svn-id: ce2b1a6d-e550-0410-aec6-3dcde31c8c00


Comment 36 by, Sep 17 2014

Status: Fixed
Closing as Fixed, since generators are enabled by default as of r23974.  See the intent to ship mail here:!topic/v8-users/3DlzFt8Fc8o

Comment 37 by, May 11 2015

Blockedon: v8:3566

Comment 38 by, Jan 3 2017

Project Member
The following revision refers to this bug:

commit c523474713e11e98f0b87f2d7137cf3465aab13c
Author: caitp <>
Date: Tue Jan 03 21:38:22 2017

[cleanup] remove sloppy generator/async function maps

These maps contain exactly the same information as the strict maps, so
this frees up a few pointers of native context space, gets rid of some
branches in FastNewClosure, and adds missing poisoned properties tests
for async functions.

BUG= v8:2355 ,  v8:4483,,

Cr-Commit-Position: refs/heads/master@{#42051}


Comment 39 by, Jul 21 2017

Project Member
The following revision refers to this bug:

commit 00681326a3b946503023466ad59d99556c777e36
Author: Caitlin Potter <>
Date: Fri Jul 21 16:48:57 2017

[interpreter] refactor BuildGeneratorSuspend/Resume into BuildSuspendPoint

Simplify the model for generating Awaits, because the resume point is
always immediately following the suspend point, and registers used are
always the same for both operations.

Includes a minor refactoring of BytecodeGenerator::VisitYield() to
perform iterator result creation before the SuspendGenerator bytecode,
rather than between SuspendGenerator and Return. This adds a small
number of bytecodes for each yield.

BUG= v8:2355 ,  v8:5855 

Change-Id: I4868b89a6bc1b251f887d2a45890c8fa19f7b089
Reviewed-by: Ross McIlroy <>
Reviewed-by: Georg Neis <>
Commit-Queue: Caitlin Potter <>
Cr-Commit-Position: refs/heads/master@{#46820}

Sign in to add a comment