clean up generic methods in resolution

clean up generic methods in resolution

Introduces MethodInvocation.staticInvokeType to track the type of this invocation. This provides a natural place to store the instantiated generic function type. We then use this type when we are computing corresponding parameters or return types. As a result we do not need FunctionMember, and some of the code around generics becomes simpler/more uniform.

This approach should be a straightforward way to add support for generics in FunctionExpressionInvocation, in a follow up (see issue #25175).

Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is a pretty common way to describe these, I'm not sure why I didn't think of that better name originally. :)

Also removes broken ParameterMember.== that I had added in a previous CL. And the broken FunctionTypeImpl.originalFunction/instantiatedTypeArguments getters.

Finally, this fixes #23252 in the process of adding this. The return type of a "call" method was not being statically analyzed if the target was a VariableElement.

R=brianwilkerson@google.com, leafp@google.com

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

[Jennifer Messerly, 2016-01-06 20:36:33]

Description was changed from

==========
introduce MethodInvocation.staticInvokeType to track the type of this invocation

This provides a natural place to store the instantiated generic function type.
We then use this type when we are computing corresponding parameters or return
types.

Also fixes #23252 in the process of adding this.
==========

to

==========
introduce MethodInvocation.staticInvokeType to track the type of this invocation

This provides a natural place to store the instantiated generic function type.
We then use this type when we are computing corresponding parameters or return
types. As a result we do not need FunctionMember.

This approach should be easy to extend to FunctionExpressionInvocation, which
currently does not support generics.

Also fixes #23252 in the process of adding this.
==========

[Jennifer Messerly, 2016-01-06 20:36:33]

jmesserly@google.com changed reviewers:
+ brianwilkerson@google.com, leafp@google.com

[Jennifer Messerly, 2016-01-06 20:38:50]

Description was changed from

==========
introduce MethodInvocation.staticInvokeType to track the type of this invocation

This provides a natural place to store the instantiated generic function type.
We then use this type when we are computing corresponding parameters or return
types. As a result we do not need FunctionMember.

This approach should be easy to extend to FunctionExpressionInvocation, which
currently does not support generics.

Also fixes #23252 in the process of adding this.
==========

to

==========
introduce MethodInvocation.staticInvokeType to track the type of this invocation

This provides a natural place to store the instantiated generic function type.
We then use this type when we are computing corresponding parameters or return
types. As a result we do not need FunctionMember.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

This also fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.
==========

[Jennifer Messerly, 2016-01-06 20:40:22]

Description was changed from

==========
introduce MethodInvocation.staticInvokeType to track the type of this invocation

This provides a natural place to store the instantiated generic function type.
We then use this type when we are computing corresponding parameters or return
types. As a result we do not need FunctionMember.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

This also fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.
==========

to

==========
introduce MethodInvocation.staticInvokeType to track the type of this invocation

This provides a natural place to store the instantiated generic function type.
We then use this type when we are computing corresponding parameters or return
types. As a result we do not need FunctionMember.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is
a pretty common way to describe these, I'm not sure why I didn't think of that
better name originally. :)

This also fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.
==========

[Jennifer Messerly, 2016-01-06 20:41:51]

Description was changed from

==========
introduce MethodInvocation.staticInvokeType to track the type of this invocation

This provides a natural place to store the instantiated generic function type.
We then use this type when we are computing corresponding parameters or return
types. As a result we do not need FunctionMember.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is
a pretty common way to describe these, I'm not sure why I didn't think of that
better name originally. :)

This also fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.
==========

to

==========
introduce MethodInvocation.staticInvokeType to track the type of this invocation

This provides a natural place to store the instantiated generic function type.
We then use this type when we are computing corresponding parameters or return
types. As a result we do not need FunctionMember.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is
a pretty common way to describe these, I'm not sure why I didn't think of that
better name originally. :)

Also removes broken ParameterMember.== that I had added.

Finally, this fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.
==========

[Jennifer Messerly, 2016-01-06 20:44:01]

Description was changed from

==========
introduce MethodInvocation.staticInvokeType to track the type of this invocation

This provides a natural place to store the instantiated generic function type.
We then use this type when we are computing corresponding parameters or return
types. As a result we do not need FunctionMember.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is
a pretty common way to describe these, I'm not sure why I didn't think of that
better name originally. :)

Also removes broken ParameterMember.== that I had added.

Finally, this fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.
==========

to

==========
clean up generic methods in resolution

Introduces MethodInvocation.staticInvokeType to track the type of this
invocation. This provides a natural place to store the instantiated generic
function type. We then use this type when we are computing corresponding
parameters or return types. As a result we do not need FunctionMember, and some
of the code around generics becomes simpler/more uniform.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is
a pretty common way to describe these, I'm not sure why I didn't think of that
better name originally. :)

Also removes broken ParameterMember.== that I had added in a previous CL.

Finally, this fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.
==========

[Jennifer Messerly, 2016-01-06 20:49:18]

Hi Brian & Leaf,

I think (well, hope :D) that you'll like this CL! It is cleaning up some of the
code that I introduced for generic methods.

Brian -- this gets rid of FunctionMember, which I think is not needed per our
design discussion thread. Also it means that generic methods don't add so much
code bloat to visitMethodInvocation in ElementResolver/StaticTypeAnalyzer.

Leaf -- I think you'll like that we're (once again) tracking the original
staticElement on MethodInvocation. For the instantiated type, that can be easily
gotten on the MethodInvocation node.


One caveat emptor: this does not totally fix propagated types and generic
methods (#25340). It is a partial fix, in that we instantiate the generic
correctly, but I wasn't sure how to make return types work, so for now it stays
with the old behavior there.

Cheers!
- John

[Jennifer Messerly, 2016-01-06 20:52:00]

Hah, I totally forgot to mention, Leaf -- this gets rid of the broken
"originalFunction" getter on FunctionTypeImpl (also added by me
originally--doh!). That was the whole point of starting down this road... :)

[Jennifer Messerly, 2016-01-06 20:52:36]

Description was changed from

==========
clean up generic methods in resolution

Introduces MethodInvocation.staticInvokeType to track the type of this
invocation. This provides a natural place to store the instantiated generic
function type. We then use this type when we are computing corresponding
parameters or return types. As a result we do not need FunctionMember, and some
of the code around generics becomes simpler/more uniform.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is
a pretty common way to describe these, I'm not sure why I didn't think of that
better name originally. :)

Also removes broken ParameterMember.== that I had added in a previous CL.

Finally, this fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.
==========

to

==========
clean up generic methods in resolution

Introduces MethodInvocation.staticInvokeType to track the type of this
invocation. This provides a natural place to store the instantiated generic
function type. We then use this type when we are computing corresponding
parameters or return types. As a result we do not need FunctionMember, and some
of the code around generics becomes simpler/more uniform.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is
a pretty common way to describe these, I'm not sure why I didn't think of that
better name originally. :)

Also removes broken ParameterMember.== that I had added in a previous CL. And
the broken FunctionTypeImpl.originalFunction/instantiatedTypeArguments getters.

Finally, this fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.
==========

[Brian Wilkerson, 2016-01-06 21:57:34]

LGTM

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/dart/e...
File pkg/analyzer/lib/dart/element/type.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/dart/e...
pkg/analyzer/lib/dart/element/type.dart:604: * will track the substitution
`{S/T}`. This substitution will be propegated
"propegated" --> "propagated"

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/dart/e...
pkg/analyzer/lib/dart/element/type.dart:605: * to its members. For example, we
can also for the "foo" field declared as
Is "we can also for the" missing something between "also" and "for"?

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/dart/e...
pkg/analyzer/lib/dart/element/type.dart:613: // substitutedTypeParameters?
Alternatively we could remove the
Not sure what the value of adding "substituted" to the names would be. Type
arguments are always substituted for type parameters.

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/dart/e...
pkg/analyzer/lib/dart/element/type.dart:615: // TypeSubstitution.
I don't want to make this non-abstract because all of these "classes" are
defining the interface for the element model. We can remove it from the
interface hierarchy is it isn't useful, but otherwise I'd leave it alone.

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
File pkg/analyzer/lib/src/generated/ast.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/ast.dart:8098: DartType staticInvokeType;
Do we need the same fields added to FunctionExpressionInvocation?
BinaryExpression (can't remember whether we support generic operators)?

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
File pkg/analyzer/lib/src/generated/element_resolver.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:645: DartType
propagatedInvokeType =
If the propagatedInvokeType is not `null` and is not more specific than the
staticInvokeType, then we should set it to `null`.

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:1474: // TODO(jmesserly):
should we support for generic "call" methods on
"should we support for"?

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
File pkg/analyzer/lib/src/generated/resolver.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/resolver.dart:9169: * The flag [reportError]
should be `true` if a compile-time error should be
Perhaps "reportAsError"? As named my first impression was "report" or "don't
report", not "as error" or "as warning".

[Jennifer Messerly, 2016-01-06 22:25:52]

Thanks Brian! I think I got all of your comments if you want to take another
look.

@Leaf -- the failing test case you just added is passing now.

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/dart/e...
File pkg/analyzer/lib/dart/element/type.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/dart/e...
pkg/analyzer/lib/dart/element/type.dart:604: * will track the substitution
`{S/T}`. This substitution will be propegated
On 2016/01/06 21:57:34, Brian Wilkerson wrote:
> "propegated" --> "propagated"

Thanks, done. For some reason I spell that word wrong 90% of the time even
though I know how it's supposed to be. Sigh. :)

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/dart/e...
pkg/analyzer/lib/dart/element/type.dart:605: * to its members. For example, we
can also for the "foo" field declared as
On 2016/01/06 21:57:34, Brian Wilkerson wrote:
> Is "we can also for the" missing something between "also" and "for"?

Doh, yeah that comment was really bad. I think this may have been one of the
first things I tried to add to this CL before I really knew where it was
heading. I've attempted to make more sense out of the comment.

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/dart/e...
pkg/analyzer/lib/dart/element/type.dart:613: // substitutedTypeParameters?
Alternatively we could remove the
On 2016/01/06 21:57:34, Brian Wilkerson wrote:
> Not sure what the value of adding "substituted" to the names would be. Type
> arguments are always substituted for type parameters.

Agreed. Let me remove this TODO. It was added before I really understood what
was going on.

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/dart/e...
pkg/analyzer/lib/dart/element/type.dart:615: // TypeSubstitution.
On 2016/01/06 21:57:34, Brian Wilkerson wrote:
> I don't want to make this non-abstract because all of these "classes" are
> defining the interface for the element model. We can remove it from the
> interface hierarchy is it isn't useful, but otherwise I'd leave it alone.

Agreed, I will remove this comment.

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
File pkg/analyzer/lib/src/generated/ast.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/ast.dart:8098: DartType staticInvokeType;
On 2016/01/06 21:57:34, Brian Wilkerson wrote:
> Do we need the same fields added to FunctionExpressionInvocation?
> BinaryExpression (can't remember whether we support generic operators)?

Yeah I think so. Was going to talk to Leaf and see if he's okay with me tackling
that next. (it's bug https://github.com/dart-lang/sdk/issues/25175 currently
assigned to him)

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
File pkg/analyzer/lib/src/generated/element_resolver.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:645: DartType
propagatedInvokeType =
On 2016/01/06 21:57:34, Brian Wilkerson wrote:
> If the propagatedInvokeType is not `null` and is not more specific than the
> staticInvokeType, then we should set it to `null`.

Yeah that's a good point. I think we get this for free because only one of
"staticElement" or "propagatedElement" should be non-null, and that's how the
old code was able to ensure only one of static/propagated parameter types were
computed.

But I'm not sure if that's always the case.

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:1474: // TODO(jmesserly):
should we support for generic "call" methods on
On 2016/01/06 21:57:34, Brian Wilkerson wrote:
> "should we support for"?

DOH. Good catch! It got stuck halfway between an edit from "should we have
support for" and "should we support". Sometimes I think my comments would be so
much better if I didn't try edit them.... always end up losing words in the
process. :)

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
File pkg/analyzer/lib/src/generated/resolver.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/resolver.dart:9169: * The flag [reportError]
should be `true` if a compile-time error should be
On 2016/01/06 21:57:34, Brian Wilkerson wrote:
> Perhaps "reportAsError"? As named my first impression was "report" or "don't
> report", not "as error" or "as warning".

Great idea. Done!

https://codereview.chromium.org/1568643002/diff/60001/pkg/analyzer/test/gener...
File pkg/analyzer/test/generated/resolver_test.dart (right):

https://codereview.chromium.org/1568643002/diff/60001/pkg/analyzer/test/gener...
pkg/analyzer/test/generated/resolver_test.dart:13373: _resolveTestUnit(r'''
BTW, I added a very similar version of this to checker_test, not sure if it's
worth keeping both. Let me know what you think.

https://codereview.chromium.org/1568643002/diff/60001/pkg/analyzer/test/gener...
pkg/analyzer/test/generated/resolver_test.dart:13577: void
test_genericMethod_tearoff() {
nothing changed here just sorting

https://codereview.chromium.org/1568643002/diff/60001/pkg/analyzer/test/src/t...
File pkg/analyzer/test/src/task/strong/inferred_type_test.dart (right):

https://codereview.chromium.org/1568643002/diff/60001/pkg/analyzer/test/src/t...
pkg/analyzer/test/src/task/strong/inferred_type_test.dart:15: testChecker('!!!
dart:math min/max', {
oops, this was for debugging, removed

[Brian Wilkerson, 2016-01-06 22:47:01]

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
File pkg/analyzer/lib/src/generated/element_resolver.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:645: DartType
propagatedInvokeType =
> I think we get this for free because only one of
> "staticElement" or "propagatedElement" should be non-null, and that's how the
> old code was able to ensure only one of static/propagated parameter types were
> computed.
> 
> But I'm not sure if that's always the case.

Unfortunately, no. It's perfectly valid for both to be non-null (which means the
old code was probably wrong). For example, given

class A {
  int m() {}
}
class B extends A {
  int m() {}
}
f() {
  A a = new B();
  a.m();
}

The static type of 'a' will be 'A' but the propagated type will be 'B', so in
the invocation of 'm' we will have both a static element (A.m) and a propagated
element (B.m). But because the return type will be the same either way, we want
to not record the propagated type (in order to reduce the amount of follow-on
work we do).

[Jennifer Messerly, 2016-01-06 22:52:48]

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
File pkg/analyzer/lib/src/generated/element_resolver.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:645: DartType
propagatedInvokeType =
On 2016/01/06 22:47:01, Brian Wilkerson wrote:
> > I think we get this for free because only one of
> > "staticElement" or "propagatedElement" should be non-null, and that's how
the
> > old code was able to ensure only one of static/propagated parameter types
were
> > computed.
> > 
> > But I'm not sure if that's always the case.
> 
> Unfortunately, no. It's perfectly valid for both to be non-null (which means
the
> old code was probably wrong). For example, given
> 
> class A {
>   int m() {}
> }
> class B extends A {
>   int m() {}
> }
> f() {
>   A a = new B();
>   a.m();
> }
> 
> The static type of 'a' will be 'A' but the propagated type will be 'B', so in
> the invocation of 'm' we will have both a static element (A.m) and a
propagated
> element (B.m). But because the return type will be the same either way, we
want
> to not record the propagated type (in order to reduce the amount of follow-on
> work we do).

Ah that makes sense. Does something like this look right:

if (propagatedInvokeType != null &&
    !propagatedInvokeType.isMoreSpecificThan(staticInvokeType)) {

  // If the propagated type is no better than the static type, discard it.
  propagatedInvokeType = null;
}

[Jennifer Messerly, 2016-01-07 00:11:18]

I added some logic to avoid setting the propagatedInvokeType.

Turns out we still need to update the propagated parameter types, otherwise some
propagated type logic later doesn't kick in. Likely there's a fix we could make
somewhere else to save that work too. For now this gets us back to the original
behavior.

[Brian Wilkerson, 2016-01-07 00:24:23]

LGTM

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
File pkg/analyzer/lib/src/generated/element_resolver.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:645: DartType
propagatedInvokeType =
See ResolverVisitor.recordPropagatedTypeIfBetter.

[Jennifer Messerly, 2016-01-07 00:33:29]

Thanks!

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
File pkg/analyzer/lib/src/generated/element_resolver.dart (right):

https://codereview.chromium.org/1568643002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:645: DartType
propagatedInvokeType =
On 2016/01/07 00:24:22, Brian Wilkerson wrote:
> See ResolverVisitor.recordPropagatedTypeIfBetter.

Ah, nice! Looking through there, I think the logic I added is almost the same,
but it should explicitly "null" out the type if it is not needed. I'll add that
& then I think it's good.

[Leaf, 2016-01-07 22:47:30]

LGTM!  This is really nice, I think a big improvement.  I think this just leaves
the inferred function invocation case as the last big remaining miss.

[Jennifer Messerly, 2016-01-07 22:51:40]

Description was changed from

==========
clean up generic methods in resolution

Introduces MethodInvocation.staticInvokeType to track the type of this
invocation. This provides a natural place to store the instantiated generic
function type. We then use this type when we are computing corresponding
parameters or return types. As a result we do not need FunctionMember, and some
of the code around generics becomes simpler/more uniform.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is
a pretty common way to describe these, I'm not sure why I didn't think of that
better name originally. :)

Also removes broken ParameterMember.== that I had added in a previous CL. And
the broken FunctionTypeImpl.originalFunction/instantiatedTypeArguments getters.

Finally, this fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.
==========

to

==========
clean up generic methods in resolution

Introduces MethodInvocation.staticInvokeType to track the type of this
invocation. This provides a natural place to store the instantiated generic
function type. We then use this type when we are computing corresponding
parameters or return types. As a result we do not need FunctionMember, and some
of the code around generics becomes simpler/more uniform.

This approach should be a straightforward way to add support for generics in
FunctionExpressionInvocation, in a follow up (see issue #25175).

Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is
a pretty common way to describe these, I'm not sure why I didn't think of that
better name originally. :)

Also removes broken ParameterMember.== that I had added in a previous CL. And
the broken FunctionTypeImpl.originalFunction/instantiatedTypeArguments getters.

Finally, this fixes #23252 in the process of adding this. The return type of a
"call" method was not being statically analyzed if the target was a
VariableElement.

R=brianwilkerson@google.com, leafp@google.com

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

[Jennifer Messerly, 2016-01-07 22:51:41]

Committed patchset #6 (id:100001) manually as
924f2f97b75bc9774fe49813806e574d1ddbccb1 (presubmit successful).