Implement the new '?.' operator in analyzer.

Implement the new '?.' operator in analyzer.

As in r44802, the new operator is only accepted by the tokenizer if
the command-line option "--enable-null-aware-operators" is supplied.
Only static analysis of '?.' is implemented; however, the tests in
tests/language will verify behavior once it is implemented.

R=brianwilkerson@google.com

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

[Paul Berry, 2015-04-05 18:45:42]

paulberry@google.com changed reviewers:
+ brianwilkerson@google.com, scheglov@google.com

[Brian Wilkerson, 2015-04-05 19:55:45]

LGTM

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

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/ast.dart:18159: if (node.target != null) {
Seems like it would be cleaner and more consistent with:
  _visitNodeWithSuffix(node.target, node.operator.lexeme);

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

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:596: // then we don't call
resolveInvokedElement(..) which walks up the class
".." --> "..."

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:2456: // then we don't call
resolveProperty(..) which walks up the class
".." --> "..."

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/pubspec.yaml
File pkg/analyzer/pubspec.yaml (right):

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/pubspec.ya...
pkg/analyzer/pubspec.yaml:2: version: 0.24.1-alpha.1.dev
Unless, of course, we publish before committing this change.

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/test/gener...
File pkg/analyzer/test/generated/static_type_warning_code_test.dart (right):

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/test/gener...
pkg/analyzer/test/generated/static_type_warning_code_test.dart:1413:
assertErrors(source, [StaticTypeWarningCode.UNDEFINED_GETTER]);
It would be good to use a less generic error code, something like
CONDITIONAL_GETTER_ACCESS. It would help with both user understanding and with
quick fixes. (Same for the other two tests added here.)

[Paul Berry, 2015-04-05 20:49:43]

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

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/ast.dart:18159: if (node.target != null) {
On 2015/04/05 19:55:45, Brian Wilkerson wrote:
> Seems like it would be cleaner and more consistent with:
>   _visitNodeWithSuffix(node.target, node.operator.lexeme);

I considered that, but unfortunately it doesn't work because node.operator can
be null (it's null if there's no target).

I suppose I could do this:

if (node.target != null) {
  _visitNodeWithSuffix(node.target, node.operator.lexeme);
}

or this:

_visitNodeWithSuffix(node.target, node.operator == null ? null :
node.operator.lexeme);

But both of those possibilities seem clumsy because they have one if-test in the
caller and an equivalent if-test in the callee.  So I opted to just spell out
the logic explicitly.

Keeping as is for now.  If you have strong feelings I can always do a follow-up
CL.

As a side note, if it weren't for the chicken-and-egg problem this would have
been an excellent opportunity to do:

_visitNodeWithSuffix(node.target, node.operator?.lexeme);

:)

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

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:596: // then we don't call
resolveInvokedElement(..) which walks up the class
On 2015/04/05 19:55:45, Brian Wilkerson wrote:
> ".." --> "..."

Done.

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/lib/src/ge...
pkg/analyzer/lib/src/generated/element_resolver.dart:2456: // then we don't call
resolveProperty(..) which walks up the class
On 2015/04/05 19:55:45, Brian Wilkerson wrote:
> ".." --> "..."

Done.

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/pubspec.yaml
File pkg/analyzer/pubspec.yaml (right):

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/pubspec.ya...
pkg/analyzer/pubspec.yaml:2: version: 0.24.1-alpha.1.dev
On 2015/04/05 19:55:45, Brian Wilkerson wrote:
> Unless, of course, we publish before committing this change.

Acknowledged.

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/test/gener...
File pkg/analyzer/test/generated/static_type_warning_code_test.dart (right):

https://codereview.chromium.org/1062723002/diff/20001/pkg/analyzer/test/gener...
pkg/analyzer/test/generated/static_type_warning_code_test.dart:1413:
assertErrors(source, [StaticTypeWarningCode.UNDEFINED_GETTER]);
On 2015/04/05 19:55:45, Brian Wilkerson wrote:
> It would be good to use a less generic error code, something like
> CONDITIONAL_GETTER_ACCESS. It would help with both user understanding and with
> quick fixes. (Same for the other two tests added here.)

That's a good point, especially given that this limitation exists solely for the
convenience of the implementation and would probably confuse users if it ever
arose in practice.

I'll work on it in a follow-up CL.

[Paul Berry, 2015-04-05 20:59:32]

Committed patchset #2 (id:20001) manually as 44907 (presubmit successful).