Raise SyntaxError on let [ starting an ExpressionStatement

src/parsing/parser-base.h

Index: src/parsing/parser-base.h
diff --git a/src/parsing/parser-base.h b/src/parsing/parser-base.h
index 9809071d4789a58da84abfd32420688e0fd2a038..7871ab01483c9b602ae6f9fd90afb9315a7b61a1 100644
--- a/src/parsing/parser-base.h
+++ b/src/parsing/parser-base.h
@@ -4996,6 +4996,12 @@ ParserBase<Impl>::ParseExpressionOrLabelledStatement(
       ReportUnexpectedToken(Next());
       *ok = false;
       return impl()->NullStatement();
+    case Token::LET:
+      if (PeekAhead() != Token::LBRACK) break;
+      impl()->ReportMessageAt(scanner()->peek_location(),
+                              MessageTemplate::kUnexpectedTokenLetLBrack);
+      *ok = false;
+      return impl()->NullStatement();
     default:
       break;
   }
@@ -5446,6 +5452,13 @@ typename ParserBase<Impl>::StatementT ParserBase<Impl>::ParseForStatement(
 
   StatementT init = impl()->NullStatement();
 
+  // "let [" is forbidden in the initializer of the for loop.
+  if (peek() == Token::LET && PeekAhead() == Token::LBRACK) {
+    impl()->ReportMessageAt(scanner()->peek_location(),
+                            MessageTemplate::kUnexpectedTokenLetLBrack);
+    *ok = false;
+    return init;
+  }

[Dan Ehrenberg, 2017/02/13 19:26:57]

I'm not sure I agree with your reading of the specification. Yes, the case Andre
mentioned (which you handled above, and which seems good to me AFAICT) is
prohibited, but I think the negative lookahead in IterationStatement is more for
disambiguation, so that "let [" is forced to be parsed as part of a
LexicalDeclaration rather than an Expression (otherwise, there's ambiguity and
lookahead would have to continue further). I believe this disagreement is what's
causing your test failures.

[vabr (Chromium), 2017/02/13 20:14:46]

The test failures are due to not restricting this check to for(;;) (as opposed
to for-each and for-in).

If the parser gets here, the attempt to parse the "let [" as LexicalDeclaration
has already failed (see ParseStatementListItem).

[vabr (Chromium), 2017/02/13 20:29:20]

Hm, now I see how I misunderstood your comment and mixed my observation about
the ExpressionStatement case.

Let me think about this a little more, I will update the CL with the next
proposal (which might be to restrict this change just to address the
ExpressionStatement case).

   if (peek() == Token::VAR || peek() == Token::CONST ||
       (peek() == Token::LET && IsNextLetKeyword())) {
     // The initializer contains declarations.