dart2js cps: Support function types in 'is' and 'as' operators.

dart2js cps: Support function types in 'is' and 'as' operators.

The generated code uses different helpers than the SSA. In SSA, there are calls to buildFunctionType and _isTest. The CPS uses checkSubtypeOfRuntimeType, the "one size fits all" method we also use to test against type variable types.

When the function type has no type variables in it we could hoist the function type into a constant, but the constant system does not support type representation constants at the moment. But it seems like an optimization we may want to add later.

BUG=
R=karlklose@google.com

Committed: https://github.com/dart-lang/sdk/commit/fb38d61dba779be60a29026a6861430e439db940

[asgerf, 2015-06-17 14:01:48]

asgerf@google.com changed reviewers:
+ karlklose@google.com

[asgerf, 2015-06-17 14:01:49]

https://codereview.chromium.org/1180973003/diff/20001/sdk/lib/_internal/compi...
File sdk/lib/_internal/compiler/js_lib/js_rti.dart (right):

https://codereview.chromium.org/1180973003/diff/20001/sdk/lib/_internal/compi...
sdk/lib/_internal/compiler/js_lib/js_rti.dart:393: if (isDartFunctionType(t)) {
This matters when 'o' is a generic class with a call method being tested against
a function type.

https://codereview.chromium.org/1180973003/diff/20001/tests/compiler/dart2js_...
File tests/compiler/dart2js_native/dart2js_native.status (right):

https://codereview.chromium.org/1180973003/diff/20001/tests/compiler/dart2js_...
tests/compiler/dart2js_native/dart2js_native.status:114:
subclassing_constructor_2_test : RuntimeError # Expect.throws fails: Did not
throw
Something with native classes, unrelated type operators.

https://codereview.chromium.org/1180973003/diff/20001/tests/corelib/corelib.s...
File tests/corelib/corelib.status (right):

https://codereview.chromium.org/1180973003/diff/20001/tests/corelib/corelib.s...
tests/corelib/corelib.status:223: iterable_expand_test : RuntimeError #
TypeError: receiver.get$list is not a function
Seems like an issue with the interceptor calling convention.

Probably related to the issue mentioned in sra's TODO in unsugar.dart.

[karlklose, 2015-06-18 07:45:02]

LGTM, just one question about the change to js_rti.

https://codereview.chromium.org/1180973003/diff/20001/pkg/compiler/lib/src/cp...
File pkg/compiler/lib/src/cps_ir/cps_ir_nodes.dart (right):

https://codereview.chromium.org/1180973003/diff/20001/pkg/compiler/lib/src/cp...
pkg/compiler/lib/src/cps_ir/cps_ir_nodes.dart:387: final
List<Reference<Primitive>> typeArguments;
We should rename this field.  How about 'typeRepresentations'?

https://codereview.chromium.org/1180973003/diff/20001/sdk/lib/_internal/compi...
File sdk/lib/_internal/compiler/js_lib/js_rti.dart (right):

https://codereview.chromium.org/1180973003/diff/20001/sdk/lib/_internal/compi...
sdk/lib/_internal/compiler/js_lib/js_rti.dart:393: if (isDartFunctionType(t)) {
On 2015/06/17 14:01:49, asgerf wrote:
> This matters when 'o' is a generic class with a call method being tested
against

Is this change not affecting the SSA backend because it builds the function type
test objects instead?

[asgerf, 2015-06-18 09:20:38]

https://codereview.chromium.org/1180973003/diff/20001/pkg/compiler/lib/src/cp...
File pkg/compiler/lib/src/cps_ir/cps_ir_nodes.dart (right):

https://codereview.chromium.org/1180973003/diff/20001/pkg/compiler/lib/src/cp...
pkg/compiler/lib/src/cps_ir/cps_ir_nodes.dart:387: final
List<Reference<Primitive>> typeArguments;
On 2015/06/18 07:45:02, karlklose wrote:
> We should rename this field.  How about 'typeRepresentations'?

Well, at least now it makes sense for the InterfaceType case.

https://codereview.chromium.org/1180973003/diff/20001/sdk/lib/_internal/compi...
File sdk/lib/_internal/compiler/js_lib/js_rti.dart (right):

https://codereview.chromium.org/1180973003/diff/20001/sdk/lib/_internal/compi...
sdk/lib/_internal/compiler/js_lib/js_rti.dart:393: if (isDartFunctionType(t)) {
On 2015/06/18 07:45:02, karlklose wrote:
> On 2015/06/17 14:01:49, asgerf wrote:
> > This matters when 'o' is a generic class with a call method being tested
> against
> 
> Is this change not affecting the SSA backend because it builds the function
type
> test objects instead?

For direct checks against a function type, yes.

However, if testing against a type variable holding a function type at runtime,
SSA calls this method and would previously give the wrong answer, but is now
fixed.

I've added a new test case that fails without the change but passes now.

[karlklose, 2015-06-18 09:29:45]

Still LGTM.

[asgerf, 2015-06-18 09:31:02]

Committed patchset #4 (id:60001) manually as
fb38d61dba779be60a29026a6861430e439db940 (presubmit successful).