Enable ES6 iteration by default

Enable ES6 iteration by default

This enables for-of, as well as @@iterator implementations for strings
and arrays.

R=rossberg@chromium.org
BUG=v8:2214
LOG=Y

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

[rossberg, 2014-08-07 14:10:03]

LGTM, except that the relevant tests should move to the mjsunit/es6 directory
now.

[wingo, 2014-08-07 14:59:43]

On 2014/08/07 14:10:03, rossberg wrote:
> LGTM, except that the relevant tests should move to the mjsunit/es6 directory
> now.

Humm, moving the tests there causes them to fail, as that directory is run with
--always-opt --turbo-filter=*.  Example failing test program under those flags
(which works fine otherwise):

function wrap_iterator(iterator) {
    var iterable = {};
    iterable[Symbol.iterator] = function() { return iterator; };
    return iterable;
}

function integers_until(max) {
  function next() {
    var ret = { value: this.n, done: this.n == max };
    this.n++;
    return ret;
  }
  return wrap_iterator({ next: next, n: 0 });
}

function fold(cons, seed, iterable) {
  for (var x of iterable) {
    seed = cons(x, seed);
  }
  return seed;
}

function sum(x, tail) {
  return x + tail;
}

if (fold(sum, 0, integers_until(10)) != 45) throw "wat";

Could it be something about the bailout id's again?  For-of isn't crankshafted
so they might not be used at all currently.  It could just be a bug in TF, of
course.  Should I figure out the issue before landing this, or land and figure
it out later?

[rossberg, 2014-08-07 15:24:50]

On 2014/08/07 14:59:43, wingo wrote:
> Could it be something about the bailout id's again?  For-of isn't crankshafted
> so they might not be used at all currently.  It could just be a bug in TF, of
> course.  Should I figure out the issue before landing this, or land and figure
> it out later?

TurboFan has no support for ES6 yet, so just blacklist these tests in the
corresponding section of mjsunit.status.

[rossberg, 2014-08-07 15:25:44]

On 2014/08/07 15:24:50, rossberg wrote:
> On 2014/08/07 14:59:43, wingo wrote:
> > Could it be something about the bailout id's again?  For-of isn't
crankshafted
> > so they might not be used at all currently.  It could just be a bug in TF,
of
> > course.  Should I figure out the issue before landing this, or land and
figure
> > it out later?
> 
> TurboFan has no support for ES6 yet, so just blacklist these tests in the
> corresponding section of mjsunit.status.

Or rather, update the names of the black-listed tests. :)

[wingo, 2014-08-07 16:20:50]

Bah, for some reason --harmony-unscopables doesn't work with
--harmony-iteration, so I can't land this patch as it turns on
--harmony-iteration by default.  Before the patch:

/hack/v8/out/x64.debug/d8 --harmony-unscopables --harmony-iteration


#
# Fatal error in ../src/runtime.cc, line 2153
# CHECK((attr & READ_ONLY) == 0) failed
#

==== C stack trace ===============================

 1: V8_Fatal
 2: ??
 3: ??
 4: v8::internal::Runtime_DeclareGlobals(int, v8::internal::Object**,
v8::internal::Isolate*)
 5: ??
Illegal instruction

[wingo, 2014-08-07 16:25:01]

On 2014/08/07 16:20:50, wingo wrote:
> Bah, for some reason --harmony-unscopables doesn't work with
> --harmony-iteration, so I can't land this patch as it turns on
> --harmony-iteration by default.  Before the patch:
> 
> /hack/v8/out/x64.debug/d8 --harmony-unscopables --harmony-iteration
> 
> 
> #
> # Fatal error in ../src/runtime.cc, line 2153
> # CHECK((attr & READ_ONLY) == 0) failed
> #
> 
> ==== C stack trace ===============================
> 
>  1: V8_Fatal
>  2: ??
>  3: ??
>  4: v8::internal::Runtime_DeclareGlobals(int, v8::internal::Object**,
> v8::internal::Isolate*)
>  5: ??
> Illegal instruction

So this turns out to be because of a duplicate declaration of
ExtendArrayPrototype.  Cut and paste hulk stomp stomp!

[wingo, 2014-08-07 16:42:38]

Committed patchset #2 manually as 22980 (presubmit successful).

[arv (Not doing code reviews), 2014-08-07 16:49:07]

On 2014/08/07 at 16:25:01, wingo wrote:

> So this turns out to be because of a duplicate declaration of
ExtendArrayPrototype.  Cut and paste hulk stomp stomp!

Maybe we should stop introducing functions that are just called immediately?

Today:

function Init() {
  var x = ...
  ...
}
Init();

In a year

{
  let x = ...
  ...
}

In a month?

(function Init() {
  var x = ...
  ...
})();

[rossberg, 2014-08-07 17:08:12]

On 2014/08/07 16:49:07, arv wrote:
> Maybe we should stop introducing functions that are just called immediately?

I agree. I'd go for named IIFEs. (I'm somewhat undecided about routinely using
toplevel blocks for tests, since the toplevel is quite special in many regards.
E.g., it will always bypass lazy compilation.)