Add flag for disallowing for-in initializers

src/parsing/parser.cc

Index: src/parsing/parser.cc
diff --git a/src/parsing/parser.cc b/src/parsing/parser.cc
index e2e8f92ad9f922a5838b96ddea114da2c24e5c79..452b0ef30029a5bfc0665b99f2d800518b2a3030 100644
--- a/src/parsing/parser.cc
+++ b/src/parsing/parser.cc
@@ -3500,6 +3500,14 @@ Statement* Parser::ParseForStatement(ZoneList<const AstRawString*>* labels,
         if (!IsLexicalVariableMode(parsing_result.descriptor.mode) &&
             decl.pattern->IsVariableProxy() && decl.initializer != nullptr) {
           ++use_counts_[v8::Isolate::kForInInitializer];
+          if (FLAG_harmony_for_in) {

[nickie, 2016/04/22 11:22:56]

Shouldn't a similar thing be added to the preparser?

[rossberg, 2016/04/22 11:34:50]

Yes, normally it should. However, we'd lose use counts if we already rejected it
in the preparser. So I'm inclined to leave it like that as a temporary measure.
I added a TODO comment explaining this.

[adamk, 2016/04/22 17:28:18]

This inconsistency seems like it'll cause us some headaches if people actually
start reporting bugs about this feature. You could instead add a bit of API to
the ParserRecorder and copy that over to the use_counts_ in
ParseLazyFunctionBodyWithPreParser. If you feel that's too complex for this
feature, than I'd rather lose the UseCounter data then have this inconsistency
in behavior.

+            ParserTraits::ReportMessageAt(
+                parsing_result.first_initializer_loc,
+                MessageTemplate::kForInOfLoopInitializer,
+                ForEachStatement::VisitModeString(mode));
+            *ok = false;
+            return nullptr;
+          }
           const AstRawString* name =
               decl.pattern->AsVariableProxy()->raw_name();
           VariableProxy* single_var = scope_->NewUnresolved(