Fix casts and type assertions on mixins used in native classes

Fix casts and type assertions on mixins used in native classes.

The tests are more complex with mixins and subtypes of native types.

We must avoid calling getCheckedModeHelper and friends during resolution because the type queries required to identify the static helper function might access unresolved types.

R=karlklose@google.com

Committed: https://code.google.com/p/dart/source/detail?r=27272

[sra1, 2013-09-06 02:40:19]

ping

[karlklose, 2013-09-06 06:51:01]

This seems to rely on the checked mode helpers being resolved from some other
use. How can you make sure that they are resolved when you get to the backend?

https://chromiumcodereview.appspot.com/23959003/diff/8001/tests/html/html.status
File tests/html/html.status (right):

https://chromiumcodereview.appspot.com/23959003/diff/8001/tests/html/html.sta...
tests/html/html.status:53: #custom/constructor_calls_created_synchronously_test:
Fail
Are these to be removed?

[karlklose, 2013-09-06 07:11:30]

Ah, I see that you enqueue them all instead of resolving which we need now. I
would like to avoid this, if possible. 

Can you elaborate more on which type is unresolved in getCheckedModeHelper and
what happens then? I think we should be able to always answer true, if the test
should succeed.

https://chromiumcodereview.appspot.com/23959003/diff/8001/sdk/lib/_internal/c...
File sdk/lib/_internal/compiler/implementation/js_backend/backend.dart (right):

https://chromiumcodereview.appspot.com/23959003/diff/8001/sdk/lib/_internal/c...
sdk/lib/_internal/compiler/implementation/js_backend/backend.dart:997:
enqueueInResolution(helper.getElement(compiler), elements);
Doesn't this work only because we already resolved it? The resolution queue
should be closed at that point and enqueueInResolution would throw if there are
no cached elements for the helper.

[sra1, 2013-09-06 08:01:41]

On 2013/09/06 07:11:30, karlklose wrote:
> Ah, I see that you enqueue them all instead of resolving which we need now. I
> would like to avoid this, if possible. 
> 
> Can you elaborate more on which type is unresolved in getCheckedModeHelper and
> what happens then? I think we should be able to always answer true, if the
test
> should succeed.


> 
>
https://chromiumcodereview.appspot.com/23959003/diff/8001/sdk/lib/_internal/c...
> File sdk/lib/_internal/compiler/implementation/js_backend/backend.dart
(right):
> 
>
https://chromiumcodereview.appspot.com/23959003/diff/8001/sdk/lib/_internal/c...
> sdk/lib/_internal/compiler/implementation/js_backend/backend.dart:997:
> enqueueInResolution(helper.getElement(compiler), elements);
> Doesn't this work only because we already resolved it? The resolution queue
> should be closed at that point and enqueueInResolution would throw if there
are
> no cached elements for the helper.

There are two problems I saw:
(1) accessing unresolved types
(2) wrong answers

It might be possible to solve (1) by calling ensureResolved() in more places but
I did not find them all.
I'm not sure that adding ensureResolved in many places is wise, since resolution
must not be confused by erroneous programs (e.g. cycles).

The second problem is that selecting the correct helper now depends on whether a
mixin is used on some native class or a subclass of a native class. You can't
tell from the type in your hand (the mixin or a subtype thereof) that a mixin is
used in another class until that other class has been resolved.  Resolving that
other class depends on allocations or native calls in methods that have not been
resolved yet.  So the selection of the correct helper depends the set of all
resolved types.

Basically, we need to avoid subtype queries until after resolution is complete.

[karlklose, 2013-09-06 12:51:42]

LGTM, but please file a bug and add a comment to find a solution to solve this
bug without adding all the helpers to the resolution queue.

Adding Johnni as a reviewer.

[sra1, 2013-09-07 00:35:32]

Committed patchset #3 manually as r27272 (presubmit successful).