4 Commits

Author SHA1 Message Date
Andrew Scott
a86ca4fe04 feat(language-service): Enable renaming of pipes (#40523)
This commit updates the logic in the LS renaming to handle renaming of
pipes, both from the name expression in the pipe metadata as well as
from the template.

The approach here is to introduce a new concept for renaming: an
"indirect" rename. In this type of rename, we find rename locations
in with the native TS Language Service using a different node than the
one we are renaming. Using pipes as an example, if we want to rename the
pipe name from the string literal expression, we use the transform
method to find rename locations rather than the string literal itself
(which will not return any results because it's just a string).

So the general approach is:
* Determine the details about the requested rename location, i.e. the
  targeted template node and symbol for a template rename, or the TS
  node for a rename outside a template.
* Using the details of the location, determine if the node is attempting
  to rename something that is an indirect rename (pipes, selectors,
  bindings). Other renames are considered "direct" and we use whatever
  results the native TSLS returns for the rename locations.
* In the case of indirect renames, we throw out results that do not
  appear in the templates (in this case, the shim files). These results will be
  for the "indirect" rename that we don't want to touch, but are only
  using to find template results.
* Create an additional rename result for the string literal expression
  that is used for the input/output alias, the pipe name, or the
  selector.

 Note that renaming is moving towards being much more accurate in its
 results than "find references". When the approach for renaming
 stabilizes, we may want to then port the changes back to being shared
 with the approach for retrieving references.

PR Close #40523
2021-05-06 17:54:13 -04:00
Andrew Scott
f31a6015a0 perf(language-service): short-circuit LS operations (#40946)
When certain information is requested from the Angular Language Service, we
know that there will be no additional Angular information if the requested
position is not in an inline template, template url, or style url. To avoid
unnecessary compiler compilations, we short circuit and return `undefined`
before asking the compiler for any type of answer which would trigger a
partial compilation, at the very least.

fixes https://github.com/angular/vscode-ng-language-service/issues/1104

PR Close #40946
2021-02-22 13:19:09 -08:00
Andrew Scott
d466db8285 fix(language-service): Do not include $event parameter in reference results (#40158)
Given the template
`<div (click)="doSomething($event)"></div>`

If you request references for the `$event`, the results include both `$event` and `(click)="doSomething($event)"`.

This happens because in the TCB, `$event` is passed to the `subscribe`/`addEventListener`
function as an argument. So when we ask typescript to give us the references, we
get the result from the usage in the subscribe body as well as the one passed in as an argument.

This commit adds an identifier to the `$event` parameter in the TCB so
that the result returned from `getReferencesAtPosition` can be
identified and filtered out.

fixes #40157

PR Close #40158
2021-01-05 10:07:20 -08:00
Andrew Scott
3a1d36cce3 refactor(language-service): Use compiler APIs in Ivy to get definitions for external resources (#39476)
Rather than re-reading component metadata that was already interpreted
by the Ivy compiler, the Language Service should instead use the
compiler APIs to get information it needs about the metadata.

PR Close #39476
2020-11-06 09:17:33 -08:00