feat(compiler): add name spans for property reads and method calls

[ayazhafiz]

ASTs for property read and method calls contain information about
the entire span of the expression, including its receiver. Use cases
like a language service and compile error messages may be more
interested in the span of the direct identifier for which the
expression is constructed (i.e. an accessed property). To support this,
this commit adds a nameSpan property on

• PropertyReads
• SafePropertyReads
• PropertyWrites
• MethodCalls
• SafeMethodCalls

The nameSpan property already existed for BindingPipes.

This commit also updates usages of these expressions' sourceSpans in
Ngtsc and the langauge service to use nameSpans where appropriate.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Feature

Does this PR introduce a breaking change?

• Yes
• No

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[JoostK]

Thanks for working on this. I do have some comments on the chosen source spans in the template type checker.

In general, I think our AST nodes could be cleaned up a lot if we were to have something like Identifier, similar to the TypeScript AST. That seems like a large project by itself though, so it's not necessary for this PR. It may also be problematic to push that forward, as tools that depend on the compiler for parsing ASTs would have to be updated. Although the compiler is not technically considered public API, such breakages are still problematic to push through.

[ayazhafiz]

In general, I think our AST nodes could be cleaned up a lot if we were to have something like Identifier, similar to the TypeScript AST.

such breakages are still problematic to push through.

I agree that this would be difficult to push through. IMO the benefit of this isn't worth the churn -- the expression grammar is fairly small, so exposing a common interface for identifier-like ASTs is probably enough.

[ayazhafiz]

@JoostK there are still some minor things that could be improved, for example wrapping method calls for diagnostics and annotating that with the span including any receivers (like is done for property reads). I think this can be done in another PR though, since this one is very large as is.

[JoostK]

LGTM for compiler changes.

[ayazhafiz]

Caretaker: could you run g3sync? (I think there may be some failures with Codelyzer)

[alxhub]

Presubmit

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}