perf(compiler-cli): perform template type-checking incrementally (#36211)

This optimization builds on a lot of prior work to finally make type-
checking of templates incremental.

Incrementality requires two main components:
- the ability to reuse work from a prior compilation.
- the ability to know when changes in the current program invalidate that
  prior work.

Prior to this commit, on every type-checking pass the compiler would
generate new .ngtypecheck files for each original input file in the program.

1. (Build #1 main program): empty .ngtypecheck files generated for each
   original input file.

2. (Build #1 type-check program): .ngtypecheck contents overridden for those
   which have corresponding components that need type-checked.

3. (Build #2 main program): throw away old .ngtypecheck files and generate
   new empty ones.

4. (Build #2 type-check program): same as step 2.

With this commit, the `IncrementalDriver` now tracks template type-checking
_metadata_ for each input file. The metadata contains information about
source mappings for generated type-checking code, as well as some
diagnostics which were discovered at type-check analysis time. The actual
type-checking code is stored in the TypeScript AST for type-checking files,
which is now re-used between programs as follows:

1. (Build #1 main program): empty .ngtypecheck files generated for each
   original input file.

2. (Build #1 type-check program): .ngtypecheck contents overridden for those
   which have corresponding components that need type-checked, and the
   metadata registered in the `IncrementalDriver`.

3. (Build #2 main program): The `TypeCheckShimGenerator` now reuses _all_
   .ngtypecheck `ts.SourceFile` shims from build #1's type-check program in
   the construction of build #2's main program. Some of the contents of
   these files might be stale (if a component's template changed, for
   example), but wholesale reuse here prevents unnecessary changes in the
   contents of the program at this point and makes TypeScript's job a lot
   easier.

4. (Build #2 type-check program): For those input files which have not
   "logically changed" (meaning components within are semantically the same
   as they were before), the compiler will re-use the type-check file
   metadata from build #1, and _not_ generate a new .ngtypecheck shim.
   For components which have logically changed or where the previous
   .ngtypecheck contents cannot otherwise be reused, code generation happens
   as before.

PR Close #36211

Author: alxhub

packages/compiler-cli/ngcc/src/analysis/ngcc_trait_compiler.ts

@@ -82,8 +82,12 @@ export class NgccTraitCompiler extends TraitCompiler {
   }
 }
 
-class NoIncrementalBuild implements IncrementalBuild<any> {
+class NoIncrementalBuild implements IncrementalBuild<any, any> {
   priorWorkFor(sf: ts.SourceFile): any[]|null {
     return null;
   }
+
+  priorTypeCheckingResultsFor(): null {
+    return null;
+  }
 }

packages/compiler-cli/src/ngtsc/core/src/compiler.ts

@@ -482,8 +482,6 @@ export class NgCompiler {
   }
 
   private getTemplateDiagnostics(): ReadonlyArray<ts.Diagnostic> {
-    const host = this.host;
-
     // Skip template type-checking if it's disabled.
     if (this.options.ivyTemplateTypeCheck === false && !this.fullTemplateTypeCheck) {
       return [];
@@ -493,7 +491,8 @@ export class NgCompiler {
 
     // Execute the typeCheck phase of each decorator in the program.
     const prepSpan = this.perfRecorder.start('typeCheckPrep');
-    compilation.templateTypeChecker.refresh();
+    const results = compilation.templateTypeChecker.refresh();
+    this.incrementalDriver.recordSuccessfulTypeCheck(results.perFileData);
     this.perfRecorder.stop(prepSpan);
 
     // Get the diagnostics.
@@ -728,7 +727,7 @@ export class NgCompiler {
 
     const templateTypeChecker = new TemplateTypeChecker(
         this.tsProgram, this.typeCheckingProgramStrategy, traitCompiler,
-        this.getTypeCheckingConfig(), refEmitter, reflector);
+        this.getTypeCheckingConfig(), refEmitter, reflector, this.incrementalDriver);
 
     return {
       isCore,

packages/compiler-cli/src/ngtsc/incremental/BUILD.bazel

@@ -16,6 +16,7 @@ ts_library(
         "//packages/compiler-cli/src/ngtsc/reflection",
         "//packages/compiler-cli/src/ngtsc/scope",
         "//packages/compiler-cli/src/ngtsc/transform",
+        "//packages/compiler-cli/src/ngtsc/typecheck",
         "//packages/compiler-cli/src/ngtsc/util",
         "@npm//typescript",
     ],

packages/compiler-cli/src/ngtsc/incremental/README.md

@@ -33,6 +33,22 @@ If the file is logically unchanged, ngtsc will reuse the previous analysis and o
 
 If the file is logically changed, ngtsc will re-analyze it.
 
+## Reuse of template type-checking code
+
+Generally speaking, the generation of a template type-checking "shim" for an input component file is a time-consuming operation. Such generation produces several outputs:
+
+1) The text of the template type-checking shim file, which can later be fed to TypeScript for the production of raw diagnostics.
+2) Metadata regarding source mappings within the template type-checking shim, which can be used to convert the raw diagnostics into mapped template diagnostics.
+3) "Construction" diagnostics, which are diagnostics produced as a side effect of generation of the shim itself.
+
+When a component file is logically unchanged, ngtsc attempts to reuse this generation work. As part of creating both the new emit program and template type-checking program, the `ts.SourceFile` of the shim for the component file is included directly and not re-generated.
+
+At the same time, the metadata and construction diagnostics are passed via the incremental build system. When TS gets diagnostics for the shim file, this metadata is used to convert them into mapped template diagnostics for delivery to the user.
+
+### Limitations on template type-checking reuse
+
+In certain cases the template type-checking system is unable to use the existing shim code. If the component is logically changed, the shim is regenerated in case its contents may have changed. If generating the shim itself required the use of any "inline" code (type-checking code which needs to be inserted into the component file instead for some reason), it also becomes ineligible for reuse.
+
 ## Skipping emit
 
 ngtsc makes a decision to skip the emit of a file if it can prove that the contents of the file will not have changed since the last good compilation. To prove this, two conditions must be true.
@@ -135,13 +151,4 @@ Currently the compiler does not distinguish these two cases, and conservatively
 
 ## Skipping template type-checking
 
-For certain kinds of changes, it may be possible to avoid the cost of generating and checking template type-checking files. Several levels of this can be imagined.
-
-For resource-only changes, only the component(s) which have changed resources need to be re-checked. No other components could be affected, so previously produced diagnostics are still valid.
-
-For arbitrary source changes, things get a bit more complicated. A change to any .ts file could affect types anywhere in the program (think `declare global ...`). If a set of affected components can be determined (perhaps via the import graph that the cycle analyzer extracts?) and it can be proven that the change does not impact any global types (exactly how to do this is left as an exercise for  the reader), then type-checking could be skipped for other components in the mix.
-
-If the above is too complex, then certain kinds of type changes might allow for the reuse of the text of some template type-checking files, if it can be proven that none of the inputs to their generation have changed. This is useful for two very important reasons.
-
-1) Generating (and subsequently parsing) the template type-checking files is expensive.
-2) Under ideal conditions, after an initial template type-checking program is created, it may be possible to reuse it for emit _and_ type-checking in subsequent builds. This would be a pretty advanced optimization but would save creation of a second `ts.Program` on each valid rebuild.
+Under ideal conditions, after an initial template type-checking program is created, it may be possible to reuse it for emit _and_ type-checking in subsequent builds. This would be a pretty advanced optimization but would save creation of a second `ts.Program` on each valid rebuild.

packages/compiler-cli/src/ngtsc/incremental/api.ts

@@ -14,12 +14,19 @@ import {AbsoluteFsPath} from '../file_system';
  *
  * `W` is a generic type representing a unit of work. This is generic to avoid a cyclic dependency
  * between the incremental engine API definition and its consumer(s).
+ * `T` is a generic type representing template type-checking data for a particular file, which is
+ * generic for the same reason.
  */
-export interface IncrementalBuild<W> {
+export interface IncrementalBuild<W, T> {
   /**
    * Retrieve the prior analysis work, if any, done for the given source file.
    */
   priorWorkFor(sf: ts.SourceFile): W[]|null;
+
+  /**
+   * Retrieve the prior type-checking work, if any, that's been done for the given source file.
+   */
+  priorTypeCheckingResultsFor(sf: ts.SourceFile): T|null;
 }
 
 /**

packages/compiler-cli/src/ngtsc/incremental/src/noop.ts

@@ -8,6 +8,7 @@
 
 import {IncrementalBuild} from '../api';
 
-export const NOOP_INCREMENTAL_BUILD: IncrementalBuild<any> = {
-  priorWorkFor: () => null
+export const NOOP_INCREMENTAL_BUILD: IncrementalBuild<any, any> = {
+  priorWorkFor: () => null,
+  priorTypeCheckingResultsFor: () => null,
 };

packages/compiler-cli/src/ngtsc/incremental/src/state.ts

@@ -8,16 +8,17 @@
 
 import * as ts from 'typescript';
 
-import {absoluteFrom, AbsoluteFsPath} from '../../file_system';
+import {absoluteFrom, absoluteFromSourceFile, AbsoluteFsPath} from '../../file_system';
 import {ClassRecord, TraitCompiler} from '../../transform';
+import {FileTypeCheckingData} from '../../typecheck/src/context';
 import {IncrementalBuild} from '../api';
 
 import {FileDependencyGraph} from './dependency_tracking';
 
 /**
  * Drives an incremental build, by tracking changes and determining which files need to be emitted.
  */
-export class IncrementalDriver implements IncrementalBuild<ClassRecord> {
+export class IncrementalDriver implements IncrementalBuild<ClassRecord, FileTypeCheckingData> {
   /**
    * State of the current build.
    *
@@ -190,10 +191,21 @@ export class IncrementalDriver implements IncrementalBuild<ClassRecord> {
       lastGood: {
         depGraph: this.depGraph,
         traitCompiler: traitCompiler,
-      }
+        typeCheckingResults: null,
+      },
+
+      priorTypeCheckingResults:
+          this.state.lastGood !== null ? this.state.lastGood.typeCheckingResults : null,
     };
   }
 
+  recordSuccessfulTypeCheck(results: Map<AbsoluteFsPath, FileTypeCheckingData>): void {
+    if (this.state.lastGood === null || this.state.kind !== BuildStateKind.Analyzed) {
+      return;
+    }
+    this.state.lastGood.typeCheckingResults = results;
+  }
+
   recordSuccessfulEmit(sf: ts.SourceFile): void {
     this.state.pendingEmit.delete(sf.fileName);
   }
@@ -214,6 +226,28 @@ export class IncrementalDriver implements IncrementalBuild<ClassRecord> {
       return this.state.lastGood.traitCompiler.recordsFor(sf);
     }
   }
+
+  priorTypeCheckingResultsFor(sf: ts.SourceFile): FileTypeCheckingData|null {
+    if (this.state.kind !== BuildStateKind.Analyzed ||
+        this.state.priorTypeCheckingResults === null || this.logicalChanges === null) {
+      return null;
+    }
+
+    if (this.logicalChanges.has(sf.fileName)) {
+      return null;
+    }
+
+    const fileName = absoluteFromSourceFile(sf);
+    if (!this.state.priorTypeCheckingResults.has(fileName)) {
+      return null;
+    }
+    const data = this.state.priorTypeCheckingResults.get(fileName)!;
+    if (data.hasInlines) {
+      return null;
+    }
+
+    return data;
+  }
 }
 
 type BuildState = PendingBuildState|AnalyzedBuildState;
@@ -236,7 +270,8 @@ interface BaseBuildState {
    * After analysis, it's updated to include any files which might have changed and need a re-emit
    * as a result of incremental changes.
    *
-   * If an emit happens, any written files are removed from the `Set`, as they're no longer pending.
+   * If an emit happens, any written files are removed from the `Set`, as they're no longer
+   * pending.
    *
    * Thus, after compilation `pendingEmit` should be empty (on a successful build) or contain the
    * files which still need to be emitted but have not yet been (due to errors).
@@ -267,6 +302,11 @@ interface BaseBuildState {
      * This is used to extract "prior work" which might be reusable in this compilation.
      */
     traitCompiler: TraitCompiler;
+
+    /**
+     * Type checking results which will be passed onto the next build.
+     */
+    typeCheckingResults: Map<AbsoluteFsPath, FileTypeCheckingData>| null;
   }|null;
 }
 
@@ -306,6 +346,11 @@ interface AnalyzedBuildState extends BaseBuildState {
    * analyzed build.
    */
   pendingEmit: Set<string>;
+
+  /**
+   * Type checking results from the previous compilation, which can be reused in this one.
+   */
+  priorTypeCheckingResults: Map<AbsoluteFsPath, FileTypeCheckingData>|null;
 }
 
 function tsOnlyFiles(program: ts.Program): ReadonlyArray<ts.SourceFile> {

packages/compiler-cli/src/ngtsc/shims/index.ts

@@ -10,7 +10,7 @@
 
 export {PerFileShimGenerator, TopLevelShimGenerator} from './api';
 export {ShimAdapter} from './src/adapter';
-export {isShim} from './src/expando';
+export {copyFileShimData, isShim} from './src/expando';
 export {FactoryGenerator, FactoryInfo, FactoryTracker, generatedFactoryTransform} from './src/factory_generator';
 export {ShimReferenceTagger} from './src/reference_tagger';
 export {SummaryGenerator} from './src/summary_generator';

packages/compiler-cli/src/ngtsc/shims/src/expando.ts

@@ -100,3 +100,13 @@ export function isFileShimSourceFile(sf: ts.SourceFile): sf is NgFileShimSourceF
 export function isShim(sf: ts.SourceFile): boolean {
   return isExtended(sf) && (sf[NgExtension].fileShim !== null || sf[NgExtension].isTopLevelShim);
 }
+
+/**
+ * Copy any shim data from one `ts.SourceFile` to another.
+ */
+export function copyFileShimData(from: ts.SourceFile, to: ts.SourceFile): void {
+  if (!isFileShimSourceFile(from)) {
+    return;
+  }
+  sfExtensionData(to).fileShim = sfExtensionData(from).fileShim;
+}

packages/compiler-cli/src/ngtsc/transform/src/compilation.ts

@@ -87,7 +87,7 @@ export class TraitCompiler implements ProgramTypeCheckAdapter {
   constructor(
       private handlers: DecoratorHandler<unknown, unknown, unknown>[],
       private reflector: ReflectionHost, private perf: PerfRecorder,
-      private incrementalBuild: IncrementalBuild<ClassRecord>,
+      private incrementalBuild: IncrementalBuild<ClassRecord, unknown>,
       private compileNonExportedClasses: boolean, private dtsTransforms: DtsTransformRegistry) {
     for (const handler of handlers) {
       this.handlersByName.set(handler.name, handler);
@@ -423,8 +423,16 @@ export class TraitCompiler implements ProgramTypeCheckAdapter {
     }
   }
 
-  typeCheck(ctx: TypeCheckContext): void {
-    for (const clazz of this.classes.keys()) {
+  /**
+   * Generate type-checking code into the `TypeCheckContext` for any components within the given
+   * `ts.SourceFile`.
+   */
+  typeCheck(sf: ts.SourceFile, ctx: TypeCheckContext): void {
+    if (!this.fileToClasses.has(sf)) {
+      return;
+    }
+
+    for (const clazz of this.fileToClasses.get(sf)!) {
       const record = this.classes.get(clazz)!;
       for (const trait of record.traits) {
         if (trait.state !== TraitState.RESOLVED) {