Fix bug with spread rewriting

Fix bug with spread rewriting

It was not properly rewriting three cases:

-   [...[42]][0]
-   [...[42]].length
-   [...[42]] `foo`    (which is a type error)

R=rossberg@chromium.org
BUG=v8:4696
LOG=N

Committed: https://crrev.com/52a01ae0c7db3054e92275db048213d2cec81dae
Cr-Commit-Position: refs/heads/master@{#33433}

[rossberg, 2016-01-21 11:51:25]

Description was changed from

==========
Fix bug with spread rewriting

It was not properly rewriting three cases:

-   [...[42]][0]
-   [...[42]].length
-   [...[42]] `foo`    (which is a type error)

R=rossberg@chromium.org
BUG=v8:4696
LOG=N
==========

to

==========
Fix bug with spread rewriting

It was not properly rewriting three cases:

-   [...[42]][0]
-   [...[42]].length
-   [...[42]] `foo`    (which is a type error)

R=rossberg@chromium.org
BUG=v8:4696
LOG=N
==========

[rossberg, 2016-01-21 11:52:07]

lgtm

[nickie, 2016-01-21 11:52:45]

The CQ bit was checked by nikolaos@chromium.org

[commit-bot: I haz the power, 2016-01-21 11:52:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1617713002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1617713002/1

[commit-bot: I haz the power, 2016-01-21 12:15:33]

Description was changed from

==========
Fix bug with spread rewriting

It was not properly rewriting three cases:

-   [...[42]][0]
-   [...[42]].length
-   [...[42]] `foo`    (which is a type error)

R=rossberg@chromium.org
BUG=v8:4696
LOG=N
==========

to

==========
Fix bug with spread rewriting

It was not properly rewriting three cases:

-   [...[42]][0]
-   [...[42]].length
-   [...[42]] `foo`    (which is a type error)

R=rossberg@chromium.org
BUG=v8:4696
LOG=N
==========

[commit-bot: I haz the power, 2016-01-21 12:15:33]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-01-21 12:16:27]

Description was changed from

==========
Fix bug with spread rewriting

It was not properly rewriting three cases:

-   [...[42]][0]
-   [...[42]].length
-   [...[42]] `foo`    (which is a type error)

R=rossberg@chromium.org
BUG=v8:4696
LOG=N
==========

to

==========
Fix bug with spread rewriting

It was not properly rewriting three cases:

-   [...[42]][0]
-   [...[42]].length
-   [...[42]] `foo`    (which is a type error)

R=rossberg@chromium.org
BUG=v8:4696
LOG=N

Committed: https://crrev.com/52a01ae0c7db3054e92275db048213d2cec81dae
Cr-Commit-Position: refs/heads/master@{#33433}
==========

[commit-bot: I haz the power, 2016-01-21 12:16:27]

Patchset 1 (id:??) landed as
https://crrev.com/52a01ae0c7db3054e92275db048213d2cec81dae
Cr-Commit-Position: refs/heads/master@{#33433}

[Michael Achenbach, 2016-01-21 14:40:49]

Could this CL be the reason for the exceeded stack here:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20gcov%20cov...
? Can be that it's benign and we should simply skip the test on the gcov bot.

[nickie, 2016-01-21 15:15:36]

On 2016/01/21 14:40:49, Michael Achenbach wrote:
> Could this CL be the reason for the exceeded stack here:
>
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20gcov%20cov...
> ? Can be that it's benign and we should simply skip the test on the gcov bot.

This particular CL is almost certainly not the cause of this problem.  The AST
traversal that takes place for spread desugaring after 1564083002 could be the
cause of C++ stack overflows in the case of deeply nested array literals, not JS
stack overflows.

[Michael Achenbach, 2016-01-21 15:28:01]

On 2016/01/21 15:15:36, nickie wrote:
> On 2016/01/21 14:40:49, Michael Achenbach wrote:
> > Could this CL be the reason for the exceeded stack here:
> >
>
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20gcov%20cov...
> > ? Can be that it's benign and we should simply skip the test on the gcov
bot.
> 
> This particular CL is almost certainly not the cause of this problem.  The AST
> traversal that takes place for spread desugaring after 1564083002 could be the
> cause of C++ stack overflows in the case of deeply nested array literals, not
JS
> stack overflows.

Local repro says differently. Repro's to this CL. Still, maybe it's due to the
gcov instrumentation and a tiny change in stack size - in which case we could
just skip the test.

[rossberg, 2016-01-21 15:36:12]

On 2016/01/21 15:28:01, Michael Achenbach wrote:
> On 2016/01/21 15:15:36, nickie wrote:
> > On 2016/01/21 14:40:49, Michael Achenbach wrote:
> > > Could this CL be the reason for the exceeded stack here:
> > >
> >
>
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20gcov%20cov...
> > > ? Can be that it's benign and we should simply skip the test on the gcov
> bot.
> > 
> > This particular CL is almost certainly not the cause of this problem.  The
AST
> > traversal that takes place for spread desugaring after 1564083002 could be
the
> > cause of C++ stack overflows in the case of deeply nested array literals,
not
> JS
> > stack overflows.
> 
> Local repro says differently. Repro's to this CL. Still, maybe it's due to the
> gcov instrumentation and a tiny change in stack size - in which case we could
> just skip the test.

Yes, I can only explain this as a secondary effect. We should just disable the
test on that bot (or adjust it, if we care enough about this build?).