dart2js: Make .runtimeType work for tear-off closures

dart2js: Make .runtimeType work for tear-off closures

BUG=
R=sigmund@google.com

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

[sra1, 2017-01-18 03:24:44]

sra@google.com changed reviewers:
+ sigmund@google.com

[karlklose, 2017-01-18 07:13:15]

On 2017/01/18 03:24:44, sra1 wrote:

If this was not working before, could you add a regression test? Or are there
status file changes?

[Siggi Cherem (dart-lang), 2017-01-18 17:40:44]

lgtm, I agree with Karl, it would be great to add a small unit test for closure
tear-offs .runtimeType

https://codereview.chromium.org/2639733004/diff/20001/sdk/lib/_internal/js_ru...
File sdk/lib/_internal/js_runtime/lib/js_rti.dart (right):

https://codereview.chromium.org/2639733004/diff/20001/sdk/lib/_internal/js_ru...
sdk/lib/_internal/js_runtime/lib/js_rti.dart:199: returnTypeText =
runtimeTypeToString(returnRti, onTypeVariable: onTypeVariable);
nit: long line (maybe run dartfmt?) and below

[sra1, 2017-01-19 00:09:20]

PTAL

1. Changed format to the same as VM to enable one test to pass.
2. Added another test.

https://codereview.chromium.org/2639733004/diff/20001/sdk/lib/_internal/js_ru...
File sdk/lib/_internal/js_runtime/lib/js_rti.dart (right):

https://codereview.chromium.org/2639733004/diff/20001/sdk/lib/_internal/js_ru...
sdk/lib/_internal/js_runtime/lib/js_rti.dart:199: returnTypeText =
runtimeTypeToString(returnRti, onTypeVariable: onTypeVariable);
On 2017/01/18 17:40:44, Siggi Cherem (dart-lang) wrote:
> nit: long line (maybe run dartfmt?) and below

Done.

[Siggi Cherem (dart-lang), 2017-01-19 00:33:03]

lgtm!

[sra1, 2017-01-19 01:42:01]

Description was changed from

==========
dart2js: Make .runtimeType work for tear-off closures

BUG=
==========

to

==========
dart2js: Make .runtimeType work for tear-off closures

BUG=
R=sigmund@google.com

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

[sra1, 2017-01-19 01:42:02]

Committed patchset #5 (id:80001) manually as
fdbc6688f1c61a725cad019c98f543db773d01ae (presubmit successful).

[Emily Fortuna, 2017-01-20 20:02:26]

On 2017/01/19 01:42:02, sra1 wrote:
> Committed patchset #5 (id:80001) manually as
> fdbc6688f1c61a725cad019c98f543db773d01ae (presubmit successful).

This CL caused language/generic_closure_test to start failing when you run it
with kernel: 
python tools/test.py -mrelease -cdart2js -rd8 --host-checked --dart2js-options
--use-kernel language/generic_closure_test

was that intended?

[sra1, 2017-01-20 21:11:07]

On 2017/01/20 20:02:26, Emily Fortuna wrote:
> On 2017/01/19 01:42:02, sra1 wrote:
> > Committed patchset #5 (id:80001) manually as
> > fdbc6688f1c61a725cad019c98f543db773d01ae (presubmit successful).
> 
> This CL caused language/generic_closure_test to start failing when you run it
> with kernel: 
> python tools/test.py -mrelease -cdart2js -rd8 --host-checked --dart2js-options
> --use-kernel language/generic_closure_test
> 
> was that intended?

Very strange.
If I run the tests before and after I see what you see, but if I run test and
then repeat the d8 step, both fail.

[sra1, 2017-01-20 21:12:42]

On 2017/01/20 21:11:07, sra1 wrote:
> On 2017/01/20 20:02:26, Emily Fortuna wrote:
> > On 2017/01/19 01:42:02, sra1 wrote:
> > > Committed patchset #5 (id:80001) manually as
> > > fdbc6688f1c61a725cad019c98f543db773d01ae (presubmit successful).
> > 
> > This CL caused language/generic_closure_test to start failing when you run
it
> > with kernel: 
> > python tools/test.py -mrelease -cdart2js -rd8 --host-checked
--dart2js-options
> > --use-kernel language/generic_closure_test
> > 
> > was that intended?
> 
> Very strange.
> If I run the tests before and after I see what you see, but if I run test and
> then repeat the d8 step, both fail.

Doh!

The CL makes the test pass on the Ast version.
It 'passed' on kernel because it was marked Fail and I changed that!