[fullcodegen] Remove deprecated support for lookup variables, eval and with.

src/ast/ast-numbering.cc

Index: src/ast/ast-numbering.cc
diff --git a/src/ast/ast-numbering.cc b/src/ast/ast-numbering.cc
index 620925406d17883ce231a952933b4b0fcaa9179e..2bdf817bfe783407288b2f6afe166c2672496f1e 100644
--- a/src/ast/ast-numbering.cc
+++ b/src/ast/ast-numbering.cc
@@ -532,6 +532,9 @@ void AstNumberingVisitor::VisitArrayLiteral(ArrayLiteral* node) {
 
 
 void AstNumberingVisitor::VisitCall(Call* node) {
+  if (node->is_possibly_eval()) {
+    DisableFullCodegenAndCrankshaft(kFunctionCallsEval);

[Michael Starzinger, 2016/11/23 10:15:48]

Just out of curiosity, are there cases where this is not covered by the
{scope->calls_eval()} predicate on the overall function literal? Because this
could at first glance indicate a bug in scope analysis.

[rmcilroy, 2016/11/23 13:48:50]

Yeah this didn't work without it. If I remember correctly, it was when an eval
was within a let block scope. The scope->inner_scope_calls_eval() would be set,
but not just scope->calls_eval(). We can't use inner_scope_calls_eval, since
that would also go through function scopes, but I'm assuming the
scope->calls_eval() is only meant to register if that particular scope calls
eval (not inner block or with scopes).

[Michael Starzinger, 2016/11/23 14:11:05]

I briefly talked with Toon about this and he agrees with your assessment and
this is WAI for the scope analysis. I would vote however to remove the check for
{scope->calls_eval()} below in line 593, because it is covered by this new check
and is somewhat confusing IMHO. WDYT?

+  }
   IncrementNodeCount();
   ReserveFeedbackSlots(node);
   node->set_base_id(ReserveIdRange(Call::num_ids()));