For-of calls [Symbol.iterator]() on RHS to get iterator

For-of calls [Symbol.iterator]() on RHS to get iterator

R=rossberg@chromium.org
BUG=http://code.google.com/p/v8/issues/detail?id=2735
LOG=N

Committed: https://code.google.com/p/v8/source/detail?r=21820

[wingo, 2014-06-12 08:52:37]

PTAL.  The change to the AST is kinda nasty but seemed to be the smallest change
I could make to do the right thing (namely, shortcutting the loop if the
iterable is null or undefined, and otherwise binding the iterator to
iterable[@@iterator]()).

[rossberg, 2014-06-12 12:36:40]

LGTM. You might want to add a simple test checking that generators actually have
a @@iterator property now.

> PTAL.  The change to the AST is kinda nasty but seemed to be the smallest
change
> I could make to do the right thing (namely, shortcutting the loop if the
> iterable is null or undefined, and otherwise binding the iterator to
> iterable[@@iterator]()).

Oh dear, I hadn't even noticed that special case. Seems wrong, especially for
undefined, where it will mostly just mask bugs.

[wingo, 2014-06-12 14:32:41]

On 2014/06/12 12:36:40, rossberg wrote:
> LGTM. You might want to add a simple test checking that generators actually
have
> a @@iterator property now.

Will do so in a followup.

> > PTAL.  The change to the AST is kinda nasty but seemed to be the smallest
> change
> > I could make to do the right thing (namely, shortcutting the loop if the
> > iterable is null or undefined, and otherwise binding the iterator to
> > iterable[@@iterator]()).
> 
> Oh dear, I hadn't even noticed that special case. Seems wrong, especially for
> undefined, where it will mostly just mask bugs.

I agree but I think my (bad) language design instincts aren't the same as
Allen's :)

[wingo, 2014-06-12 17:32:30]

Committed patchset #1 manually as r21820 (presubmit successful).