[parser] Relex restriction on reserved words

test/cctest/test-parsing.cc

 // Copyright 2012 the V8 project authors. All rights reserved.
 // Redistribution and use in source and binary forms, with or without
 // modification, are permitted provided that the following conditions are
 // met:
 //
 //     * Redistributions of source code must retain the above copyright
 //       notice, this list of conditions and the following disclaimer.
 //     * Redistributions in binary form must reproduce the above
 //       copyright notice, this list of conditions and the following
 //       disclaimer in the documentation and/or other materials provided
@@ skipping 1991 matching lines @@
     "var foo = { eval: 1 };",
     "var foo = { arguments: 1 };",
     "var foo = { }; foo.eval = {};",
     "var foo = { }; foo.arguments = {};",
     NULL
   };
 
   RunParserSyncTest(context_data, statement_data, kSuccess);
 }
 
+#define FUTURE_STRICT_RESERVED_WORDS_NO_LET(V) \
+  V(implements)                                \
+  V(interface)                                 \
+  V(package)                                   \
+  V(private)                                   \
+  V(protected)                                 \
+  V(public)                                    \
+  V(static)                                    \
+  V(yield)

[Dan Ehrenberg, 2016/04/20 20:59:56]

I believe all of these extra tests would be valid with 'let' as well, due to the
static semantics early errors for use of let in a lexical binding.

[Dan Ehrenberg, 2016/04/20 21:02:31]

Actually, I see you are using 'no let' for your sloppy mode kSuccess tests. In
this case, have you verified that there is a kError test for 'let' for all of
these cases? For the strict mode error tests, it should not be necessary to use
_NO_LET, however

[mike3, 2016/04/21 19:51:20]

Sure thing, I'll add tests for both cases.

 
 #define FUTURE_STRICT_RESERVED_WORDS(V) \
-  V(implements)                         \
-  V(interface)                          \
   V(let)                                \
-  V(package)                            \
-  V(private)                            \
-  V(protected)                          \
-  V(public)                             \
-  V(static)                             \
+  FUTURE_STRICT_RESERVED_WORDS_NO_LET(V)
+
+#define LIMITED_FUTURE_STRICT_RESERVED_WORDS_NO_LET(V) \
+  V(implements)                                        \
+  V(static)                                            \
   V(yield)
 
-
 #define LIMITED_FUTURE_STRICT_RESERVED_WORDS(V) \
-  V(implements)                                 \
   V(let)                                        \
-  V(static)                                     \
-  V(yield)
-
+  LIMITED_FUTURE_STRICT_RESERVED_WORDS_NO_LET(V)
 
 #define FUTURE_STRICT_RESERVED_STATEMENTS(NAME) \
   "var " #NAME ";",                             \
   "var foo, " #NAME ";",                        \
   "try { } catch (" #NAME ") { }",              \
   "function " #NAME "() { }",                   \
   "(function " #NAME "() { })",                 \
   "function foo(" #NAME ") { }",                \
   "function foo(bar, " #NAME ") { }",           \
   #NAME " = 1;",                                \
   #NAME " += 1;",                               \
   "var foo = " #NAME " = 1;",                   \
   "++" #NAME ";",                               \
   #NAME " ++;",
 
+// clang-format off
+#define FUTURE_STRICT_RESERVED_LET_BINDINGS(NAME) \
+  "let " #NAME ";",                               \
+  "for (let " #NAME "; false; ) {}",              \
+  "for (let " #NAME " in {}) {}",                 \
+  "for (let " #NAME " of []) {}",

[Dan Ehrenberg, 2016/04/20 20:59:56]

For completeness, you can use const for most of these as well, since that has
the same lexical binding rules, right?

[mike3, 2016/04/21 19:51:20]

Acknowledged.

+// clang-format on
 
 TEST(ErrorsFutureStrictReservedWords) {
   // Tests that both preparsing and parsing produce the right kind of errors for
   // using future strict reserved words as identifiers. Without the strict mode,
   // it's ok to use future strict reserved words as identifiers. With the strict
   // mode, it isn't.
   const char* context_data[][2] = {
       {"function test_func() {\"use strict\"; ", "}"},
       {"() => { \"use strict\"; ", "}"},
       {NULL, NULL}};
 
+  // clang-format off
   const char* statement_data[] {
     LIMITED_FUTURE_STRICT_RESERVED_WORDS(FUTURE_STRICT_RESERVED_STATEMENTS)
+    LIMITED_FUTURE_STRICT_RESERVED_WORDS_NO_LET(
+      FUTURE_STRICT_RESERVED_LET_BINDINGS)
     NULL
   };
+  // clang-format on
 
   RunParserSyncTest(context_data, statement_data, kError);
 }
 
-
 #undef LIMITED_FUTURE_STRICT_RESERVED_WORDS
 
 
 TEST(NoErrorsFutureStrictReservedWords) {
   const char* context_data[][2] = {
     { "", "" },
     { "function test_func() {", "}"},
     { "() => {", "}" },
     { NULL, NULL }
   };
 
+  // clang-format off
   const char* statement_data[] = {
     FUTURE_STRICT_RESERVED_WORDS(FUTURE_STRICT_RESERVED_STATEMENTS)
+    FUTURE_STRICT_RESERVED_WORDS_NO_LET(FUTURE_STRICT_RESERVED_LET_BINDINGS)
     NULL
   };
+  // clang-format on
 
   RunParserSyncTest(context_data, statement_data, kSuccess);
 }
 
 
 TEST(ErrorsReservedWords) {
   // Tests that both preparsing and parsing produce the right kind of errors for
   // using future reserved words as identifiers. These tests don't depend on the
   // strict mode.
   const char* context_data[][2] = {
@@ skipping 5132 matching lines @@
     // "Array() **= 10",
     NULL
   };
   // clang-format on
 
   static const ParserFlag always_flags[] = {
       kAllowHarmonyExponentiationOperator};
   RunParserSyncTest(context_data, error_data, kError, NULL, 0, always_flags,
                     arraysize(always_flags));
 }