perf(ivy): support simple generic type constraints in local type ctors

[JoostK]

In Ivy's template type checker, type constructors are created for all
directive types to allow for accurate type inference to work. The type
checker has two strategies for dealing with such type constructors:

1. They can be emitted local to the type check block/type check file.
2. They can be emitted as static ngTypeCtor field into the directive
   itself.

The first strategy is preferred, as it avoids having to update the
directive type which would cause a more expensive rebuild. However, this
strategy is not suitable for directives that have constrained generic
types, as those constraints would need to be present on the local type
constructor declaration. This is not trivial, as it requires that any
type references within a type parameter's constraint are imported into
the local context of the type check block.

For example, lets consider the NgForOf directive from '@angular/core'
looks as follows:

import {NgIterable} from '@angular/core';

export class NgForOf<T, U extends NgIterable<T>> {}

The type constructor will then have the signature:
(o: Pick<i1.NgForOf<T, U>, 'ngForOf'>) => i1.NgForOf<T, U>

Notice how this refers to the type parameters T and U, so the type
constructor needs to be emitted into a scope where those types are
available, and have the correct constraints.

Previously, the template type checker would detect the situation where a
type parameter is constrained, and would emit the type constructor
using strategy 2; within the directive type itself. This approach makes
any type references with the generic type constraints lexically
available:

export class NgForOf<T, U extends NgIterable<T>> {
  static ngTypeCtor<T = any, U extends NgIterable<T> = any>
    (o: Pick<NgForOf<T, U>, 'ngForOf'>): NgForOf<T, U> { return null!; }
}

This commit introduces the ability to reify a type parameter with
constraints into a different context, under the condition that it can
be imported from an absolute module. This allows a generic type
constructor to be emitted into a type check block or type check file
according to strategy 1, as its generic types can be reconstructed using
the reification mechanism:

import * as i0 from '@angular/core';
import * as i1 from '@angular/common';

const _ctor1: <T = any, U extends i0.NgIterable<T> = any>
  (o: Pick<i1.NgForOf<T, U>, 'ngForOf'>) => i1.NgForOf<T, U> = null!;

Notice how the generic type constraint of U has resulted in an import
of @angular/core, and the NgIterable is transformed into a qualified
name during the reification process.

Resolves FW-1739

[petebacondarwin]

This is awesome work @JoostK . I couldn't find anything wrong with the implementation. Only nice tidy code, full tests and an excellent commit message!

---

I am sorry to bike-shed but "reify" is not the correct term to use here - and it actually made it much harder for me to work out what this PR was about.

Reifying is taking something abstract and making it concrete. This is not what this code is doing.

What this is really about is moving a type to a new file, when it is possible. I.E. the type that is being used in the file where a directive is being defined needs to be moved to the file containing the type checking code.

I believe that if you change all instances of reify to relocate then this makes a lot more sense. E.g.

  private relocateTypeParameters(declaration: ClassDeclaration<ts.ClassDeclaration>):
      ts.TypeParameterDeclaration[]|undefined {
    const relocator = new TypeParameterRelocator(declaration.typeParameters, this.reflector);
    return relocator.relocate(ref => this.referenceType(ref));
  }

[petebacondarwin]

When you say anywhere, isn't it true that the type check file will be local to the application being built, so if the original application source file can import the local declaration then the type check file ought to be able to as well?

[petebacondarwin]

Can you give an example of when it is not possible to import the dependency?

[alxhub]

@petebacondarwin in general, yes, we should be able to import such identifiers. However, I'd like to limit the scope of this change until we've thought through all the ramifications regarding rootDirs and the other quirks of TS module resolution. I'm mostly concerned that the template type-checking file is somewhat randomly placed right now.

[alxhub]

Whoa, cool!

[alxhub]

Change the "reified" terminology here :)

One term we might consider using is "context-free". This means that the type nodes and their associated imports can be reproduced in the type-checking file without mutation - they're not sensitive to the specific file (context) in which they appear.

[JoostK]

Hahaha, the very first iteration of the code started with a function named isTypeContextFree, which became isTypeReifiable as it became more complete. I'll have a look at changing the canEmit terminology into isContextFree to see how clear that would be.

Feedback has been addressed

[alxhub]

Updated:

Presubmit
Ivy Presubmit

[angular-automatic-lock-bot]

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

Read more about our automatic conversation locking policy.

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