2020-11-19 16:31:34 -05:00
|
|
|
/**
|
|
|
|
* @license
|
|
|
|
* Copyright Google LLC All Rights Reserved.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by an MIT-style license that can be
|
|
|
|
* found in the LICENSE file at https://angular.io/license
|
|
|
|
*/
|
2020-12-01 17:55:57 -05:00
|
|
|
import {AbsoluteSourceSpan, AST, BindingPipe, LiteralPrimitive, MethodCall, ParseSourceSpan, PropertyRead, PropertyWrite, SafeMethodCall, SafePropertyRead, TmplAstBoundAttribute, TmplAstBoundEvent, TmplAstNode, TmplAstReference, TmplAstTextAttribute, TmplAstVariable} from '@angular/compiler';
|
2020-11-19 16:31:34 -05:00
|
|
|
import {NgCompiler} from '@angular/compiler-cli/src/ngtsc/core';
|
|
|
|
import {absoluteFrom, absoluteFromSourceFile, AbsoluteFsPath} from '@angular/compiler-cli/src/ngtsc/file_system';
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
import {DirectiveSymbol, ShimLocation, SymbolKind, TemplateTypeChecker, TypeCheckingProgramStrategy} from '@angular/compiler-cli/src/ngtsc/typecheck/api';
|
2020-12-16 14:13:34 -05:00
|
|
|
import {ExpressionIdentifier, hasExpressionIdentifier} from '@angular/compiler-cli/src/ngtsc/typecheck/src/comments';
|
2020-11-19 16:31:34 -05:00
|
|
|
import * as ts from 'typescript';
|
|
|
|
|
2020-12-16 17:39:49 -05:00
|
|
|
import {getTargetAtPosition, TargetNodeKind} from './template_target';
|
2020-12-16 14:13:34 -05:00
|
|
|
import {findTightestNode} from './ts_utils';
|
2021-01-15 18:57:24 -05:00
|
|
|
import {getDirectiveMatchesForAttribute, getDirectiveMatchesForElementTag, getTemplateInfoAtPosition, getTemplateLocationFromShimLocation, isWithin, TemplateInfo, toTextSpan} from './utils';
|
2020-11-19 16:31:34 -05:00
|
|
|
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
interface FilePosition {
|
|
|
|
fileName: string;
|
|
|
|
position: number;
|
|
|
|
}
|
|
|
|
|
|
|
|
function toFilePosition(shimLocation: ShimLocation): FilePosition {
|
|
|
|
return {fileName: shimLocation.shimPath, position: shimLocation.positionInShimFile};
|
|
|
|
}
|
|
|
|
|
|
|
|
enum RequestKind {
|
|
|
|
Template,
|
|
|
|
TypeScript,
|
|
|
|
}
|
|
|
|
|
|
|
|
interface TemplateRequest {
|
|
|
|
kind: RequestKind.Template;
|
|
|
|
requestNode: TmplAstNode|AST;
|
|
|
|
position: number;
|
|
|
|
}
|
|
|
|
|
|
|
|
interface TypeScriptRequest {
|
|
|
|
kind: RequestKind.TypeScript;
|
|
|
|
requestNode: ts.Node;
|
|
|
|
}
|
|
|
|
|
|
|
|
type RequestOrigin = TemplateRequest|TypeScriptRequest;
|
|
|
|
|
|
|
|
interface TemplateLocationDetails {
|
|
|
|
/**
|
|
|
|
* A target node in a template.
|
|
|
|
*/
|
|
|
|
templateTarget: TmplAstNode|AST;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* TypeScript locations which the template node maps to. A given template node might map to
|
|
|
|
* several TS nodes. For example, a template node for an attribute might resolve to several
|
|
|
|
* directives or a directive and one of its inputs.
|
|
|
|
*/
|
|
|
|
typescriptLocations: FilePosition[];
|
|
|
|
}
|
|
|
|
|
|
|
|
export class ReferencesAndRenameBuilder {
|
2020-11-19 16:31:34 -05:00
|
|
|
private readonly ttc = this.compiler.getTemplateTypeChecker();
|
|
|
|
|
|
|
|
constructor(
|
|
|
|
private readonly strategy: TypeCheckingProgramStrategy,
|
|
|
|
private readonly tsLS: ts.LanguageService, private readonly compiler: NgCompiler) {}
|
|
|
|
|
2020-12-01 17:55:57 -05:00
|
|
|
getRenameInfo(filePath: string, position: number):
|
|
|
|
Omit<ts.RenameInfoSuccess, 'kind'|'kindModifiers'>|ts.RenameInfoFailure {
|
|
|
|
const templateInfo = getTemplateInfoAtPosition(filePath, position, this.compiler);
|
|
|
|
// We could not get a template at position so we assume the request came from outside the
|
|
|
|
// template.
|
|
|
|
if (templateInfo === undefined) {
|
|
|
|
return this.tsLS.getRenameInfo(filePath, position);
|
|
|
|
}
|
|
|
|
|
|
|
|
const allTargetDetails = this.getTargetDetailsAtTemplatePosition(templateInfo, position);
|
|
|
|
if (allTargetDetails === null) {
|
|
|
|
return {canRename: false, localizedErrorMessage: 'Could not find template node at position.'};
|
|
|
|
}
|
|
|
|
const {templateTarget} = allTargetDetails[0];
|
|
|
|
const templateTextAndSpan = getRenameTextAndSpanAtPosition(templateTarget, position);
|
|
|
|
if (templateTextAndSpan === null) {
|
|
|
|
return {canRename: false, localizedErrorMessage: 'Could not determine template node text.'};
|
|
|
|
}
|
|
|
|
const {text, span} = templateTextAndSpan;
|
|
|
|
return {
|
|
|
|
canRename: true,
|
|
|
|
displayName: text,
|
|
|
|
fullDisplayName: text,
|
|
|
|
triggerSpan: toTextSpan(span),
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
findRenameLocations(filePath: string, position: number): readonly ts.RenameLocation[]|undefined {
|
|
|
|
this.ttc.generateAllTypeCheckBlocks();
|
|
|
|
const templateInfo = getTemplateInfoAtPosition(filePath, position, this.compiler);
|
2020-12-01 17:55:57 -05:00
|
|
|
// We could not get a template at position so we assume the request came from outside the
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
// template.
|
|
|
|
if (templateInfo === undefined) {
|
|
|
|
const requestNode = this.getTsNodeAtPosition(filePath, position);
|
|
|
|
if (requestNode === null) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
const requestOrigin: TypeScriptRequest = {kind: RequestKind.TypeScript, requestNode};
|
|
|
|
return this.findRenameLocationsAtTypescriptPosition(filePath, position, requestOrigin);
|
|
|
|
}
|
|
|
|
|
|
|
|
return this.findRenameLocationsAtTemplatePosition(templateInfo, position);
|
|
|
|
}
|
|
|
|
|
|
|
|
private findRenameLocationsAtTemplatePosition(templateInfo: TemplateInfo, position: number):
|
|
|
|
readonly ts.RenameLocation[]|undefined {
|
|
|
|
const allTargetDetails = this.getTargetDetailsAtTemplatePosition(templateInfo, position);
|
|
|
|
if (allTargetDetails === null) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
|
|
|
const allRenameLocations: ts.RenameLocation[] = [];
|
|
|
|
for (const targetDetails of allTargetDetails) {
|
|
|
|
const requestOrigin: TemplateRequest = {
|
|
|
|
kind: RequestKind.Template,
|
|
|
|
requestNode: targetDetails.templateTarget,
|
|
|
|
position,
|
|
|
|
};
|
|
|
|
|
|
|
|
for (const location of targetDetails.typescriptLocations) {
|
|
|
|
const locations = this.findRenameLocationsAtTypescriptPosition(
|
|
|
|
location.fileName, location.position, requestOrigin);
|
|
|
|
// If we couldn't find rename locations for _any_ result, we should not allow renaming to
|
|
|
|
// proceed instead of having a partially complete rename.
|
|
|
|
if (locations === undefined) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
allRenameLocations.push(...locations);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return allRenameLocations.length > 0 ? allRenameLocations : undefined;
|
|
|
|
}
|
|
|
|
|
|
|
|
private getTsNodeAtPosition(filePath: string, position: number): ts.Node|null {
|
|
|
|
const sf = this.strategy.getProgram().getSourceFile(filePath);
|
|
|
|
if (!sf) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
return findTightestNode(sf, position) ?? null;
|
|
|
|
}
|
|
|
|
|
|
|
|
findRenameLocationsAtTypescriptPosition(
|
|
|
|
filePath: string, position: number,
|
|
|
|
requestOrigin: RequestOrigin): readonly ts.RenameLocation[]|undefined {
|
|
|
|
let originalNodeText: string;
|
|
|
|
if (requestOrigin.kind === RequestKind.TypeScript) {
|
|
|
|
originalNodeText = requestOrigin.requestNode.getText();
|
|
|
|
} else {
|
|
|
|
const templateNodeText =
|
2020-12-01 17:55:57 -05:00
|
|
|
getRenameTextAndSpanAtPosition(requestOrigin.requestNode, requestOrigin.position);
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
if (templateNodeText === null) {
|
|
|
|
return undefined;
|
|
|
|
}
|
2020-12-01 17:55:57 -05:00
|
|
|
originalNodeText = templateNodeText.text;
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
const locations = this.tsLS.findRenameLocations(
|
|
|
|
filePath, position, /*findInStrings*/ false, /*findInComments*/ false);
|
|
|
|
if (locations === undefined) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
2021-01-15 13:47:39 -05:00
|
|
|
const entries: Map<string, ts.RenameLocation> = new Map();
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
for (const location of locations) {
|
|
|
|
// TODO(atscott): Determine if a file is a shim file in a more robust way and make the API
|
|
|
|
// available in an appropriate location.
|
|
|
|
if (this.ttc.isTrackedTypeCheckFile(absoluteFrom(location.fileName))) {
|
|
|
|
const entry = this.convertToTemplateDocumentSpan(location, this.ttc, originalNodeText);
|
|
|
|
// There is no template node whose text matches the original rename request. Bail on
|
|
|
|
// renaming completely rather than providing incomplete results.
|
|
|
|
if (entry === null) {
|
|
|
|
return undefined;
|
|
|
|
}
|
2021-01-15 13:47:39 -05:00
|
|
|
entries.set(createLocationKey(entry), entry);
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
} else {
|
|
|
|
// Ensure we only allow renaming a TS result with matching text
|
|
|
|
const refNode = this.getTsNodeAtPosition(location.fileName, location.textSpan.start);
|
|
|
|
if (refNode === null || refNode.getText() !== originalNodeText) {
|
|
|
|
return undefined;
|
|
|
|
}
|
2021-01-15 13:47:39 -05:00
|
|
|
entries.set(createLocationKey(location), location);
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
}
|
|
|
|
}
|
2021-01-15 13:47:39 -05:00
|
|
|
return Array.from(entries.values());
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
getReferencesAtPosition(filePath: string, position: number): ts.ReferenceEntry[]|undefined {
|
2020-11-19 16:31:34 -05:00
|
|
|
this.ttc.generateAllTypeCheckBlocks();
|
|
|
|
const templateInfo = getTemplateInfoAtPosition(filePath, position, this.compiler);
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
if (templateInfo === undefined) {
|
|
|
|
return this.getReferencesAtTypescriptPosition(filePath, position);
|
|
|
|
}
|
|
|
|
return this.getReferencesAtTemplatePosition(templateInfo, position);
|
2020-11-19 16:31:34 -05:00
|
|
|
}
|
|
|
|
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
private getReferencesAtTemplatePosition(templateInfo: TemplateInfo, position: number):
|
2020-11-19 16:31:34 -05:00
|
|
|
ts.ReferenceEntry[]|undefined {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
const allTargetDetails = this.getTargetDetailsAtTemplatePosition(templateInfo, position);
|
|
|
|
if (allTargetDetails === null) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
const allReferences: ts.ReferenceEntry[] = [];
|
|
|
|
for (const targetDetails of allTargetDetails) {
|
|
|
|
for (const location of targetDetails.typescriptLocations) {
|
|
|
|
const refs = this.getReferencesAtTypescriptPosition(location.fileName, location.position);
|
|
|
|
if (refs !== undefined) {
|
|
|
|
allReferences.push(...refs);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return allReferences.length > 0 ? allReferences : undefined;
|
|
|
|
}
|
|
|
|
|
|
|
|
private getTargetDetailsAtTemplatePosition({template, component}: TemplateInfo, position: number):
|
|
|
|
TemplateLocationDetails[]|null {
|
2020-11-19 16:31:34 -05:00
|
|
|
// Find the AST node in the template at the position.
|
|
|
|
const positionDetails = getTargetAtPosition(template, position);
|
|
|
|
if (positionDetails === null) {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
return null;
|
2020-11-19 16:31:34 -05:00
|
|
|
}
|
|
|
|
|
2020-12-17 17:43:53 -05:00
|
|
|
const nodes = positionDetails.context.kind === TargetNodeKind.TwoWayBindingContext ?
|
|
|
|
positionDetails.context.nodes :
|
|
|
|
[positionDetails.context.node];
|
2020-11-18 17:07:30 -05:00
|
|
|
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
const details: TemplateLocationDetails[] = [];
|
|
|
|
|
2020-12-17 17:43:53 -05:00
|
|
|
for (const node of nodes) {
|
|
|
|
// Get the information about the TCB at the template position.
|
|
|
|
const symbol = this.ttc.getSymbolOfNode(node, component);
|
|
|
|
if (symbol === null) {
|
|
|
|
continue;
|
2020-12-09 13:09:55 -05:00
|
|
|
}
|
2020-12-01 17:55:57 -05:00
|
|
|
|
|
|
|
const templateTarget = node;
|
2020-12-17 17:43:53 -05:00
|
|
|
switch (symbol.kind) {
|
|
|
|
case SymbolKind.Directive:
|
|
|
|
case SymbolKind.Template:
|
|
|
|
// References to elements, templates, and directives will be through template references
|
|
|
|
// (#ref). They shouldn't be used directly for a Language Service reference request.
|
|
|
|
break;
|
|
|
|
case SymbolKind.Element: {
|
|
|
|
const matches = getDirectiveMatchesForElementTag(symbol.templateNode, symbol.directives);
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
details.push(
|
|
|
|
{typescriptLocations: this.getPositionsForDirectives(matches), templateTarget});
|
2020-12-17 17:43:53 -05:00
|
|
|
break;
|
2020-12-09 13:09:55 -05:00
|
|
|
}
|
2020-12-17 17:43:53 -05:00
|
|
|
case SymbolKind.DomBinding: {
|
|
|
|
// Dom bindings aren't currently type-checked (see `checkTypeOfDomBindings`) so they don't
|
|
|
|
// have a shim location. This means we can't match dom bindings to their lib.dom
|
|
|
|
// reference, but we can still see if they match to a directive.
|
|
|
|
if (!(node instanceof TmplAstTextAttribute) && !(node instanceof TmplAstBoundAttribute)) {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
return null;
|
2020-12-17 17:43:53 -05:00
|
|
|
}
|
|
|
|
const directives = getDirectiveMatchesForAttribute(
|
|
|
|
node.name, symbol.host.templateNode, symbol.host.directives);
|
2020-12-01 17:55:57 -05:00
|
|
|
details.push({
|
|
|
|
typescriptLocations: this.getPositionsForDirectives(directives),
|
|
|
|
templateTarget,
|
|
|
|
});
|
2020-12-17 17:43:53 -05:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case SymbolKind.Reference: {
|
2020-12-01 17:55:57 -05:00
|
|
|
details.push({
|
|
|
|
typescriptLocations: [toFilePosition(symbol.referenceVarLocation)],
|
|
|
|
templateTarget,
|
|
|
|
});
|
2020-12-17 17:43:53 -05:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case SymbolKind.Variable: {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
if ((templateTarget instanceof TmplAstVariable)) {
|
|
|
|
if (templateTarget.valueSpan !== undefined &&
|
|
|
|
isWithin(position, templateTarget.valueSpan)) {
|
2020-12-17 17:43:53 -05:00
|
|
|
// In the valueSpan of the variable, we want to get the reference of the initializer.
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
details.push({
|
|
|
|
typescriptLocations: [toFilePosition(symbol.initializerLocation)],
|
|
|
|
templateTarget,
|
|
|
|
});
|
|
|
|
} else if (isWithin(position, templateTarget.keySpan)) {
|
2020-12-17 17:43:53 -05:00
|
|
|
// In the keySpan of the variable, we want to get the reference of the local variable.
|
2020-12-01 17:55:57 -05:00
|
|
|
details.push({
|
|
|
|
typescriptLocations: [toFilePosition(symbol.localVarLocation)],
|
|
|
|
templateTarget,
|
|
|
|
});
|
2020-12-17 17:43:53 -05:00
|
|
|
}
|
2020-11-19 16:31:34 -05:00
|
|
|
} else {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
// If the templateNode is not the `TmplAstVariable`, it must be a usage of the
|
|
|
|
// variable somewhere in the template.
|
2020-12-01 17:55:57 -05:00
|
|
|
details.push({
|
|
|
|
typescriptLocations: [toFilePosition(symbol.localVarLocation)],
|
|
|
|
templateTarget,
|
|
|
|
});
|
2020-11-19 16:31:34 -05:00
|
|
|
}
|
2020-12-17 17:43:53 -05:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case SymbolKind.Input:
|
|
|
|
case SymbolKind.Output: {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
details.push({
|
|
|
|
typescriptLocations:
|
|
|
|
symbol.bindings.map(binding => toFilePosition(binding.shimLocation)),
|
|
|
|
templateTarget,
|
|
|
|
});
|
2020-12-17 17:43:53 -05:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case SymbolKind.Pipe:
|
|
|
|
case SymbolKind.Expression: {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
details.push(
|
|
|
|
{typescriptLocations: [toFilePosition(symbol.shimLocation)], templateTarget});
|
2020-12-17 17:43:53 -05:00
|
|
|
break;
|
|
|
|
}
|
2020-11-19 16:31:34 -05:00
|
|
|
}
|
|
|
|
}
|
2020-12-17 17:43:53 -05:00
|
|
|
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
return details.length > 0 ? details : null;
|
2020-11-19 16:31:34 -05:00
|
|
|
}
|
|
|
|
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
private getPositionsForDirectives(directives: Set<DirectiveSymbol>): FilePosition[] {
|
|
|
|
const allDirectives: FilePosition[] = [];
|
2020-12-09 13:09:55 -05:00
|
|
|
for (const dir of directives.values()) {
|
|
|
|
const dirClass = dir.tsSymbol.valueDeclaration;
|
|
|
|
if (dirClass === undefined || !ts.isClassDeclaration(dirClass) ||
|
|
|
|
dirClass.name === undefined) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
const {fileName} = dirClass.getSourceFile();
|
|
|
|
const position = dirClass.name.getStart();
|
|
|
|
allDirectives.push({fileName, position});
|
2020-12-09 13:09:55 -05:00
|
|
|
}
|
|
|
|
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
return allDirectives;
|
2020-12-09 13:09:55 -05:00
|
|
|
}
|
|
|
|
|
2020-11-19 16:31:34 -05:00
|
|
|
private getReferencesAtTypescriptPosition(fileName: string, position: number):
|
|
|
|
ts.ReferenceEntry[]|undefined {
|
|
|
|
const refs = this.tsLS.getReferencesAtPosition(fileName, position);
|
|
|
|
if (refs === undefined) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
2021-01-15 13:47:39 -05:00
|
|
|
const entries: Map<string, ts.ReferenceEntry> = new Map();
|
2020-11-19 16:31:34 -05:00
|
|
|
for (const ref of refs) {
|
2020-12-01 12:39:27 -05:00
|
|
|
if (this.ttc.isTrackedTypeCheckFile(absoluteFrom(ref.fileName))) {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
const entry = this.convertToTemplateDocumentSpan(ref, this.ttc);
|
2020-11-19 16:31:34 -05:00
|
|
|
if (entry !== null) {
|
2021-01-15 13:47:39 -05:00
|
|
|
entries.set(createLocationKey(entry), entry);
|
2020-11-19 16:31:34 -05:00
|
|
|
}
|
|
|
|
} else {
|
2021-01-15 13:47:39 -05:00
|
|
|
entries.set(createLocationKey(ref), ref);
|
2020-11-19 16:31:34 -05:00
|
|
|
}
|
|
|
|
}
|
2021-01-15 13:47:39 -05:00
|
|
|
return Array.from(entries.values());
|
2020-11-19 16:31:34 -05:00
|
|
|
}
|
|
|
|
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
private convertToTemplateDocumentSpan<T extends ts.DocumentSpan>(
|
|
|
|
shimDocumentSpan: T, templateTypeChecker: TemplateTypeChecker, requiredNodeText?: string): T
|
|
|
|
|null {
|
|
|
|
const sf = this.strategy.getProgram().getSourceFile(shimDocumentSpan.fileName);
|
2020-12-16 14:13:34 -05:00
|
|
|
if (sf === undefined) {
|
|
|
|
return null;
|
|
|
|
}
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
const tcbNode = findTightestNode(sf, shimDocumentSpan.textSpan.start);
|
2020-12-16 14:13:34 -05:00
|
|
|
if (tcbNode === undefined ||
|
|
|
|
hasExpressionIdentifier(sf, tcbNode, ExpressionIdentifier.EVENT_PARAMETER)) {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
// If the reference result is the $event parameter in the subscribe/addEventListener
|
|
|
|
// function in the TCB, we want to filter this result out of the references. We really only
|
|
|
|
// want to return references to the parameter in the template itself.
|
2020-12-16 14:13:34 -05:00
|
|
|
return null;
|
|
|
|
}
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
// TODO(atscott): Determine how to consistently resolve paths. i.e. with the project
|
|
|
|
// serverHost or LSParseConfigHost in the adapter. We should have a better defined way to
|
|
|
|
// normalize paths.
|
2021-01-15 18:57:24 -05:00
|
|
|
const mapping = getTemplateLocationFromShimLocation(
|
|
|
|
templateTypeChecker, absoluteFrom(shimDocumentSpan.fileName),
|
|
|
|
shimDocumentSpan.textSpan.start);
|
2020-12-16 14:13:34 -05:00
|
|
|
if (mapping === null) {
|
|
|
|
return null;
|
|
|
|
}
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
|
2021-01-15 18:57:24 -05:00
|
|
|
const {span, templateUrl} = mapping;
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
if (requiredNodeText !== undefined && span.toString() !== requiredNodeText) {
|
2020-12-16 14:13:34 -05:00
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
...shimDocumentSpan,
|
2020-12-16 14:13:34 -05:00
|
|
|
fileName: templateUrl,
|
|
|
|
textSpan: toTextSpan(span),
|
|
|
|
};
|
|
|
|
}
|
2020-11-19 16:31:34 -05:00
|
|
|
}
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
|
2020-12-01 17:55:57 -05:00
|
|
|
function getRenameTextAndSpanAtPosition(node: TmplAstNode|AST, position: number):
|
|
|
|
{text: string, span: ParseSourceSpan|AbsoluteSourceSpan}|null {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
if (node instanceof TmplAstBoundAttribute || node instanceof TmplAstTextAttribute ||
|
|
|
|
node instanceof TmplAstBoundEvent) {
|
2020-12-01 17:55:57 -05:00
|
|
|
if (node.keySpan === undefined) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
return {text: node.name, span: node.keySpan};
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
} else if (node instanceof TmplAstVariable || node instanceof TmplAstReference) {
|
|
|
|
if (isWithin(position, node.keySpan)) {
|
2020-12-01 17:55:57 -05:00
|
|
|
return {text: node.keySpan.toString(), span: node.keySpan};
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
} else if (node.valueSpan && isWithin(position, node.valueSpan)) {
|
2020-12-01 17:55:57 -05:00
|
|
|
return {text: node.valueSpan.toString(), span: node.valueSpan};
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (node instanceof BindingPipe) {
|
|
|
|
// TODO(atscott): Add support for renaming pipes
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
if (node instanceof PropertyRead || node instanceof MethodCall || node instanceof PropertyWrite ||
|
|
|
|
node instanceof SafePropertyRead || node instanceof SafeMethodCall) {
|
2020-12-01 17:55:57 -05:00
|
|
|
return {text: node.name, span: node.nameSpan};
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
} else if (node instanceof LiteralPrimitive) {
|
2020-12-01 17:55:57 -05:00
|
|
|
const span = node.span;
|
|
|
|
const text = node.value;
|
|
|
|
if (typeof text === 'string') {
|
|
|
|
// The span of a string literal includes the quotes but they should be removed for renaming.
|
|
|
|
span.start += 1;
|
|
|
|
span.end -= 1;
|
|
|
|
}
|
|
|
|
return {text, span};
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 14:16:48 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
return null;
|
|
|
|
}
|
2021-01-15 13:47:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Creates a "key" for a rename/reference location by concatenating file name, span start, and span
|
|
|
|
* length. This allows us to de-duplicate template results when an item may appear several times
|
|
|
|
* in the TCB but map back to the same template location.
|
|
|
|
*/
|
|
|
|
function createLocationKey(ds: ts.DocumentSpan) {
|
|
|
|
return ds.fileName + ds.textSpan.start + ds.textSpan.length;
|
|
|
|
}
|