[Interpreter] Add function literal support.

src/interpreter/bytecode-generator.cc

Index: src/interpreter/bytecode-generator.cc
diff --git a/src/interpreter/bytecode-generator.cc b/src/interpreter/bytecode-generator.cc
index 0e7d44dca9afad891fb508f6baabe937c3647061..3ea9e088786b2e8402b0fea52d85dc23e0513e58 100644
--- a/src/interpreter/bytecode-generator.cc
+++ b/src/interpreter/bytecode-generator.cc
@@ -445,7 +445,14 @@ void BytecodeGenerator::VisitDebuggerStatement(DebuggerStatement* stmt) {
 
 
 void BytecodeGenerator::VisitFunctionLiteral(FunctionLiteral* expr) {
-  UNIMPLEMENTED();
+  // Find or build a shared function info.
+  Handle<SharedFunctionInfo> shared_info =
+      Compiler::GetSharedFunctionInfo(expr, info()->script(), info());
+  CHECK(!shared_info.is_null());  // TODO(rmcilroy): Set stack overflow?

[Michael Starzinger, 2015/10/09 13:19:00]

Yeah, that same check in the AstGraphBuilder bothers me every time I see it. I
finally need to dig into whether this can ever happen, and if so, write a repro
for that. Let me know if it ever happens to hit you, I'd be interested. :)

[rmcilroy, 2015/10/12 17:00:15]

Yeah I've never seen this myself. I'll let you know if I ever hit it.

+
+  builder()
+      ->LoadLiteral(shared_info)
+      .CreateClosure(expr->pretenure() ? TENURED : NOT_TENURED);
 }
 
 
@@ -730,10 +737,15 @@ void BytecodeGenerator::VisitCall(Call* expr) {
       builder()->StoreAccumulatorInRegister(callee);
       break;
     }
+    case Call::OTHER_CALL: {
+      Visit(callee_expr);
+      builder()->StoreAccumulatorInRegister(callee);
+      builder()->LoadUndefined().StoreAccumulatorInRegister(receiver);

[Michael Starzinger, 2015/10/09 13:19:00]

nit: I don't think it matters much, since we don't have any deoptimization yet,
but could we store the receiver before we evaluate the {callee_expr}? Or is
there a particular reason for this order? It shouldn't matter but I would feel
more comfortable setting the receiver register first.

[Michael Starzinger, 2015/10/09 13:28:01]

Actually, I just checked again and we already in full-codegen don't have the
receiver on the operand stack here. So my comment is completely without basis.
Please disregard, sorry for the noise.

[rmcilroy, 2015/10/12 17:00:15]

It doesn't actually matter which way round this goes, I was just following the
evaluation order of ASTGraphBuilder which does it. Swapped it around in any
case.

+      break;
+    }
     case Call::LOOKUP_SLOT_CALL:
     case Call::SUPER_CALL:
     case Call::POSSIBLY_EVAL_CALL:
-    case Call::OTHER_CALL:
       UNIMPLEMENTED();
   }