Detect conflicting variable bindings in harmony mode.

src/ia32/full-codegen-ia32.cc

Index: src/ia32/full-codegen-ia32.cc
diff --git a/src/ia32/full-codegen-ia32.cc b/src/ia32/full-codegen-ia32.cc
index 253387f42d5346e1a14cf49f040401486af88c39..1250e6b0dd4bd384887fcd7db8504c6d3bd21477 100644
--- a/src/ia32/full-codegen-ia32.cc
+++ b/src/ia32/full-codegen-ia32.cc
@@ -2158,8 +2158,13 @@ void FullCodeGenerator::EmitResolvePossiblyDirectEval(ResolveEvalFlag flag,
   // Push the receiver of the enclosing function.
   __ push(Operand(ebp, (2 + info_->scope()->num_parameters()) * kPointerSize));
 
-  // Push the strict mode flag.
-  __ push(Immediate(Smi::FromInt(strict_mode_flag())));
+  // Push the strict mode flag. In harmony mode every eval call
+  // is a strict mode eval call.

[Lasse Reichstein, 2011/09/01 07:34:04]

How come this invariant isn't shown in the strict_mode_flag to begin with? I.e.,
should strict_mode_flag be able to return anything but kStrictMode in Harmony
mode?

[Steven, 2011/09/01 15:01:33]

In fact, harmony mode should be an extension of the strict mode, so that we
could set that in strict_mode_flag() and assume strict mode semantics
everywhere. However, then we would have to do the same for the parser for
consistency. Andreas and I agreed that we would want to make the impact of new
features on existing functionality as small as possible if it does not
complicate things. Leaking
var declarations from 'eval' is nasty so we would want to disallow that.
On 2011/09/01 07:34:04, Lasse Reichstein wrote:

+  StrictModeFlag strict_mode = strict_mode_flag();
+  if (FLAG_harmony_block_scoping) {
+    strict_mode = kStrictMode;
+  }
+  __ push(Immediate(Smi::FromInt(strict_mode)));
 
   __ CallRuntime(flag == SKIP_CONTEXT_LOOKUP
                  ? Runtime::kResolvePossiblyDirectEvalNoLookup