Let bound iteration variables in for-loops

Let bound iteration variables in for-loops

TEST=mjsunit/harmony/block-for.js

Committed: http://code.google.com/p/v8/source/detail?r=9658

[Steven, 2011-09-07 13:45:47]

PTAL.

[Steven, 2011-10-17 10:59:50]

I rebased this on
http://codereview.chromium.org/8306025/
to include all the recent changes. Could you please take a look.

[Lasse Reichstein, 2011-10-17 11:49:40]

LGTM

http://codereview.chromium.org/7837028/diff/6017/src/parser.cc
File src/parser.cc (right):

http://codereview.chromium.org/7837028/diff/6017/src/parser.cc#newcode2437
src/parser.cc:2437: // TODO(keuchel): move temporary variable to block scope
What does this mean? Is the current code not correct, or is this just an
optimization?
(and remember '.' at end of sentences :).

http://codereview.chromium.org/7837028/diff/6017/test/mjsunit/harmony/block-f...
File test/mjsunit/harmony/block-for.js (right):

http://codereview.chromium.org/7837028/diff/6017/test/mjsunit/harmony/block-f...
test/mjsunit/harmony/block-for.js:36: assertEquals(0, props({}).length,
"olen0");
You can safely choose to omit the third parameter of the test without loss since
our test framework reports the line now.

http://codereview.chromium.org/7837028/diff/6017/test/mjsunit/harmony/block-f...
test/mjsunit/harmony/block-for.js:54: for (let i = 0x0020; i < 0x01ff; i+=2) {
Try declaring i and s prior to this loop, and see that their values haven't
changed afterwards.

[Steven, 2011-10-17 12:18:29]

http://codereview.chromium.org/7837028/diff/6017/src/parser.cc
File src/parser.cc (right):

http://codereview.chromium.org/7837028/diff/6017/src/parser.cc#newcode2437
src/parser.cc:2437: // TODO(keuchel): move temporary variable to block scope
This is an optimization. TEMPORARY variables are always stack allocated, so I
can only change this after I land my code for stack allocating block scoped
variables. Will adapt the comment for now.
On 2011/10/17 11:49:40, Lasse Reichstein wrote:
> What does this mean? Is the current code not correct, or is this just an
> optimization?
> (and remember '.' at end of sentences :).

http://codereview.chromium.org/7837028/diff/6017/test/mjsunit/harmony/block-f...
File test/mjsunit/harmony/block-for.js (right):

http://codereview.chromium.org/7837028/diff/6017/test/mjsunit/harmony/block-f...
test/mjsunit/harmony/block-for.js:36: assertEquals(0, props({}).length,
"olen0");
On 2011/10/17 11:49:40, Lasse Reichstein wrote:
> You can safely choose to omit the third parameter of the test without loss
since
> our test framework reports the line now.

Done.

http://codereview.chromium.org/7837028/diff/6017/test/mjsunit/harmony/block-f...
test/mjsunit/harmony/block-for.js:54: for (let i = 0x0020; i < 0x01ff; i+=2) {
On 2011/10/17 11:49:40, Lasse Reichstein wrote:
> Try declaring i and s prior to this loop, and see that their values haven't
> changed afterwards.

Done.