Fix not throwing error when redefine eval or arguments in strict mode.

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 000b606a9549570b50ca9429633a5d88e6dbbf3f..e42566719daec863ad54678ad64c9042b1861520 100644
--- a/src/parsing/parser-base.h
+++ b/src/parsing/parser-base.h
@@ -1970,7 +1970,7 @@ ParserBase<Traits>::ParsePropertyDefinition(
       CheckDestructuringElement(lhs, classifier, next_beg_pos, next_end_pos);
 
       ExpressionT value;
-      if (peek() == Token::ASSIGN) {
+      if (IsValidReferenceExpression(lhs) && peek() == Token::ASSIGN) {

[Dan Ehrenberg, 2016/07/28 00:13:38]

Does the insertion of IsValidReferenceExpression(lhs) here have any other
effects observable in tests?

         Consume(Token::ASSIGN);
         ExpressionClassifier rhs_classifier(this);
         ExpressionT rhs = this->ParseAssignmentExpression(
@@ -1987,6 +1987,11 @@ ParserBase<Traits>::ParsePropertyDefinition(
 
         Traits::SetFunctionNameFromIdentifierRef(rhs, lhs);
       } else {
+        if (this->IsIdentifier(lhs) && is_strict(language_mode()) &&
+            this->IsEvalOrArguments(this->AsIdentifier(lhs))) {
+          ReportMessageAt(Scanner::Location(next_beg_pos, next_end_pos),

[adamk, 2016/07/28 18:46:55]

I think you should be able to detect this when parsing the identifier. See
ParseAndClassifyIdentifier (and in particular its callers).

ExpressionClassifier is the right way to handle this error; it's the thing we
use to record "speculative" errors, before we know exactly what we're trying to
parse.

Anyway, in pointing to the destructuring assignment tests, I also meant to
suggest looking at how the destructuring assignment case manages to get the
right error (I'd use gdb or printf debugging for that :)

[lpy, 2016/08/05 22:15:41]

Done.

+                          MessageTemplate::kStrictEvalArguments, kSyntaxError);
+        }
         value = lhs;
       }