dart2js cps: Generate interceptors at use-site and share afterwards.

tests/compiler/dart2js_extra/dart2js_extra.status

Index: tests/compiler/dart2js_extra/dart2js_extra.status
diff --git a/tests/compiler/dart2js_extra/dart2js_extra.status b/tests/compiler/dart2js_extra/dart2js_extra.status
index 32184b0b49d148071f65aaba8ed370fd766adf14..b2d49f99c1e287e2039fecb3bbf8bec1b4039135 100644
--- a/tests/compiler/dart2js_extra/dart2js_extra.status
+++ b/tests/compiler/dart2js_extra/dart2js_extra.status
@@ -70,6 +70,7 @@ invalid_annotation_test/01: MissingCompileTimeError, OK # vm is lazy
 16407_test: Pass # Please triage this failure.
 22868_test: RuntimeError # Issue 23997
 22895_test: RuntimeError # Issue 23997
+23432_test: RuntimeError # Issue 23432

[asgerf, 2015/08/25 14:00:42]

It sort of passed for the wrong reason, and also seems to pass for the wrong
reason in the SSA backend.

[sra1, 2015/08/31 18:12:07]

What is the wrong reason?

[asgerf, 2015/08/31 18:23:05]

Ah, right. I was trying to get to the bottom of things, but then got
side-tracked.

There is a call to getInterceptor that gets a numeric argument, but JSNumber is
not an intercepted class because numbers don't respond to that selector. The
call intentionally fails at runtime.

In CPS, the getInterceptor call returns the number itself, and the resulting
exception message is not rewritten into a nice exception message. It says
something like "getInterceptor(x).blah" is not a method where it was supposed to
say something like "12345 does not have a method blah".

In SSA, the getInterceptor call has a case for UnknownJavaScriptObject which is
only there because the program contains a try/catch. The number is (on purpose?)
classified as such an unknown object. The unknown object's method table then
responds to the message by throwing a nice-looking exception message and passes
the test.

The UnknownJavaScriptObject case seems to go away if there is no try/catch.

I can make SSA generate just as bad error messages by removing all try/catches
from the program, but we can't make a test case for it because it needs a
try/catch to inspect the error message.

I don't know the official strategy for getting nice-looking exception message.
Having the UnknownJavaScriptObject case isn't such a bad idea for handling
negative cases, but the condition under which that happens in the SSA is weird.

 async_stacktrace_test/asyncStar: Crash # (foo()async*{try {tr...  cannot handle sync*/async* functions
 async_stacktrace_test/none: RuntimeError # $async$temp1.Tracer$ is not a function
 closure_capture5_test: Crash # (i=0): For-loop variable captured in loop header