fix(compiler-cli): handle directives that refer to a namespaced class in a type parameter bound#43511
fix(compiler-cli): handle directives that refer to a namespaced class in a type parameter bound#43511JoostK wants to merge 1 commit intoangular:masterfrom
Conversation
… in a type parameter bound The template type-checker has to emit type constructors for the directives that are used in a template, where a type constructor's declaration has to mirror the type parameter constraints as they were originally declared. Therefore, the compiler analyzes whether a type parameter constraint can be recreated, e.g. by generating imports for any type references. Some type references cannot be recreated, in which case the compiler has to fall back to a strategy where the type constructor is created inline in the original source file (which comes with a performance penalty). There used to be an issue for type references to namespaced declarations. The compiler is unable to emit such references such that an inline type constructor should be used as fallback, but this did not happen. This caused the attempt to emit the type reference to fail, as the namespaced declaration cannot be located by the reference emitters. This commit fixes the issue by using a stricter check to determine if a type parameter requires an inline type constructor. The TypeScript reflection host's `isStaticallyExported` logic was expanded to work for any declaration instead of just classes, as e.g. type declarations can also be referenced in a type parameter constraint. Closes angular#43383
… in a type parameter bound (#43511) The template type-checker has to emit type constructors for the directives that are used in a template, where a type constructor's declaration has to mirror the type parameter constraints as they were originally declared. Therefore, the compiler analyzes whether a type parameter constraint can be recreated, e.g. by generating imports for any type references. Some type references cannot be recreated, in which case the compiler has to fall back to a strategy where the type constructor is created inline in the original source file (which comes with a performance penalty). There used to be an issue for type references to namespaced declarations. The compiler is unable to emit such references such that an inline type constructor should be used as fallback, but this did not happen. This caused the attempt to emit the type reference to fail, as the namespaced declaration cannot be located by the reference emitters. This commit fixes the issue by using a stricter check to determine if a type parameter requires an inline type constructor. The TypeScript reflection host's `isStaticallyExported` logic was expanded to work for any declaration instead of just classes, as e.g. type declarations can also be referenced in a type parameter constraint. Closes #43383 PR Close #43511
|
Dunno if I should post here or in the Issues, but... After upgrading from v12.2.6 to v12.2.7 (with this fix included) my library project build now fails. Rolling only the Last messages before build process fails are these: (SomeComponent extends another abstract component with Directive annotation on it, if this matters. Also SomeInterface not even remotely used in SomeComponent) Any ideas? |
|
@amariq that's a new bug, then. Please open a new issue with reproduction and I'll sort it out. |
|
@JoostK uh oh, okay, I'll try, but I don't even know what could lead to that. Also it involves libraries (haven't tried to build an app, yet), and both of them are internal (one uses another). |
|
@JoostK hello there :-) I did some testing in our code (sorry, no issue/repro yet, will add later, still just digging up), and I think I found something. The following part is the source of the issue: Any changes to MyValue don't do anything, and only removing it from MyComponent declaration or replacing with built-in types (V = any or V extends object = any) helps. |
|
@amariq Could you share how |
|
@JoostK of course! I also tried changing import to import type, but no effect. |
|
Thanks a lot. That seems simple enough and unfortunately does not yet give me any pointers as to why it started failing. |
|
@JoostK some thoughts here. At first I thought the reason is parameter constraints that depend on other parameters, but it doesn't seem to be the case.
Here is extended details on full type hierarchy (maybe it will bring some hints, its best I have time on right now):
|
|
@JoostK repro here! https://github.com/amariq/angular-pr43511-bug Will post the issue later, if necessary :) |
|
any news on this? We have the same issue after upgrading to v12.2.7 @amariq did you open an issue for this problem? |
|
@kahmannf opened just now :) |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
The template type-checker has to emit type constructors for the
directives that are used in a template, where a type constructor's
declaration has to mirror the type parameter constraints as they were
originally declared. Therefore, the compiler analyzes whether a type
parameter constraint can be recreated, e.g. by generating imports for
any type references. Some type references cannot be recreated, in which
case the compiler has to fall back to a strategy where the type
constructor is created inline in the original source file (which comes
with a performance penalty).
There used to be an issue for type references to namespaced declarations.
The compiler is unable to emit such references such that an inline
type constructor should be used as fallback, but this did not happen.
This caused the attempt to emit the type reference to fail, as the
namespaced declaration cannot be located by the reference emitters.
This commit fixes the issue by using a stricter check to determine if a
type parameter requires an inline type constructor. The TypeScript
reflection host's
isStaticallyExportedlogic was expanded to work forany declaration instead of just classes, as e.g. type declarations can
also be referenced in a type parameter constraint.
Closes #43383