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())) { Actually we do follow ES5 already and for labelled statements disallow the correct sets of FutureReservedWords in both modes as specified in clause 7.6.1.2. I was just confused by this check because it did not make the distinction between always FutureReservedWords and the ones that are only reserved in strict mode. The check is actually redundant because Parse(Primary)Expression will already disallow the usage. In fact I can use the following assertions if (expr.IsRawIdentifier()) { ASSERT(!expr.AsIdentifier().IsFutureReserved()); ASSERT(!strict_mode() || !expr.AsIdentifier().IsFutureStrictReserved()); [...] The file preparser/strict-identifiers.pyt does not yet include tests for checking the identifier used in labelled statements, break or continue. And indeed the implementations of break and continue both do not check the parsed identifier, because clearly they use ParseIdentifier directly and not ParseExpression. On 2011/09/21 20:11:45, Lasse Reichstein wrote:
We "should" disallow FutureReserved in non-strict mode, but we don't.
It's a
legacy thing - we can't start making future-reserved words an error
now without
breaking code that uses them. We block keywords in both modes (expr.IsRawIdentifier() returns false
on
keywords), and future reserved words in strict mode. Both "eval" and "arguments" are allowed in both modes, since they are
raw
identifiers and not future reserved words. I.e., I believe the code does the right thing.
There is an extensive unit-test suite for the preparser. Do check if
this needs
to be covered better.
http://codereview.chromium.org/7983006/ -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev
