Allow intercepted calls to have typed selectors.

Allow intercepted calls to have typed selectors.
Committed: https://code.google.com/p/dart/source/detail?r=18165

[kasperl, 2013-02-06 07:24:03]

LGTM.

https://codereview.chromium.org/12211013/diff/8/sdk/lib/_internal/compiler/im...
File sdk/lib/_internal/compiler/implementation/enqueue.dart (right):

https://codereview.chromium.org/12211013/diff/8/sdk/lib/_internal/compiler/im...
sdk/lib/_internal/compiler/implementation/enqueue.dart:322: void
registerDynamicInvocationOf(Element element, Selector selector) {
So the selector here is always a call here? If so, it would be nice if you could
assert that because it makes it easier to understand the way you're dealing with
fields (only adding the getter).

https://codereview.chromium.org/12211013/diff/8/sdk/lib/_internal/compiler/im...
File sdk/lib/_internal/compiler/implementation/ssa/optimize.dart (right):

https://codereview.chromium.org/12211013/diff/8/sdk/lib/_internal/compiler/im...
sdk/lib/_internal/compiler/implementation/ssa/optimize.dart:340: // There is a
strong dependency between codegen and this
Is this a TODO? It's unclear from the comment whether or not this is a problem
or a feature. The use of the word "should" is also a little bit hard to grasp --
will it go away by itself or is it something we should work on getting rid of?

[ngeoffray, 2013-02-06 08:11:55]

Thanks Kasper.

https://codereview.chromium.org/12211013/diff/8/sdk/lib/_internal/compiler/im...
File sdk/lib/_internal/compiler/implementation/enqueue.dart (right):

https://codereview.chromium.org/12211013/diff/8/sdk/lib/_internal/compiler/im...
sdk/lib/_internal/compiler/implementation/enqueue.dart:322: void
registerDynamicInvocationOf(Element element, Selector selector) {
On 2013/02/06 07:24:03, kasperl wrote:
> So the selector here is always a call here? If so, it would be nice if you
could
> assert that because it makes it easier to understand the way you're dealing
with
> fields (only adding the getter).

Yes, it's only a call selector. I added an assert and a comment.

https://codereview.chromium.org/12211013/diff/8/sdk/lib/_internal/compiler/im...
File sdk/lib/_internal/compiler/implementation/ssa/optimize.dart (right):

https://codereview.chromium.org/12211013/diff/8/sdk/lib/_internal/compiler/im...
sdk/lib/_internal/compiler/implementation/ssa/optimize.dart:340: // There is a
strong dependency between codegen and this
On 2013/02/06 07:24:03, kasperl wrote:
> Is this a TODO? It's unclear from the comment whether or not this is a problem
> or a feature.

It's kind of a problem. The feature is that we're getting rid of the interceptor
SSA node in the inputs, so the interceptor just becomes dead code.

 The use of the word "should" is also a little bit hard to grasp --
> will it go away by itself or is it something we should work on getting rid of?

I think we should work getting rid of it. Dependencies like this will come back
and hunt us. We could turn it into a HForeign instead but then the pass that
inserts bounds check (for removeLast) needs to be somehow updated. I hope
inlining will make these problems disappear (for example for removeLast, the
bounds checks becomes explicit, so is the growable check and the call to push).

[ngeoffray, 2013-02-06 10:16:18]

PTAL: I have found something that confused the generation of type guards. See
changes in bailout.dart.

[kasperl, 2013-02-06 10:27:19]

Still LGTM.