2020-04-29 18:08:22 -04:00
|
|
|
/**
|
|
|
|
* @license
|
2020-05-19 15:08:49 -04:00
|
|
|
* Copyright Google LLC All Rights Reserved.
|
2020-04-29 18:08:22 -04:00
|
|
|
*
|
|
|
|
* 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-04 11:33:27 -05:00
|
|
|
import {AbsoluteSourceSpan, AST, ParseSourceSpan, TmplAstBoundEvent, TmplAstNode} from '@angular/compiler';
|
2020-10-30 18:16:39 -04:00
|
|
|
import {CompilerOptions, ConfigurationHost, readConfiguration} from '@angular/compiler-cli';
|
2020-12-04 11:33:27 -05:00
|
|
|
import {NgCompiler} from '@angular/compiler-cli/src/ngtsc/core';
|
2021-01-13 17:52:29 -05:00
|
|
|
import {ErrorCode, ngErrorCode} from '@angular/compiler-cli/src/ngtsc/diagnostics';
|
2020-12-01 17:55:57 -05:00
|
|
|
import {absoluteFrom, absoluteFromSourceFile, AbsoluteFsPath} from '@angular/compiler-cli/src/ngtsc/file_system';
|
2021-03-19 10:56:13 -04:00
|
|
|
import {PerfPhase} from '@angular/compiler-cli/src/ngtsc/perf';
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
import {ProgramDriver} from '@angular/compiler-cli/src/ngtsc/program_driver';
|
2021-01-28 13:31:04 -05:00
|
|
|
import {isNamedClassDeclaration} from '@angular/compiler-cli/src/ngtsc/reflection';
|
2020-07-31 00:26:02 -04:00
|
|
|
import {TypeCheckShimGenerator} from '@angular/compiler-cli/src/ngtsc/typecheck';
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
import {OptimizeFor} from '@angular/compiler-cli/src/ngtsc/typecheck/api';
|
2020-12-04 11:33:27 -05:00
|
|
|
import {findFirstMatchingNode} from '@angular/compiler-cli/src/ngtsc/typecheck/src/comments';
|
2020-04-29 18:08:22 -04:00
|
|
|
import * as ts from 'typescript/lib/tsserverlibrary';
|
2021-01-28 13:31:04 -05:00
|
|
|
|
|
|
|
import {GetComponentLocationsForTemplateResponse, GetTcbResponse} from '../api';
|
2020-04-29 18:08:22 -04:00
|
|
|
|
2020-10-30 18:16:39 -04:00
|
|
|
import {LanguageServiceAdapter, LSParseConfigHost} from './adapters';
|
2020-10-09 19:46:55 -04:00
|
|
|
import {CompilerFactory} from './compiler_factory';
|
2020-11-18 20:30:52 -05:00
|
|
|
import {CompletionBuilder, CompletionNodeContext} from './completions';
|
2020-09-30 11:47:36 -04:00
|
|
|
import {DefinitionBuilder} from './definitions';
|
2020-09-28 14:26:07 -04:00
|
|
|
import {QuickInfoBuilder} from './quick_info';
|
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 {ReferencesAndRenameBuilder} from './references';
|
2021-04-12 11:10:03 -04:00
|
|
|
import {getSignatureHelp} from './signature_help';
|
2020-12-16 17:39:49 -05:00
|
|
|
import {getTargetAtPosition, TargetContext, TargetNodeKind} from './template_target';
|
2021-02-22 14:12:09 -05:00
|
|
|
import {findTightestNode, getClassDeclFromDecoratorProp, getPropertyAssignmentFromValue} from './ts_utils';
|
2020-10-13 13:28:15 -04:00
|
|
|
import {getTemplateInfoAtPosition, isTypeScriptFile} from './utils';
|
2020-09-28 14:26:07 -04:00
|
|
|
|
2021-03-02 18:46:11 -05:00
|
|
|
interface LanguageServiceConfig {
|
|
|
|
/**
|
|
|
|
* If true, enable `strictTemplates` in Angular compiler options regardless
|
|
|
|
* of its value in tsconfig.json.
|
|
|
|
*/
|
|
|
|
forceStrictTemplates?: true;
|
|
|
|
}
|
|
|
|
|
2020-04-29 18:08:22 -04:00
|
|
|
export class LanguageService {
|
2020-04-29 18:52:17 -04:00
|
|
|
private options: CompilerOptions;
|
2020-11-04 15:28:59 -05:00
|
|
|
readonly compilerFactory: CompilerFactory;
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
private readonly programDriver: ProgramDriver;
|
2020-09-30 13:59:38 -04:00
|
|
|
private readonly adapter: LanguageServiceAdapter;
|
2020-11-09 19:20:02 -05:00
|
|
|
private readonly parseConfigHost: LSParseConfigHost;
|
2020-04-29 18:52:17 -04:00
|
|
|
|
2021-01-13 17:52:29 -05:00
|
|
|
constructor(
|
2021-03-02 18:46:11 -05:00
|
|
|
private readonly project: ts.server.Project,
|
|
|
|
private readonly tsLS: ts.LanguageService,
|
|
|
|
private readonly config: LanguageServiceConfig,
|
|
|
|
) {
|
2020-10-30 18:16:39 -04:00
|
|
|
this.parseConfigHost = new LSParseConfigHost(project.projectService.host);
|
2021-03-02 18:46:11 -05:00
|
|
|
this.options = parseNgCompilerOptions(project, this.parseConfigHost, config);
|
2021-01-08 13:40:06 -05:00
|
|
|
logCompilerOptions(project, this.options);
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
this.programDriver = createProgramDriver(project);
|
2020-09-30 13:59:38 -04:00
|
|
|
this.adapter = new LanguageServiceAdapter(project);
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
this.compilerFactory = new CompilerFactory(this.adapter, this.programDriver, this.options);
|
2020-04-29 18:52:17 -04:00
|
|
|
this.watchConfigFile(project);
|
|
|
|
}
|
2020-04-29 18:08:22 -04:00
|
|
|
|
2020-11-09 19:20:02 -05:00
|
|
|
getCompilerOptions(): CompilerOptions {
|
|
|
|
return this.options;
|
|
|
|
}
|
|
|
|
|
2020-04-29 18:08:22 -04:00
|
|
|
getSemanticDiagnostics(fileName: string): ts.Diagnostic[] {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsDiagnostics, (compiler) => {
|
|
|
|
const ttc = compiler.getTemplateTypeChecker();
|
|
|
|
const diagnostics: ts.Diagnostic[] = [];
|
|
|
|
if (isTypeScriptFile(fileName)) {
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
const program = compiler.getCurrentProgram();
|
2021-03-19 10:56:13 -04:00
|
|
|
const sourceFile = program.getSourceFile(fileName);
|
|
|
|
if (sourceFile) {
|
|
|
|
const ngDiagnostics = compiler.getDiagnosticsForFile(sourceFile, OptimizeFor.SingleFile);
|
|
|
|
// There are several kinds of diagnostics returned by `NgCompiler` for a source file:
|
|
|
|
//
|
|
|
|
// 1. Angular-related non-template diagnostics from decorated classes within that
|
|
|
|
// file.
|
|
|
|
// 2. Template diagnostics for components with direct inline templates (a string
|
|
|
|
// literal).
|
|
|
|
// 3. Template diagnostics for components with indirect inline templates (templates
|
|
|
|
// computed
|
|
|
|
// by expression).
|
|
|
|
// 4. Template diagnostics for components with external templates.
|
|
|
|
//
|
|
|
|
// When showing diagnostics for a TS source file, we want to only include kinds 1 and
|
|
|
|
// 2 - those diagnostics which are reported at a location within the TS file itself.
|
|
|
|
// Diagnostics for external templates will be shown when editing that template file
|
|
|
|
// (the `else` block) below.
|
|
|
|
//
|
|
|
|
// Currently, indirect inline template diagnostics (kind 3) are not shown at all by
|
|
|
|
// the Language Service, because there is no sensible location in the user's code for
|
|
|
|
// them. Such templates are an edge case, though, and should not be common.
|
|
|
|
//
|
|
|
|
// TODO(alxhub): figure out a good user experience for indirect template diagnostics
|
|
|
|
// and show them from within the Language Service.
|
|
|
|
diagnostics.push(...ngDiagnostics.filter(
|
|
|
|
diag => diag.file !== undefined && diag.file.fileName === sourceFile.fileName));
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
const components = compiler.getComponentsWithTemplateFile(fileName);
|
|
|
|
for (const component of components) {
|
|
|
|
if (ts.isClassDeclaration(component)) {
|
|
|
|
diagnostics.push(...ttc.getDiagnosticsForComponent(component));
|
|
|
|
}
|
2020-09-30 13:59:38 -04:00
|
|
|
}
|
2020-07-31 00:26:02 -04:00
|
|
|
}
|
2021-03-19 10:56:13 -04:00
|
|
|
return diagnostics;
|
|
|
|
});
|
2020-07-31 00:26:02 -04:00
|
|
|
}
|
|
|
|
|
2020-09-30 11:47:36 -04:00
|
|
|
getDefinitionAndBoundSpan(fileName: string, position: number): ts.DefinitionInfoAndBoundSpan
|
|
|
|
|undefined {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsDefinition, (compiler) => {
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
if (!isInAngularContext(compiler.getCurrentProgram(), fileName, position)) {
|
2021-02-22 14:12:09 -05:00
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
return new DefinitionBuilder(this.tsLS, compiler)
|
|
|
|
.getDefinitionAndBoundSpan(fileName, position);
|
|
|
|
});
|
2020-09-30 11:47:36 -04:00
|
|
|
}
|
|
|
|
|
2020-10-02 16:54:18 -04:00
|
|
|
getTypeDefinitionAtPosition(fileName: string, position: number):
|
|
|
|
readonly ts.DefinitionInfo[]|undefined {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsDefinition, (compiler) => {
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
if (!isTemplateContext(compiler.getCurrentProgram(), fileName, position)) {
|
2021-02-22 14:12:09 -05:00
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
return new DefinitionBuilder(this.tsLS, compiler)
|
|
|
|
.getTypeDefinitionsAtPosition(fileName, position);
|
|
|
|
});
|
2020-10-02 16:54:18 -04:00
|
|
|
}
|
|
|
|
|
2020-09-28 14:26:07 -04:00
|
|
|
getQuickInfoAtPosition(fileName: string, position: number): ts.QuickInfo|undefined {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsQuickInfo, (compiler) => {
|
|
|
|
return this.getQuickInfoAtPositionImpl(fileName, position, compiler);
|
|
|
|
});
|
|
|
|
}
|
2020-12-16 17:39:49 -05:00
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
private getQuickInfoAtPositionImpl(
|
|
|
|
fileName: string,
|
|
|
|
position: number,
|
|
|
|
compiler: NgCompiler,
|
|
|
|
): ts.QuickInfo|undefined {
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
if (!isTemplateContext(compiler.getCurrentProgram(), fileName, position)) {
|
2021-03-19 10:56:13 -04:00
|
|
|
return undefined;
|
|
|
|
}
|
2021-02-22 18:29:28 -05:00
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
const templateInfo = getTemplateInfoAtPosition(fileName, position, compiler);
|
|
|
|
if (templateInfo === undefined) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
const positionDetails = getTargetAtPosition(templateInfo.template, position);
|
|
|
|
if (positionDetails === null) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Because we can only show 1 quick info, just use the bound attribute if the target is a two
|
|
|
|
// way binding. We may consider concatenating additional display parts from the other target
|
|
|
|
// nodes or representing the two way binding in some other manner in the future.
|
|
|
|
const node = positionDetails.context.kind === TargetNodeKind.TwoWayBindingContext ?
|
|
|
|
positionDetails.context.nodes[0] :
|
|
|
|
positionDetails.context.node;
|
|
|
|
return new QuickInfoBuilder(this.tsLS, compiler, templateInfo.component, node).get();
|
2020-04-29 18:08:22 -04:00
|
|
|
}
|
2020-04-29 18:52:17 -04:00
|
|
|
|
2020-11-19 16:31:34 -05:00
|
|
|
getReferencesAtPosition(fileName: string, position: number): ts.ReferenceEntry[]|undefined {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsReferencesAndRenames, (compiler) => {
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
return new ReferencesAndRenameBuilder(this.programDriver, this.tsLS, compiler)
|
2021-03-19 10:56:13 -04:00
|
|
|
.getReferencesAtPosition(fileName, 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
|
|
|
}
|
|
|
|
|
2020-12-01 17:55:57 -05:00
|
|
|
getRenameInfo(fileName: string, position: number): ts.RenameInfo {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsReferencesAndRenames, (compiler) => {
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
const renameInfo = new ReferencesAndRenameBuilder(this.programDriver, this.tsLS, compiler)
|
2021-03-19 10:56:13 -04:00
|
|
|
.getRenameInfo(absoluteFrom(fileName), position);
|
|
|
|
if (!renameInfo.canRename) {
|
|
|
|
return renameInfo;
|
|
|
|
}
|
2020-12-01 17:55:57 -05:00
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
const quickInfo = this.getQuickInfoAtPositionImpl(fileName, position, compiler) ??
|
|
|
|
this.tsLS.getQuickInfoAtPosition(fileName, position);
|
|
|
|
const kind = quickInfo?.kind ?? ts.ScriptElementKind.unknown;
|
|
|
|
const kindModifiers = quickInfo?.kindModifiers ?? ts.ScriptElementKind.unknown;
|
|
|
|
return {...renameInfo, kind, kindModifiers};
|
|
|
|
});
|
2020-12-01 17:55:57 -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
|
|
|
findRenameLocations(fileName: string, position: number): readonly ts.RenameLocation[]|undefined {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsReferencesAndRenames, (compiler) => {
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
return new ReferencesAndRenameBuilder(this.programDriver, this.tsLS, compiler)
|
2021-03-19 10:56:13 -04:00
|
|
|
.findRenameLocations(fileName, position);
|
|
|
|
});
|
2020-11-19 16:31:34 -05:00
|
|
|
}
|
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
private getCompletionBuilder(fileName: string, position: number, compiler: NgCompiler):
|
2020-10-13 14:14:13 -04:00
|
|
|
CompletionBuilder<TmplAstNode|AST>|null {
|
|
|
|
const templateInfo = getTemplateInfoAtPosition(fileName, position, compiler);
|
|
|
|
if (templateInfo === undefined) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
const positionDetails = getTargetAtPosition(templateInfo.template, position);
|
|
|
|
if (positionDetails === null) {
|
|
|
|
return null;
|
|
|
|
}
|
2020-12-16 17:39:49 -05:00
|
|
|
|
2020-12-17 17:44:27 -05:00
|
|
|
// For two-way bindings, we actually only need to be concerned with the bound attribute because
|
|
|
|
// the bindings in the template are written with the attribute name, not the event name.
|
2020-12-16 17:39:49 -05:00
|
|
|
const node = positionDetails.context.kind === TargetNodeKind.TwoWayBindingContext ?
|
|
|
|
positionDetails.context.nodes[0] :
|
|
|
|
positionDetails.context.node;
|
2020-10-13 14:14:13 -04:00
|
|
|
return new CompletionBuilder(
|
2021-03-17 14:31:57 -04:00
|
|
|
this.tsLS, compiler, templateInfo.component, node, positionDetails);
|
2020-10-13 14:14:13 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
getCompletionsAtPosition(
|
|
|
|
fileName: string, position: number, options: ts.GetCompletionsAtPositionOptions|undefined):
|
|
|
|
ts.WithMetadata<ts.CompletionInfo>|undefined {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsCompletions, (compiler) => {
|
|
|
|
return this.getCompletionsAtPositionImpl(fileName, position, options, compiler);
|
2021-02-22 14:12:09 -05:00
|
|
|
});
|
2020-10-13 14:14:13 -04:00
|
|
|
}
|
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
private getCompletionsAtPositionImpl(
|
|
|
|
fileName: string, position: number, options: ts.GetCompletionsAtPositionOptions|undefined,
|
|
|
|
compiler: NgCompiler): ts.WithMetadata<ts.CompletionInfo>|undefined {
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
if (!isTemplateContext(compiler.getCurrentProgram(), fileName, position)) {
|
2021-03-19 10:56:13 -04:00
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
|
|
|
const builder = this.getCompletionBuilder(fileName, position, compiler);
|
|
|
|
if (builder === null) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
return builder.getCompletionsAtPosition(options);
|
|
|
|
}
|
|
|
|
|
2020-10-13 14:14:13 -04:00
|
|
|
getCompletionEntryDetails(
|
|
|
|
fileName: string, position: number, entryName: string,
|
|
|
|
formatOptions: ts.FormatCodeOptions|ts.FormatCodeSettings|undefined,
|
|
|
|
preferences: ts.UserPreferences|undefined): ts.CompletionEntryDetails|undefined {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsCompletions, (compiler) => {
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
if (!isTemplateContext(compiler.getCurrentProgram(), fileName, position)) {
|
2021-02-22 14:12:09 -05:00
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
const builder = this.getCompletionBuilder(fileName, position, compiler);
|
2021-02-22 14:12:09 -05:00
|
|
|
if (builder === null) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
return builder.getCompletionEntryDetails(entryName, formatOptions, preferences);
|
|
|
|
});
|
2020-10-13 14:14:13 -04:00
|
|
|
}
|
|
|
|
|
2021-04-12 11:10:03 -04:00
|
|
|
getSignatureHelpItems(fileName: string, position: number, options?: ts.SignatureHelpItemsOptions):
|
|
|
|
ts.SignatureHelpItems|undefined {
|
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsSignatureHelp, compiler => {
|
|
|
|
if (!isTemplateContext(compiler.getCurrentProgram(), fileName, position)) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
|
|
|
return getSignatureHelp(compiler, this.tsLS, fileName, position, options);
|
|
|
|
|
|
|
|
return undefined;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2020-11-18 20:30:52 -05:00
|
|
|
getCompletionEntrySymbol(fileName: string, position: number, entryName: string): ts.Symbol
|
|
|
|
|undefined {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsCompletions, (compiler) => {
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
if (!isTemplateContext(compiler.getCurrentProgram(), fileName, position)) {
|
2021-02-22 14:12:09 -05:00
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
const builder = this.getCompletionBuilder(fileName, position, compiler);
|
2021-02-22 14:12:09 -05:00
|
|
|
if (builder === null) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
const result = builder.getCompletionEntrySymbol(entryName);
|
|
|
|
return result;
|
|
|
|
});
|
2020-10-13 14:14:13 -04:00
|
|
|
}
|
|
|
|
|
2021-01-28 13:31:04 -05:00
|
|
|
getComponentLocationsForTemplate(fileName: string): GetComponentLocationsForTemplateResponse {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing<GetComponentLocationsForTemplateResponse>(
|
|
|
|
PerfPhase.LsComponentLocations, (compiler) => {
|
|
|
|
const components = compiler.getComponentsWithTemplateFile(fileName);
|
|
|
|
const componentDeclarationLocations: ts.DocumentSpan[] =
|
|
|
|
Array.from(components.values()).map(c => {
|
|
|
|
let contextSpan: ts.TextSpan|undefined = undefined;
|
|
|
|
let textSpan: ts.TextSpan;
|
|
|
|
if (isNamedClassDeclaration(c)) {
|
|
|
|
textSpan = ts.createTextSpanFromBounds(c.name.getStart(), c.name.getEnd());
|
|
|
|
contextSpan = ts.createTextSpanFromBounds(c.getStart(), c.getEnd());
|
|
|
|
} else {
|
|
|
|
textSpan = ts.createTextSpanFromBounds(c.getStart(), c.getEnd());
|
|
|
|
}
|
|
|
|
return {
|
|
|
|
fileName: c.getSourceFile().fileName,
|
|
|
|
textSpan,
|
|
|
|
contextSpan,
|
|
|
|
};
|
|
|
|
});
|
|
|
|
return componentDeclarationLocations;
|
|
|
|
});
|
2021-01-28 13:31:04 -05:00
|
|
|
}
|
|
|
|
|
2021-02-22 17:14:31 -05:00
|
|
|
getTcb(fileName: string, position: number): GetTcbResponse|undefined {
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing<GetTcbResponse|undefined>(PerfPhase.LsTcb, compiler => {
|
2020-12-04 11:33:27 -05:00
|
|
|
const templateInfo = getTemplateInfoAtPosition(fileName, position, compiler);
|
|
|
|
if (templateInfo === undefined) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
const tcb = compiler.getTemplateTypeChecker().getTypeCheckBlock(templateInfo.component);
|
|
|
|
if (tcb === null) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
const sf = tcb.getSourceFile();
|
|
|
|
|
|
|
|
let selections: ts.TextSpan[] = [];
|
|
|
|
const target = getTargetAtPosition(templateInfo.template, position);
|
|
|
|
if (target !== null) {
|
|
|
|
let selectionSpans: Array<ParseSourceSpan|AbsoluteSourceSpan>;
|
|
|
|
if ('nodes' in target.context) {
|
|
|
|
selectionSpans = target.context.nodes.map(n => n.sourceSpan);
|
|
|
|
} else {
|
|
|
|
selectionSpans = [target.context.node.sourceSpan];
|
|
|
|
}
|
|
|
|
const selectionNodes: ts.Node[] =
|
|
|
|
selectionSpans
|
|
|
|
.map(s => findFirstMatchingNode(tcb, {
|
|
|
|
withSpan: s,
|
|
|
|
filter: (node: ts.Node): node is ts.Node => true,
|
|
|
|
}))
|
|
|
|
.filter((n): n is ts.Node => n !== null);
|
|
|
|
|
|
|
|
selections = selectionNodes.map(n => {
|
|
|
|
return {
|
|
|
|
start: n.getStart(sf),
|
|
|
|
length: n.getEnd() - n.getStart(sf),
|
|
|
|
};
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
|
|
|
fileName: sf.fileName,
|
|
|
|
content: sf.getFullText(),
|
|
|
|
selections,
|
|
|
|
};
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
/**
|
|
|
|
* Provides an instance of the `NgCompiler` and traces perf results. Perf results are logged only
|
|
|
|
* if the log level is verbose or higher. This method is intended to be called once per public
|
|
|
|
* method call.
|
|
|
|
*
|
|
|
|
* Here is an example of the log output.
|
|
|
|
*
|
|
|
|
* Perf 245 [16:16:39.353] LanguageService#getQuickInfoAtPosition(): {"events":{},"phases":{
|
|
|
|
* "Unaccounted":379,"TtcSymbol":4},"memory":{}}
|
|
|
|
*
|
|
|
|
* Passing name of caller instead of using `arguments.caller` because 'caller', 'callee', and
|
|
|
|
* 'arguments' properties may not be accessed in strict mode.
|
|
|
|
*
|
|
|
|
* @param phase the `PerfPhase` to execute the `p` callback in
|
|
|
|
* @param p callback to be run synchronously with an instance of the `NgCompiler` as argument
|
|
|
|
* @return the result of running the `p` callback
|
|
|
|
*/
|
|
|
|
private withCompilerAndPerfTracing<T>(phase: PerfPhase, p: (compiler: NgCompiler) => T): T {
|
2021-01-21 18:54:40 -05:00
|
|
|
const compiler = this.compilerFactory.getOrCreate();
|
2021-03-19 10:56:13 -04:00
|
|
|
const result = compiler.perfRecorder.inPhase(phase, () => p(compiler));
|
|
|
|
const logger = this.project.projectService.logger;
|
|
|
|
if (logger.hasLevel(ts.server.LogLevel.verbose)) {
|
|
|
|
logger.perftrc(`LanguageService#${PerfPhase[phase]}: ${
|
|
|
|
JSON.stringify(compiler.perfRecorder.finalize())}`);
|
|
|
|
}
|
|
|
|
|
2020-12-04 11:33:27 -05:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2021-01-13 17:52:29 -05:00
|
|
|
getCompilerOptionsDiagnostics(): ts.Diagnostic[] {
|
|
|
|
const project = this.project;
|
|
|
|
if (!(project instanceof ts.server.ConfiguredProject)) {
|
|
|
|
return [];
|
|
|
|
}
|
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
return this.withCompilerAndPerfTracing(PerfPhase.LsDiagnostics, (compiler) => {
|
|
|
|
const diagnostics: ts.Diagnostic[] = [];
|
|
|
|
const configSourceFile = ts.readJsonConfigFile(
|
|
|
|
project.getConfigFilePath(), (path: string) => project.readFile(path));
|
|
|
|
|
|
|
|
if (!this.options.strictTemplates && !this.options.fullTemplateTypeCheck) {
|
|
|
|
diagnostics.push({
|
|
|
|
messageText: 'Some language features are not available. ' +
|
|
|
|
'To access all features, enable `strictTemplates` in `angularCompilerOptions`.',
|
|
|
|
category: ts.DiagnosticCategory.Suggestion,
|
|
|
|
code: ngErrorCode(ErrorCode.SUGGEST_STRICT_TEMPLATES),
|
|
|
|
file: configSourceFile,
|
|
|
|
start: undefined,
|
|
|
|
length: undefined,
|
|
|
|
});
|
|
|
|
}
|
2021-01-13 17:52:29 -05:00
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
diagnostics.push(...compiler.getOptionDiagnostics());
|
2021-01-13 17:52:29 -05:00
|
|
|
|
2021-03-19 10:56:13 -04:00
|
|
|
return diagnostics;
|
|
|
|
});
|
2021-01-13 17:52:29 -05:00
|
|
|
}
|
|
|
|
|
2020-04-29 18:52:17 -04:00
|
|
|
private watchConfigFile(project: ts.server.Project) {
|
|
|
|
// TODO: Check the case when the project is disposed. An InferredProject
|
|
|
|
// could be disposed when a tsconfig.json is added to the workspace,
|
|
|
|
// in which case it becomes a ConfiguredProject (or vice-versa).
|
|
|
|
// We need to make sure that the FileWatcher is closed.
|
|
|
|
if (!(project instanceof ts.server.ConfiguredProject)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
const {host} = project.projectService;
|
|
|
|
host.watchFile(
|
|
|
|
project.getConfigFilePath(), (fileName: string, eventKind: ts.FileWatcherEventKind) => {
|
|
|
|
project.log(`Config file changed: ${fileName}`);
|
|
|
|
if (eventKind === ts.FileWatcherEventKind.Changed) {
|
2021-03-02 18:46:11 -05:00
|
|
|
this.options = parseNgCompilerOptions(project, this.parseConfigHost, this.config);
|
2021-01-08 13:40:06 -05:00
|
|
|
logCompilerOptions(project, this.options);
|
2020-04-29 18:52:17 -04:00
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-01-08 13:40:06 -05:00
|
|
|
function logCompilerOptions(project: ts.server.Project, options: CompilerOptions) {
|
|
|
|
const {logger} = project.projectService;
|
|
|
|
const projectName = project.getProjectName();
|
|
|
|
logger.info(`Angular compiler options for ${projectName}: ` + JSON.stringify(options, null, 2));
|
|
|
|
}
|
|
|
|
|
2020-10-30 18:16:39 -04:00
|
|
|
function parseNgCompilerOptions(
|
2021-03-02 18:46:11 -05:00
|
|
|
project: ts.server.Project, host: ConfigurationHost,
|
|
|
|
config: LanguageServiceConfig): CompilerOptions {
|
2020-11-09 19:20:02 -05:00
|
|
|
if (!(project instanceof ts.server.ConfiguredProject)) {
|
|
|
|
return {};
|
2020-04-29 18:52:17 -04:00
|
|
|
}
|
2020-11-09 19:20:02 -05:00
|
|
|
const {options, errors} =
|
|
|
|
readConfiguration(project.getConfigFilePath(), /* existingOptions */ undefined, host);
|
|
|
|
if (errors.length > 0) {
|
2020-10-30 18:16:39 -04:00
|
|
|
project.setProjectErrors(errors);
|
2020-11-09 19:20:02 -05:00
|
|
|
}
|
|
|
|
|
2021-01-08 13:36:46 -05:00
|
|
|
// Projects loaded into the Language Service often include test files which are not part of the
|
|
|
|
// app's main compilation unit, and these test files often include inline NgModules that declare
|
|
|
|
// components from the app. These declarations conflict with the main declarations of such
|
|
|
|
// components in the app's NgModules. This conflict is not normally present during regular
|
|
|
|
// compilation because the app and the tests are part of separate compilation units.
|
|
|
|
//
|
|
|
|
// As a temporary mitigation of this problem, we instruct the compiler to ignore classes which
|
|
|
|
// are not exported. In many cases, this ensures the test NgModules are ignored by the compiler
|
|
|
|
// and only the real component declaration is used.
|
|
|
|
options.compileNonExportedClasses = false;
|
|
|
|
|
2021-03-02 18:46:11 -05:00
|
|
|
// If `forceStrictTemplates` is true, always enable `strictTemplates`
|
|
|
|
// regardless of its value in tsconfig.json.
|
|
|
|
if (config.forceStrictTemplates === true) {
|
|
|
|
options.strictTemplates = true;
|
|
|
|
}
|
|
|
|
|
2020-11-09 19:20:02 -05:00
|
|
|
return options;
|
2020-04-29 18:08:22 -04:00
|
|
|
}
|
2020-07-31 00:26:02 -04:00
|
|
|
|
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291)
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close #41291
2021-03-19 20:06:10 -04:00
|
|
|
function createProgramDriver(project: ts.server.Project): ProgramDriver {
|
2020-07-31 00:26:02 -04:00
|
|
|
return {
|
|
|
|
supportsInlineOperations: false,
|
|
|
|
getProgram(): ts.Program {
|
|
|
|
const program = project.getLanguageService().getProgram();
|
|
|
|
if (!program) {
|
|
|
|
throw new Error('Language service does not have a program!');
|
|
|
|
}
|
|
|
|
return program;
|
|
|
|
},
|
|
|
|
updateFiles(contents: Map<AbsoluteFsPath, string>) {
|
|
|
|
for (const [fileName, newText] of contents) {
|
|
|
|
const scriptInfo = getOrCreateTypeCheckScriptInfo(project, fileName);
|
|
|
|
const snapshot = scriptInfo.getSnapshot();
|
|
|
|
const length = snapshot.getLength();
|
|
|
|
scriptInfo.editContent(0, length, newText);
|
|
|
|
}
|
|
|
|
},
|
2021-04-07 11:38:47 -04:00
|
|
|
getSourceFileVersion(sf: ts.SourceFile): string {
|
|
|
|
return project.getScriptVersion(sf.fileName);
|
|
|
|
}
|
2020-07-31 00:26:02 -04:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
function getOrCreateTypeCheckScriptInfo(
|
|
|
|
project: ts.server.Project, tcf: string): ts.server.ScriptInfo {
|
|
|
|
// First check if there is already a ScriptInfo for the tcf
|
|
|
|
const {projectService} = project;
|
|
|
|
let scriptInfo = projectService.getScriptInfo(tcf);
|
|
|
|
if (!scriptInfo) {
|
|
|
|
// ScriptInfo needs to be opened by client to be able to set its user-defined
|
|
|
|
// content. We must also provide file content, otherwise the service will
|
|
|
|
// attempt to fetch the content from disk and fail.
|
|
|
|
scriptInfo = projectService.getOrCreateScriptInfoForNormalizedPath(
|
|
|
|
ts.server.toNormalizedPath(tcf),
|
2020-12-16 14:15:14 -05:00
|
|
|
true, // openedByClient
|
|
|
|
'', // fileContent
|
|
|
|
// script info added by plugins should be marked as external, see
|
|
|
|
// https://github.com/microsoft/TypeScript/blob/b217f22e798c781f55d17da72ed099a9dee5c650/src/compiler/program.ts#L1897-L1899
|
|
|
|
ts.ScriptKind.External, // scriptKind
|
2020-07-31 00:26:02 -04:00
|
|
|
);
|
|
|
|
if (!scriptInfo) {
|
|
|
|
throw new Error(`Failed to create script info for ${tcf}`);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// Add ScriptInfo to project if it's missing. A ScriptInfo needs to be part of
|
|
|
|
// the project so that it becomes part of the program.
|
|
|
|
if (!project.containsScriptInfo(scriptInfo)) {
|
|
|
|
project.addRoot(scriptInfo);
|
|
|
|
}
|
|
|
|
return scriptInfo;
|
|
|
|
}
|
2020-11-18 20:30:52 -05:00
|
|
|
|
2021-02-22 14:12:09 -05:00
|
|
|
function isTemplateContext(program: ts.Program, fileName: string, position: number): boolean {
|
|
|
|
if (!isTypeScriptFile(fileName)) {
|
|
|
|
// If we aren't in a TS file, we must be in an HTML file, which we treat as template context
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
const node = findTightestNodeAtPosition(program, fileName, position);
|
|
|
|
if (node === undefined) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
let asgn = getPropertyAssignmentFromValue(node, 'template');
|
|
|
|
if (asgn === null) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return getClassDeclFromDecoratorProp(asgn) !== null;
|
|
|
|
}
|
|
|
|
|
|
|
|
function isInAngularContext(program: ts.Program, fileName: string, position: number) {
|
|
|
|
if (!isTypeScriptFile(fileName)) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
const node = findTightestNodeAtPosition(program, fileName, position);
|
|
|
|
if (node === undefined) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
const asgn = getPropertyAssignmentFromValue(node, 'template') ??
|
|
|
|
getPropertyAssignmentFromValue(node, 'templateUrl') ??
|
|
|
|
getPropertyAssignmentFromValue(node.parent, 'styleUrls');
|
|
|
|
return asgn !== null && getClassDeclFromDecoratorProp(asgn) !== null;
|
|
|
|
}
|
|
|
|
|
|
|
|
function findTightestNodeAtPosition(program: ts.Program, fileName: string, position: number) {
|
|
|
|
const sourceFile = program.getSourceFile(fileName);
|
|
|
|
if (sourceFile === undefined) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
|
|
|
return findTightestNode(sourceFile, position);
|
2021-02-22 17:14:31 -05:00
|
|
|
}
|