dart2js: Allow 'throw' when inlining

sdk/lib/_internal/compiler/implementation/ssa/nodes.dart

Index: sdk/lib/_internal/compiler/implementation/ssa/nodes.dart
diff --git a/sdk/lib/_internal/compiler/implementation/ssa/nodes.dart b/sdk/lib/_internal/compiler/implementation/ssa/nodes.dart
index c1b9796ec9cbe58f70e8ea5889df11e536d25935..f77aa993e765799e2c6f82456526b7aae3e44227 100644
--- a/sdk/lib/_internal/compiler/implementation/ssa/nodes.dart
+++ b/sdk/lib/_internal/compiler/implementation/ssa/nodes.dart
@@ -64,6 +64,7 @@ abstract class HVisitor<R> {
   R visitSwitch(HSwitch node);
   R visitThis(HThis node);
   R visitThrow(HThrow node);
+  R visitThrowExpression(HThrowExpression node);
   R visitTry(HTry node);
   R visitTypeGuard(HTypeGuard node);
   R visitTypeConversion(HTypeConversion node);
@@ -339,6 +340,7 @@ class HBaseVisitor extends HGraphVisitor implements HVisitor {
   visitStringify(HStringify node) => visitInstruction(node);
   visitThis(HThis node) => visitParameterValue(node);
   visitThrow(HThrow node) => visitControlFlow(node);
+  visitThrowExpression(HThrowExpression node) => visitInstruction(node);
   visitTry(HTry node) => visitControlFlow(node);
   visitTypeGuard(HTypeGuard node) => visitCheck(node);
   visitIs(HIs node) => visitInstruction(node);
@@ -2018,6 +2020,13 @@ class HReturn extends HControlFlow {
   accept(HVisitor visitor) => visitor.visitReturn(this);
 }
 
+class HThrowExpression extends HInstruction {

[karlklose, 2013/04/09 11:58:46]

Shouldn't this extends HControlFlow?

[ngeoffray, 2013/04/10 12:06:39]

Wouldn't it be simpler to have HTrow be treated as an expression in our SSA
nodes?

[erikcorry, 2013/04/10 12:52:32]

I don't think so.

[erikcorry, 2013/04/10 12:52:32]

No, we can't do control flow (closing the block with a throw) inside an
expression because the code generator can't cope.  So we just throw and keep
going (rather like a call to a method that always throws).  But we stop
generating code at the next statement boundary.

If it turns out to be common and cause bloat, we can do the work to handle throw
properly in mid-statement.  I had a patch that worked for 99% of cases, but I
kept finding more corner cases.  It is possible that it would work now that I
fixed https://codereview.chromium.org/13723002/ but I sort of lost patience with
it after being at (what I thought was) 99% for a week or two.

+  HThrowExpression(value) : super(<HInstruction>[value]);
+  toString() => 'throwexpression';
+  accept(HVisitor visitor) => visitor.visitThrowExpression(this);
+  bool canThrow() => true;
+}
+
 class HThrow extends HControlFlow {
   final bool isRethrow;
   HThrow(value, {this.isRethrow: false}) : super(<HInstruction>[value]);