dart2js: fix for https://github.com/dart-lang/sdk/issues/24412

pkg/compiler/lib/src/js_backend/codegen/codegen.dart

Index: pkg/compiler/lib/src/js_backend/codegen/codegen.dart
diff --git a/pkg/compiler/lib/src/js_backend/codegen/codegen.dart b/pkg/compiler/lib/src/js_backend/codegen/codegen.dart
index 44a52470b25c0b98d02415c07023dc87be85e59a..ad7d2141beabe16cd376dd75a2d7adf95bed7cc1 100644
--- a/pkg/compiler/lib/src/js_backend/codegen/codegen.dart
+++ b/pkg/compiler/lib/src/js_backend/codegen/codegen.dart
@@ -639,6 +639,14 @@ class CodeGenerator extends tree_ir.StatementVisitor
 
   @override
   void visitTry(tree_ir.Try node) {
+    void register(ClassElement classElement) {
+      if (classElement == null) return;
+      registry.registerInstantiatedClass(classElement);
+    }
+    // We might catch JavaScript exceptions.
+    register(glue.jsPlainJavaScriptObjectClass);
+    register(glue.jsUnknownJavaScriptObjectClass);

[asgerf, 2015/09/23 19:26:40]

I get that we ought to register these because they can flow into parts of the
system (although not into arbitrary user code, I hope). But why do they affect
interceptors? Do we ever call getInterceptor on a caught JS exception?

If yes, why do we do that when the extra case is so expensive?

If no, why is there a case for these classes in getInterceptor?

It seems to me we should just prohibit dynamic dispatch on this type of value
and let the interceptors focus on values that can flow into user code.

[sra1, 2015/09/24 00:24:45]

I am conflicted about this fix. Real programs need the extra expensive test.
This fix makes a few benchmarks faster than they would be if included in a web
app.  Maybe we should compile all benchmarks in a context that includes
dart:html.


Yes, caught exceptions can flow anywhere:

try {
  ...
} catch (e) {
  print(e);  // We must not fail to find a toString$0 method.
}

'...' could do anything since we use JS(...) in the runtime libraries. We try to
translate the JavaScript exception to a Dart exception but we don't always
succeed in recognizing obscure errors from various browsers.

The expensive 'x instanceof P.Object' test is needed in the interceptors when we
have native JavaScript objects (i.e. every web app) since we must not try to
interpret Dart objects as the JavaScript objects that represent them.

The cost of interceptors is why I suggest whole-program optimizations like
https://github.com/dart-lang/sdk/issues/23686
We are making rapid progress towards a kind of JavaScript interop where the
JavaScript values can flow unwrapped everywhere, and almost every web app will
use the interop to access some JavaScript libraries.

+
     js.Block tryBlock = buildBodyBlock(node.tryBody);
     tree_ir.Variable exceptionVariable = node.catchParameters.first;
     js.VariableDeclaration exceptionParameter =