Support for a.b.c.d extract property sequence.

Support for a.b.c.d extract property sequence.

R=paulberry@google.com
BUG=

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

[Paul Berry, 2016-04-15 21:15:52]

I'm concerned that this approach is not going to work when we try to extend it
to cover generics.  Consider:

class A<T> {
  B<List<T>> b = new B<List<T>>();
}
class B<T> {
  C<List<T>> c = new C<List<T>>();
}
class C<T> {
  T d;
}
var a = new A<int>();
var v = a.b.c.d;

The inferred type of v should be List<List<int>>.  But since your implementation
of getContainedName() only returns the getter if it's a
PropertyAccessorElementForLink (and not a PropertyAccessorMember), we will just
infer `dynamic`.

I'm also concerned because it looks like your implementation will change the
behavior of `x.length` lookup on a list so that it now returns the `length`
getter for whatever the type of `x` is, rather than a
NonStaticMemberElementForLink object pointing to the const node for `x`.  Which
means that we will no longer detect const cycles like:

class C {
  final y;
  const C() : y = x.length;
}
const x = [const C()];

My design intention here was that instead of returning the
PropertyAccessorElement directly from getContainedName(), we should return
NonstaticMemberElementForLink (as we do now), but NonstaticMemberElementForLink
should be expanded so that it stores the Element (or Member) of the nonstatic
member that was accessed (or `null` if the lookup failed). 
NonstaticMemberElementForLink.asStaticType() should return the static type of
the Element or Member.  To handle constructs like `a.b.c.d`,
NonstaticMemberElementForLink.getContainedName() should do a lookup and return a
new NonstaticMemberElementForLink pointing to the looked up member.

Does that make sense?

https://codereview.chromium.org/1893703002/diff/1/pkg/analyzer/lib/src/summar...
File pkg/analyzer/lib/src/summary/link.dart (right):

https://codereview.chromium.org/1893703002/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/link.dart:3341: // TODO(scheglov) is this correct?
Yes, I believe this is correct, but only because of a shortcut I took earlier in
the linker implementation.  We always call asTypeInferenceNode on the return
value of getContainedName(), and getContainedName() never returns accessors; it
returns top level variable elements or fields.

This is awkward and not really in line with Dart semantics; really
getContainedName() should return the accessor, and then
PropertyAccessorElementForLink_Variable should return
_variable._typeInferenceNode.

But I think we can wait until a future CL to clean this up :)

https://codereview.chromium.org/1893703002/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/link.dart:3398: print('getter: $getter');
Looks like temporary debugging code; should be removed before committing.

[scheglov, 2016-04-15 21:52:37]

This makes perfect sense.
Done.
PTAL

[Paul Berry, 2016-04-16 14:50:10]

lgtm

https://codereview.chromium.org/1893703002/diff/60001/pkg/analyzer/lib/src/su...
File pkg/analyzer/lib/src/summary/link.dart (right):

https://codereview.chromium.org/1893703002/diff/60001/pkg/analyzer/lib/src/su...
pkg/analyzer/lib/src/summary/link.dart:3181: }
else {
  return new NonStaticMemberElementForLink(null, _constNode);
}

So that we don't allow "trying again" after a failed lookup.  E.g. your code
would allow:

class A {
  B b;
}
class B {
  int c;
}
A a;
var x = a.b.foo.c; // Incorrectly infers type of `int`

https://codereview.chromium.org/1893703002/diff/60001/pkg/analyzer/lib/src/su...
pkg/analyzer/lib/src/summary/link.dart:4167: * fails.
Comment should reflect the fact that we don't do the lookup if we're not in
strong mode (and why)

[scheglov, 2016-04-17 02:38:26]

https://codereview.chromium.org/1893703002/diff/60001/pkg/analyzer/lib/src/su...
File pkg/analyzer/lib/src/summary/link.dart (right):

https://codereview.chromium.org/1893703002/diff/60001/pkg/analyzer/lib/src/su...
pkg/analyzer/lib/src/summary/link.dart:3181: }
On 2016/04/16 14:50:09, Paul Berry wrote:
> else {
>   return new NonStaticMemberElementForLink(null, _constNode);
> }
> 
> So that we don't allow "trying again" after a failed lookup.  E.g. your code
> would allow:
> 
> class A {
>   B b;
> }
> class B {
>   int c;
> }
> A a;
> var x = a.b.foo.c; // Incorrectly infers type of `int`

Done.

https://codereview.chromium.org/1893703002/diff/60001/pkg/analyzer/lib/src/su...
pkg/analyzer/lib/src/summary/link.dart:4167: * fails.
On 2016/04/16 14:50:09, Paul Berry wrote:
> Comment should reflect the fact that we don't do the lookup if we're not in
> strong mode (and why)

Done.

[scheglov, 2016-04-17 02:38:29]

Description was changed from

==========
Support for a.b.c.d extract property sequence.

R=paulberry@google.com
BUG=
==========

to

==========
Support for a.b.c.d extract property sequence.

R=paulberry@google.com
BUG=

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

[scheglov, 2016-04-17 02:38:31]

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