Skip to content
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

fix(compiler-cli): various fixes to input transform type emitting #52437

Closed
wants to merge 2 commits into from

Conversation

JoostK
Copy link
Member

@JoostK JoostK commented Oct 28, 2023

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 class
from the typecheck module to the translator module, such that it can be reused for
emitting 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

…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
@JoostK JoostK added target: patch This PR is targeted for the next patch release area: compiler Issues related to `ngc`, Angular's template compiler labels Oct 28, 2023
@ngbot ngbot bot modified the milestone: Backlog Oct 28, 2023
tsCreateTypeQueryForCoercedInput(rawType.typeName, classPropertyName) :
transform.type));
transform.type.node));
Copy link
Member Author

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.

… 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
@JoostK JoostK marked this pull request as ready for review October 29, 2023 11:16
@JoostK JoostK added the action: review The PR is still awaiting reviews from at least one requested reviewer label Oct 29, 2023
@crisbeto
Copy link
Member

Would this fix #51424 or do we still need #51474?

@JoostK
Copy link
Member Author

JoostK commented Oct 29, 2023

Would this fix #51424 or do we still need #51474?

Unfortunately the TCB generator also didn't support ambient types, so I'd expect that #51474 is still relevant.

Copy link
Member

@pkozlowski-opensource pkozlowski-opensource left a 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) {
Copy link
Member

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?

Copy link
Member Author

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;
Copy link
Member

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,
};

Copy link
Member Author

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.

Copy link
Contributor

@AndrewKushnir AndrewKushnir left a 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

@AndrewKushnir AndrewKushnir added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Oct 30, 2023
@alxhub
Copy link
Member

alxhub commented Oct 31, 2023

This PR was merged into the repository by commit 581eff4.

alxhub pushed a commit that referenced this pull request Oct 31, 2023
…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
alxhub pushed a commit that referenced this pull request Oct 31, 2023
… 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
alxhub pushed a commit that referenced this pull request Oct 31, 2023
…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
alxhub pushed a commit that referenced this pull request Oct 31, 2023
… 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
@alxhub alxhub closed this in 0c7accf Oct 31, 2023
alxhub pushed a commit that referenced this pull request Oct 31, 2023
… 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
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Dec 1, 2023
tbondwilkinson pushed a commit to tbondwilkinson/angular that referenced this pull request Dec 6, 2023
…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
tbondwilkinson pushed a commit to tbondwilkinson/angular that referenced this pull request Dec 6, 2023
… 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
ChellappanRajan pushed a commit to ChellappanRajan/angular that referenced this pull request Jan 23, 2024
…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
ChellappanRajan pushed a commit to ChellappanRajan/angular that referenced this pull request Jan 23, 2024
… 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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: compiler Issues related to `ngc`, Angular's template compiler target: patch This PR is targeted for the next patch release
Projects
None yet
5 participants