http://codereview.chromium.org/7983006/diff/1/src/preparser.cc File src/preparser.cc (right):
http://codereview.chromium.org/7983006/diff/1/src/preparser.cc#newcode394 src/preparser.cc:394: (!strict_mode() || !expr.AsIdentifier().IsFutureReserved())) { While we are already here. This check is off right? In normal mode we should disallow FutureReserved Keywords but allow all other identifiers and further in strict mode disallow FutureStrictReserved In particular eval and arguments are allowed in both modes. Do you agree? http://codereview.chromium.org/7983006/diff/1/src/preparser.cc#newcode396 src/preparser.cc:396: return ParseStatement(CHECK_OK); Yes. This is closely following the spec. We have LabelledStatement :: Identifer : Statement and we disallow function declarations as statements in strict mode. On 2011/09/21 10:29:34, Lasse Reichstein wrote:
So this is how we allow function declarations in all blocks, but not
after a
label in strict mode?
http://codereview.chromium.org/7983006/diff/1/src/preparser.cc#newcode396 src/preparser.cc:396: return ParseStatement(CHECK_OK); On 2011/09/21 10:29:34, Lasse Reichstein wrote:
CHECK_OK -> ok We won't be checking the result after the return anyway.
Done. http://codereview.chromium.org/7983006/diff/1/test/mjsunit/harmony/block-let-declaration.js File test/mjsunit/harmony/block-let-declaration.js (right): http://codereview.chromium.org/7983006/diff/1/test/mjsunit/harmony/block-let-declaration.js#newcode51 test/mjsunit/harmony/block-let-declaration.js:51: assertThrows("(function(){" + str + "})()", expect); Yes they are early errors. Done. On 2011/09/21 10:29:34, Lasse Reichstein wrote:
If this is early errors (and I guess it is), you shouldn't call the
generated
function. It should fail even if the function is never compiled.
http://codereview.chromium.org/7983006/diff/1/test/mjsunit/harmony/block-let-declaration.js#newcode55 test/mjsunit/harmony/block-let-declaration.js:55: assertDoesNotThrow("(function(){" + str + "})()"); On 2011/09/21 10:29:34, Lasse Reichstein wrote:
But keep the call here. It should never fail, not even if compiled
lazily. Done. http://codereview.chromium.org/7983006/diff/1/test/mjsunit/harmony/block-let-declaration.js#newcode79 test/mjsunit/harmony/block-let-declaration.js:79: // non-strict statement positions. Indeed the harmony proposals actually take the ES5 strict mode as a base, so in general yes it should be all strict mode code and ultimately we should do that. For now I have refrained from doing that yet and just added it orthogonally so that I can use some features from ES5 normal mode for test cases (notably forcing dynamic lookups using 'with'). On 2011/09/21 10:29:34, Lasse Reichstein wrote:
Can you have a non-strict statement position in harmony-block-scoping
mode?
I would assume that any harmony enabling flag would make everything
strict mode
code (or if not, perhaps it should?)
http://codereview.chromium.org/7983006/diff/1/test/mjsunit/harmony/block-let-declaration.js#newcode103 test/mjsunit/harmony/block-let-declaration.js:103: } On 2011/09/21 10:29:34, Lasse Reichstein wrote:
Call f here, to ensure that it isn't lazily compiled and throws at
runtime. Done. http://codereview.chromium.org/7983006/ -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev
