http://codereview.chromium.org/7616009/diff/1/src/contexts.cc File src/contexts.cc (right):
http://codereview.chromium.org/7616009/diff/1/src/contexts.cc#newcode183 src/contexts.cc:183: case Variable::LET: The context slot for the variable is fixed, but the context isn't. At the moment each iteration will have a separate block context for the loop body, each one having its once instances of block local variables. As for the semantics of freshness of iteration variables, I had the impression that there is no consensus yet :) The specific semantics is not important yet and I think (hope) the implementation doesn't differ that much. On 2011/08/16 11:00:46, Lasse Reichstein wrote:
I was just trying to understand the comment above. If a variable is
assigned a
fixed context slot, there can only be one instance of the variable in
the
context. That doesn't seem to match the behavior of let-inside-loop,
since
multiple instances can be alive at the same time.
On the other hand, this code doesn't seem to care about that, just
that we know
whether the variable is read-only or not, so it's probably fine.
I believe the current consensus about for(let x = ...; ...; ...)... is
that it
declares an implicit block around the for where the let lives (but
for(let x in
...) will use a new instance for each iteration).
http://codereview.chromium.org/7616009/diff/11001/test/mjsunit/harmony/block-scoping.js File test/mjsunit/harmony/block-scoping.js (right): http://codereview.chromium.org/7616009/diff/11001/test/mjsunit/harmony/block-scoping.js#newcode118 test/mjsunit/harmony/block-scoping.js:118: // Variable shadowing. On 2011/08/16 09:49:43, rossberg wrote:
What about shadowing between "var" and "let"?
Done. http://codereview.chromium.org/7616009/diff/11001/test/mjsunit/harmony/block-scoping.js#newcode123 test/mjsunit/harmony/block-scoping.js:123: let b = 2; On 2011/08/16 09:49:43, rossberg wrote:
You might want to put in more assertions (here and below) checking
that lookup
also gives the right binding in all shadowing scenarios.
Done. http://codereview.chromium.org/7616009/diff/11001/test/mjsunit/harmony/block-scoping.js#newcode169 test/mjsunit/harmony/block-scoping.js:169: function f8() { On 2011/08/16 09:49:43, rossberg wrote:
You never invoke this. ;-)
Done. http://codereview.chromium.org/7616009/diff/13014/test/mjsunit/harmony/block-let-declaration.js File test/mjsunit/harmony/block-let-declaration.js (right): http://codereview.chromium.org/7616009/diff/13014/test/mjsunit/harmony/block-let-declaration.js#newcode45 test/mjsunit/harmony/block-let-declaration.js:45: On 2011/08/16 11:00:46, Lasse Reichstein wrote:
Try checking the value of x and y here, just for sanity.
Done. http://codereview.chromium.org/7616009/diff/13014/test/mjsunit/harmony/block-let-declaration.js#newcode51 test/mjsunit/harmony/block-let-declaration.js:51: It's more like checking the parser. On 2011/08/16 11:00:46, Lasse Reichstein wrote:
Notic that these code blocks are executed using a direct call to eval
in
non-strict code - i.e., they use the declaration environment of its
surrounding
code (which is inside a block). If that eval turned into an indirect call (which it REALLY should),
the code
would be global (and no longer throw?).
If you want to explicitly check eval code, wrap a call to eval in a
function
instead of relying on the implementation of assertThrows.
http://codereview.chromium.org/7616009/diff/13014/test/mjsunit/harmony/block-scoping.js File test/mjsunit/harmony/block-scoping.js (right): http://codereview.chromium.org/7616009/diff/13014/test/mjsunit/harmony/block-scoping.js#newcode179 test/mjsunit/harmony/block-scoping.js:179: y = j + 10; On 2011/08/16 11:00:46, Lasse Reichstein wrote:
Should y not just always be 10? And I can't see "j" defined anywhere.
Done. http://codereview.chromium.org/7616009/diff/13014/test/mjsunit/harmony/block-scoping.js#newcode183 test/mjsunit/harmony/block-scoping.js:183: } On 2011/08/16 11:00:46, Lasse Reichstein wrote:
And you don't call f8 (which is why it could be bugged and not fail
:). Done. http://codereview.chromium.org/7616009/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
