dart2dart: Implementation of simple try/catch.

pkg/compiler/lib/src/cps_ir/cps_ir_nodes.dart

Index: pkg/compiler/lib/src/cps_ir/cps_ir_nodes.dart
diff --git a/pkg/compiler/lib/src/cps_ir/cps_ir_nodes.dart b/pkg/compiler/lib/src/cps_ir/cps_ir_nodes.dart
index d1f51fcadabcd01738f0f0f8957c1e78c8f09fc7..4f0b61167accc1343cd7b74d2b8712ac319163c5 100644
--- a/pkg/compiler/lib/src/cps_ir/cps_ir_nodes.dart
+++ b/pkg/compiler/lib/src/cps_ir/cps_ir_nodes.dart
@@ -154,6 +154,26 @@ class LetCont extends Expression implements InteriorNode {
   accept(Visitor visitor) => visitor.visitLetCont(this);
 }
 
+// Binding an exception handler.

[karlklose, 2015/02/16 10:15:48]

Make this a DartDoc comment ('///'), and maybe put the TODO outside in a normal
comment.

[Kevin Millikin (Google), 2015/02/24 11:59:25]

OK.  But I'll just address the TODO before submitting, it was a "draft" TODO :)

+//
+// let handler h(v0 ...) = E0 in E1
+//
+// The handler is a continuation which is implicitly the error continuation of
+// all the code in its body E1.  The handler parameters represent the
+// exception and possibly the stack trace.  (TODO(kmillikin): should we just
+// ensure that they always have two parameters?)  It differs from let cont
+// binding a call continuation in that it (1) has the runtime semantics of
+// pushing/popping a handler from the dynamic exception handler stack and
+// (2) it does not have explicit invocations.
+class LetHandler extends Expression implements InteriorNode {
+  Continuation handler;
+  Expression body;
+
+  LetHandler(this.handler, this.body);
+
+  accept(Visitor visitor) => visitor.visitLetHandler(this);
+}
+
 /// Binding mutable variables.
 ///
 /// let mutable v = P in E
@@ -869,6 +889,7 @@ abstract class Visitor<T> {
   // Expressions.
   T visitLetPrim(LetPrim node) => visitExpression(node);
   T visitLetCont(LetCont node) => visitExpression(node);
+  T visitLetHandler(LetHandler node) => visitExpression(node);
   T visitLetMutable(LetMutable node) => visitExpression(node);
   T visitInvokeStatic(InvokeStatic node) => visitExpression(node);
   T visitInvokeContinuation(InvokeContinuation node) => visitExpression(node);
@@ -981,6 +1002,13 @@ abstract class RecursiveVisitor extends Visitor {
     visit(node.body);
   }
 
+  processLetHandler(LetHandler node) {}
+  visitLetHandler(LetHandler node) {
+    processLetHandler(node);
+    visit(node.handler);
+    visit(node.body);
+  }
+
   processLetMutable(LetMutable node) {}
   visitLetMutable(LetMutable node) {
     processLetMutable(node);
@@ -1275,6 +1303,18 @@ class RegisterAllocator extends Visitor {
     visit(node.body);
   }
 
+  void visitLetHandler(LetHandler node) {
+    visit(node.handler);
+    // Assign indices to unused handler parameters, because they should
+    // not be eliminated.  Then release all of them because they are not
+    // live in the try block.
+    node.handler.parameters.forEach((p) {

[floitsch, 2015/02/16 14:54:07]

We tend to type (even for closures) and not to abbreviate.

[Kevin Millikin (Google), 2015/02/24 11:59:25]

Done.

+      allocate(p);
+      release(p);

[floitsch, 2015/02/16 14:54:07]

I'm not sure I understand (even with the comment). Maybe create a function that
does the combination and has a clearer name?

[Kevin Millikin (Google), 2015/02/24 11:59:25]

The clearest name I can think of is "AllocateThenRelease" :)  I think a comment
here would have to describe both this algorithm and also what we do with the
result to make sense, and this doesn't seem like the right place for that.

We probably just need comments for functions allocate and release.

====
What's happening here is that this is a backward pass over the CPS term and it
assigns indexes to used variables when it sees their last use, then releases
those indexes when it passes their definitions (moving backwards) because the
index can be used for another variable whose last use occurs before this one's
definition.

Variables that don't get assigned an index must not have had any uses, and so
they are eliminated from the output.

So: after visiting the catch block, if the catch parameters are unused they
still need to be assigned indexes to ensure that they are not eliminated.  And
in any case, they need to be released so that their index can be possibly
reused.

I've rewritten the comment, it's longer but I'm not sure it's any better.

+    });
+    visit(node.body);
+  }
+
   void visitLetMutable(LetMutable node) {
     visit(node.body);
     visitReference(node.value);