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

Fixed declaration emit issue related to a qualifier being reused cross-file #58810

Merged
merged 3 commits into from
Jun 14, 2024

Conversation

Andarist
Copy link
Contributor

@Andarist Andarist commented Jun 9, 2024

fixes #58807

@typescript-bot typescript-bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Jun 9, 2024
@@ -8840,7 +8840,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
node,
factory.updateLiteralTypeNode(node.argument, rewriteModuleSpecifier(node, node.argument.literal)),
node.attributes,
node.qualifier,
visitNode(node.qualifier, visitExistingNodeTreeSymbols, isEntityName),
Copy link

@MichaelMitchell-at MichaelMitchell-at Jun 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely don't have enough context on the workings of the checker to give any informed feedback, but I can at least ask at a high level do we have some confidence whether anything more could be done to the structure of the code to avoid this general class of problem?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tbh, I don't know this part of TS too well either so we need to wait for @weswigham or @dragomirtitian to give some feedback on this. I'd expect that other things in this function (like node.attributes here) should be wrapped like this too (if only this is the right fix).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would definitely suspect a lot of this needs this same fix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

100% - any child node we copy should have its' children visited - any missing visitor calls on manually remapped nodes are an oversight, presumably.

Copy link
Member

@weswigham weswigham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakebailey do we just want to take this as-is, or should we use this opportunity to audit all the factory calls in the visitor?

@jakebailey
Copy link
Member

I think it'd be fine to merge this since it clearly helps code in the wild, but I do think we should audit effectively everything and backport what we find.

@Andarist
Copy link
Contributor Author

I can make this audit as part of this PR (or separately), if you are OK with waiting till tomorrow.

@jakebailey
Copy link
Member

I think we could wait a day on this one; we still have time before the release.

@Andarist
Copy link
Contributor Author

aye aye, captain

@typescript-bot typescript-bot added For Milestone Bug PRs that fix a bug with a specific milestone and removed For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Jun 12, 2024
@@ -8765,7 +8765,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
/*modifiers*/ undefined,
getEffectiveDotDotDotForParameter(p),
setTextRange(context, factory.createIdentifier(getNameForJSDocFunctionParameter(p, i)), p),
p.questionToken,
p.questionToken ? factory.createToken(SyntaxKind.QuestionToken) : undefined,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some other code paths in this function do a similar "cloning" of the .questionToken so I assume that it's the right thing to do here and in other places that I touched

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those 2 call sites related to .questionToken are also related to JSDoc. I wonder if this cloning even matters in this context.

@@ -8798,7 +8798,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
if (isTypeParameterDeclaration(node)) {
return factory.updateTypeParameterDeclaration(
node,
node.modifiers,
visitNodes(node.modifiers, visitExistingNodeTreeSymbols, isModifier),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those modifiers are just tokens so i guess i could just map over them and clone them?

@@ -8839,8 +8839,8 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
return factory.updateImportTypeNode(
node,
factory.updateLiteralTypeNode(node.argument, rewriteModuleSpecifier(node, node.argument.literal)),
node.attributes,
node.qualifier,
visitNode(node.attributes, visitExistingNodeTreeSymbols, isImportAttributes),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those are not jus flat tokens so I wasn't quite sure what to do about those, it seemed like maybe i should deep clone them?

}
return factory.updateTypePredicateNode(node, node.assertsModifier, parameterName, visitNode(node.type, visitExistingNodeTreeSymbols, isTypeNode));
return factory.updateTypePredicateNode(node, node.assertsModifier ? factory.createToken(SyntaxKind.AssertsKeyword) : undefined, parameterName, visitNode(node.type, visitExistingNodeTreeSymbols, isTypeNode));
}

if (isTupleTypeNode(node) || isTypeLiteralNode(node) || isMappedTypeNode(node)) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are also places in this function that do smth like:

if (visited === node) {
  visited = factory.cloneNode(node)
}

this pattern is not applied consistently across the whole function, should it be? 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect yes.... Sure seems like though that we should make some sort of wrapper for the visitor func that would check that. Though I feel like I've seen that exact code in some visitor transformer code already (maybe we're not going through that)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might be a bigger change so I'd leave it out of this PR. I just want to flag this as a potential problem.

@Andarist Andarist requested a review from jakebailey June 12, 2024 19:03
Copy link
Member

@jakebailey jakebailey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, likely need to be cherry picking this to 5.5.

@jakebailey
Copy link
Member

@typescript-bot cherry-pick this to release-5.5

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 12, 2024

Starting jobs; this comment will be updated as builds start and complete.

Command Status Results
cherry-pick this to release-5.5 ✅ Started ✅ Results

@typescript-bot
Copy link
Collaborator

Hey, @jakebailey! I've created #58842 for you.

@jakebailey jakebailey merged commit c2e48e5 into microsoft:main Jun 14, 2024
28 checks passed
DanielRosenwasser pushed a commit that referenced this pull request Jun 15, 2024
…e-5.5 (#58842)

Co-authored-by: Mateusz Burzyński <mateuszburzynski@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
For Milestone Bug PRs that fix a bug with a specific milestone
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

[nightly] Syntactically invalid declaration files emitted under extremely specific conditions
5 participants