fix(compiler-cli): properly emit literal types when recreating type parameters in a different file #42761
Conversation
JoostK
added
target: patch
JoostK
added
the
action: review
There was a problem hiding this comment.
Nice fix @JoostK. I was a bit confused by the commit message, but I think the problem that is being solved is that in non-synthesized nodes, the TS compiler will shortcut having to render the node manually by just grabbing the text given by the "source-span". But in this case, since the node was moved from one file (the original source) to another (the type-check file) the parse-span points to a random segment of text in the type-check file. Is that correct?
| // the type as a whole cannot be emitted in that case. Otherwise, the result of visiting all child | ||
| // nodes determines the result. If no ineligible type reference node is found then the walk | ||
| // returns `undefined`, indicating that no type node was visited that could not be emitted. | ||
| // If an unsupported type node is found at any position within the type and, then the `INELIGIBLE` |
There was a problem hiding this comment.
NIT:
| // If an unsupported type node is found at any position within the type and, then the `INELIGIBLE` | |
| // If an unsupported type node is found at any position within the type and then the `INELIGIBLE` |
That's exactly the case, indeed! |
JoostK
added
action: cleanup
…arameters in a different file In angular#42492 the template type checker became capable of replicating a wider range of generic type parameters for use in template type-check files. Any literal types within a type parameter would however emit invalid code, as TypeScript was emitting the literals using the text as extracted from the template type-check file instead of the original source file where the type node was taken from. This commit works around the issue by cloning any literal types and marking them as synthetic, signalling to TypeScript that the literal text has to be extracted from the node itself instead from the source file. This commit also excludes `import()` type nodes from being supported, as their module specifier may potentially need to be rewritten. Fixes angular#42667
JoostK
force-pushed
the
ngtsc/ttc/type-emitter-literals
branch
from
81e0069
to
02fea47
Compare
JoostK
added
action: merge
AndrewKushnir
removed
the
action: presubmit
…arameters in a different file (#42761) In #42492 the template type checker became capable of replicating a wider range of generic type parameters for use in template type-check files. Any literal types within a type parameter would however emit invalid code, as TypeScript was emitting the literals using the text as extracted from the template type-check file instead of the original source file where the type node was taken from. This commit works around the issue by cloning any literal types and marking them as synthetic, signalling to TypeScript that the literal text has to be extracted from the node itself instead from the source file. This commit also excludes `import()` type nodes from being supported, as their module specifier may potentially need to be rewritten. Fixes #42667 PR Close #42761
|
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. |
In #42492 the template type checker became capable of replicating a
wider range of generic type parameters for use in template type-check
files. Any literal types within a type parameter would however emit
invalid code, as TypeScript was emitting the literals using the text as
extracted from the template type-check file instead of the original
source file where the type node was taken from.
This commit works around the issue by cloning any literal types and
marking them as synthetic, signalling to TypeScript that the literal
text has to be extracted from the node itself instead from the source
file.
This commit also excludes
import()type nodes from being supported,as their module specifier may potentially need to be rewritten.
Fixes #42667