-
Notifications
You must be signed in to change notification settings - Fork 26.1k
fix(compiler-cli): various fixes to input transform type emitting #52437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…tion arguments This commit fixes an issue where using literal types in the arguments of an input coercion function could result in emitting invalid output, due to an assumption that TypeScript makes when emitting literal types. Specifically, it takes the literal's text from its containing source file, but this breaks when the literal type node has been transplanted into a different source file. This issue has surfaced in the type-check code generator and is already being addressed there, so this commit moves the relevant `TypeEmitter` class from the `typecheck` module to the `translator` module, such that it can be reused for emitting types in the type translator. Fixes angular#51672
tsCreateTypeQueryForCoercedInput(rawType.typeName, classPropertyName) : | ||
transform.type)); | ||
transform.type.node)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still broken, but likely hasn't caused issues because type constructors in the TCB are not translated to template code so they are never reported to users.
The type node should go through the emitter process here as well, as we can't simply dump the original type node in a completely different source file as is currently done. Fixing it requires some more extensive changes though so I kept it broken for now.
0e52fbb
to
2f973e6
Compare
… functions Prior to this change, the transform function would be referenced with a potentially relative import into an external declaration file. Such imports are not portable and should not be created in this context. This commit addresses the issue by threading though the originally used module specifier by means of the `Reference` type. Fixes angular#52324
2f973e6
to
0d1a0c7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Reviewed-for: public-api
@@ -79,12 +80,17 @@ class TypeTranslatorVisitor implements o.ExpressionVisitor, o.TypeVisitor { | |||
return ts.factory.createTypeLiteralNode([indexSignature]); | |||
} | |||
|
|||
visitTransplantedType(ast: o.TransplantedType<ts.Node>, context: any) { | |||
if (!ts.isTypeNode(ast.type)) { | |||
visitTransplantedType(ast: o.TransplantedType<unknown>, context: Context) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: would it make sense to use something like ts.Node | Reference
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I decided not to, because the T
of TransplantedType
is not constrained so using ts.Node | Reference
here might not be accurate.
if (!ts.isTypeReferenceNode(result)) { | ||
throw new Error(`Expected TypeReferenceNode when referencing the type for ${ | ||
node.typeName.text}, but received ${ts.SyntaxKind[result.kind]}`); | ||
let owningModule = viaModule; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can reduce this to:
const owningModule = declaration.viaModule === null ? viaModule : owningModule = {
specifier: declaration.viaModule,
resolutionContext: type.getSourceFile().fileName,
};
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would do the same indeed, but I find the current logic more readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed-for: public-api
This PR was merged into the repository by commit 581eff4. |
…tion arguments (#52437) This commit fixes an issue where using literal types in the arguments of an input coercion function could result in emitting invalid output, due to an assumption that TypeScript makes when emitting literal types. Specifically, it takes the literal's text from its containing source file, but this breaks when the literal type node has been transplanted into a different source file. This issue has surfaced in the type-check code generator and is already being addressed there, so this commit moves the relevant `TypeEmitter` class from the `typecheck` module to the `translator` module, such that it can be reused for emitting types in the type translator. Fixes #51672 PR Close #52437
… functions (#52437) Prior to this change, the transform function would be referenced with a potentially relative import into an external declaration file. Such imports are not portable and should not be created in this context. This commit addresses the issue by threading though the originally used module specifier by means of the `Reference` type. Fixes #52324 PR Close #52437
…tion arguments (#52437) This commit fixes an issue where using literal types in the arguments of an input coercion function could result in emitting invalid output, due to an assumption that TypeScript makes when emitting literal types. Specifically, it takes the literal's text from its containing source file, but this breaks when the literal type node has been transplanted into a different source file. This issue has surfaced in the type-check code generator and is already being addressed there, so this commit moves the relevant `TypeEmitter` class from the `typecheck` module to the `translator` module, such that it can be reused for emitting types in the type translator. Fixes #51672 PR Close #52437
… functions (#52437) Prior to this change, the transform function would be referenced with a potentially relative import into an external declaration file. Such imports are not portable and should not be created in this context. This commit addresses the issue by threading though the originally used module specifier by means of the `Reference` type. Fixes #52324 PR Close #52437
… functions (#52437) Prior to this change, the transform function would be referenced with a potentially relative import into an external declaration file. Such imports are not portable and should not be created in this context. This commit addresses the issue by threading though the originally used module specifier by means of the `Reference` type. Fixes #52324 PR Close #52437
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. |
…tion arguments (angular#52437) This commit fixes an issue where using literal types in the arguments of an input coercion function could result in emitting invalid output, due to an assumption that TypeScript makes when emitting literal types. Specifically, it takes the literal's text from its containing source file, but this breaks when the literal type node has been transplanted into a different source file. This issue has surfaced in the type-check code generator and is already being addressed there, so this commit moves the relevant `TypeEmitter` class from the `typecheck` module to the `translator` module, such that it can be reused for emitting types in the type translator. Fixes angular#51672 PR Close angular#52437
… functions (angular#52437) Prior to this change, the transform function would be referenced with a potentially relative import into an external declaration file. Such imports are not portable and should not be created in this context. This commit addresses the issue by threading though the originally used module specifier by means of the `Reference` type. Fixes angular#52324 PR Close angular#52437
…tion arguments (angular#52437) This commit fixes an issue where using literal types in the arguments of an input coercion function could result in emitting invalid output, due to an assumption that TypeScript makes when emitting literal types. Specifically, it takes the literal's text from its containing source file, but this breaks when the literal type node has been transplanted into a different source file. This issue has surfaced in the type-check code generator and is already being addressed there, so this commit moves the relevant `TypeEmitter` class from the `typecheck` module to the `translator` module, such that it can be reused for emitting types in the type translator. Fixes angular#51672 PR Close angular#52437
… functions (angular#52437) Prior to this change, the transform function would be referenced with a potentially relative import into an external declaration file. Such imports are not portable and should not be created in this context. This commit addresses the issue by threading though the originally used module specifier by means of the `Reference` type. Fixes angular#52324 PR Close angular#52437
fix(compiler-cli): properly emit literal types in input coercion function arguments
This commit fixes an issue where using literal types in the arguments of an input coercion
function could result in emitting invalid output, due to an assumption that TypeScript makes
when emitting literal types. Specifically, it takes the literal's text from its containing
source file, but this breaks when the literal type node has been transplanted into a
different source file. This issue has surfaced in the type-check code generator and is
already being addressed there, so this commit moves the relevant
TypeEmitter
classfrom the
typecheck
module to thetranslator
module, such that it can be reused foremitting types in the type translator.
Fixes #51672
fix(compiler-cli): use originally used module specifier for transform functions
Prior to this change, the transform function would be referenced with a potentially
relative import into an external declaration file. Such imports are not portable
and should not be created in this context. This commit addresses the issue by threading
though the originally used module specifier by means of the
Reference
type.Fixes #52324