Handle malformed types in catch-on.

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

 // Copyright (c) 2012, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 part of ssa;
 
 /**
  * A special element for the extra parameter taken by intercepted
  * methods. We need to override [Element.computeType] because our
  * optimizers may look at its declared type.
@@ skipping 4433 matching lines @@
 
       pushInvokeHelper1(backend.getExceptionUnwrapper(), exception);
       HInvokeStatic unwrappedException = pop();
       tryInstruction.exception = exception;
       Link<Node> link = node.catchBlocks.nodes;
 
       void pushCondition(CatchBlock catchBlock) {
         if (catchBlock.onKeyword != null) {
           DartType type = elements.getType(catchBlock.type);
           if (type == null) {
-            compiler.cancel('On with unresolved type',
+            compiler.cancel('On with no type',

[ngeoffray, 2013/02/05 09:43:46]

Fits in one line?

[Johnni Winther, 2013/02/18 14:51:43]

Done.

                             node: catchBlock.type);
           }
-          HInstruction condition =
-              new HIs(type, <HInstruction>[unwrappedException]);
-          push(condition);
+          if (type.isMalformed) {
+            HInstruction condition =
+                graph.addConstantBool(false, constantSystem);

[ngeoffray, 2013/02/05 09:43:46]

Fits in one line?

[Johnni Winther, 2013/02/18 14:51:43]

:( No.

+            stack.add(condition);

[ahe, 2013/02/05 09:58:39]

Am I understanding this correctly: the specification say that using a malformed
type in a type test always returns false. It doesn't lead to an exception.

However, in checked mode, an exception often occur, but that is the implicit
type assertion as part of assignment, return, and parameter type checks.

[karlklose, 2013/02/05 10:21:45]

Shouldn't we treat any malformed type as dynamic and returning true here?

In checked mode, I think this counts as a subtype test and we have to create a
dynamic type error.

13.2: "In checked mode, it is a dynamic type error if a malformed type is used
in a subtype test. In production mode, an undeclared type is treated as an
instance of type dynamic."

+          } else {
+            HInstruction condition =
+                new HIs(type, <HInstruction>[unwrappedException]);
+            push(condition);
+          }
         }
         else {
           VariableDefinitions declaration = catchBlock.formals.nodes.head;
           HInstruction condition = null;
           if (declaration.type == null) {
             condition = graph.addConstantBool(true, constantSystem);
             stack.add(condition);
           } else {
             // TODO(aprelev@gmail.com): Once old catch syntax is removed
             // "if" condition above and this "else" branch should be deleted as
@@ skipping 531 matching lines @@
           new HSubGraphBlockInformation(elseBranch.graph));
 
     HBasicBlock conditionStartBlock = conditionBranch.block;
     conditionStartBlock.setBlockFlow(info, joinBlock);
     SubGraph conditionGraph = conditionBranch.graph;
     HIf branch = conditionGraph.end.last;
     assert(branch is HIf);
     branch.blockInformation = conditionStartBlock.blockFlow;
   }
 }