Skip to content

Conversation

@sandersn
Copy link
Member

Discovered in #57117 for the 5.4 beta.

The implementation should not use couldContainTypeVariables--it's intended as a fast path, and should not be used in places where its unreliability can be observed.

The tests stay, but with a note added that they should pass but do not.

Discovered in microsoft#57117

The implementation should not `couldContainTypeVariables`--it's not
intended a fast path, and should not be used in places where its
unreliability can be observed.

The tests stay, but with a note added that they should pass but do not.
@typescript-bot typescript-bot added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Jan 24, 2024
Copy link
Member

Choose a reason for hiding this comment

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

This is a minimal repro for the break, right?

Copy link
Contributor

Choose a reason for hiding this comment

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

yes

@DanielRosenwasser DanielRosenwasser merged commit 584b314 into microsoft:main Jan 25, 2024
const signature = getSingleCallSignature(funcType);
if (signature) {
const returnType = getReturnTypeOfSignature(signature);
if (!signature.typeParameters || !couldContainTypeVariables(returnType)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I try to understand how to use couldContainTypeVariables appropriately and I wonder how this was different from how checkFunctionExpressionOrObjectLiteralMethod uses it here?

        // The identityMapper object is used to indicate that function expressions are wildcards
        if (checkMode && checkMode & CheckMode.SkipContextSensitive && isContextSensitive(node)) {
            // Skip parameters, return signature with return type that retains noncontextual parts so inferences can still be drawn in an early stage
            if (!getEffectiveReturnTypeNode(node) && !hasContextSensitiveParameters(node)) {
                // Return plain anyFunctionType if there is no possibility we'll make inferences from the return type
                const contextualSignature = getContextualSignature(node);
                if (contextualSignature && couldContainTypeVariables(getReturnTypeOfSignature(contextualSignature))) {

Copy link
Contributor

Choose a reason for hiding this comment

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

I see how this is part of the inference algorithm and the check here was kinda not - but I still fail to understand how those 2 situations are fundamentally different so it's OK to call it within one context and not OK to call it within another.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure that other use is correct either...

Copy link
Contributor

Choose a reason for hiding this comment

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

I also tried to repro the regression caused by this cause I wanted to add a test case for it but I failed. It has been mentioned that it was only visible in the IDE but I assume that this particular report was reported by a bot reporting tsc-related changes. I couldn't repro with either though.

@sandersn sandersn deleted the revert-54477-but-keep-tests branch January 25, 2024 22:54
@microsoft microsoft locked as resolved and limited conversation to collaborators Oct 16, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants