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 a crash in completions on functionlike types #56257

Merged

Conversation

Andarist
Copy link
Contributor

@Andarist Andarist commented Oct 30, 2023

reported here
closes #56402

@typescript-bot typescript-bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Oct 30, 2023
@typescript-bot
Copy link
Collaborator

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

Comment on lines 1931 to 1933
export function isCallLikeOrFunctionLikeExpression(node: Node): node is CallLikeExpression | FunctionLikeDeclaration {
return isCallLikeExpression(node) || isFunctionLikeDeclaration(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.

I believe that this reflects the name better and perhaps the change reflects the original intention

Copy link
Member

Choose a reason for hiding this comment

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

I guess I don't expect this to return true for function declarations, except those in expression positions... am I missing something?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yee, you are right. I limited this further to only return true for function expressions and arrows

Copy link
Member

Choose a reason for hiding this comment

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

Are you trying to limit to functions that can be contextually typed? What about object literal method declarations?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Are you trying to limit to functions that can be contextually typed?

Somewhat. IIRC I meant to limit it to expression-space functions and both of those "sets" are almost the same. I think that either would be OK here (at least for the purpose of my fix).

What about object literal method declarations?

They are already covered by isFunctionLikeDeclaration check

@DanielRosenwasser
Copy link
Member

It feels like this is partially related to #51104. But I'm okay with a limited fix.

@Andarist
Copy link
Contributor Author

Andarist commented Nov 9, 2023

It feels like this is partially related to #51104. But I'm okay with a limited fix.

Yeah, it looks very much related.

@@ -1928,8 +1931,8 @@ export function isPropertyAccessOrQualifiedName(node: Node): node is PropertyAcc
}

/** @internal */
export function isCallLikeOrFunctionLikeExpression(node: Node): node is CallLikeExpression | SignatureDeclaration {
Copy link
Member

Choose a reason for hiding this comment

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

Was this function really not used elsewhere? Super surprised, but it does seem to be true.

@@ -1868,7 +1868,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
const nodeLinks = getNodeLinks(node);
cachedResolvedSignatures.push([nodeLinks, nodeLinks.resolvedSignature] as const);
nodeLinks.resolvedSignature = undefined;
if (isFunctionLike(node)) {
if (isFunctionExpressionOrArrowFunction(node)) {
const symbolLinks = getSymbolLinks(getSymbolOfDeclaration(node));
Copy link
Member

Choose a reason for hiding this comment

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

Maybe I'm wrong here, but is it the case that this could also be fixed by instead checking if the declaration has a symbol?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe I'm wrong here

You are not 😉

but is it the case that this could also be fixed by instead checking if the declaration has a symbol?

It could have been fixed like that but the possibility of lacking a symbol isn't reflected by the types. I also just noticed that this kinda happened because I was using a function that was matching more types than I wanted so this just seemed like a slightly better fix.

Copy link
Member

Choose a reason for hiding this comment

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

the possibility of lacking a symbol isn't reflected by the types

This is an ongoing struggle; I should really resurrect my PR which attempts to make it known-optional.

@jakebailey
Copy link
Member

@DanielRosenwasser This is a new crash in 5.3; I don't know that it's required pre-release, but I think this one should be backported.

@jakebailey jakebailey merged commit 4515089 into microsoft:main Nov 15, 2023
19 checks passed
@jakebailey
Copy link
Member

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

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 15, 2023

Heya @jakebailey, I've started to run the task to cherry-pick this into release-5.3 on this PR at 0009f7f. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

Hey @jakebailey, I couldn't open a PR with the cherry-pick. (You can check the log here). You may need to squash and pick this PR into release-5.3 manually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TypeError: Cannot read properties of undefined (reading 'flags')
5 participants