Function return type is not inferred when used in generic position

[HerringtonDarkholme]

TypeScript Version: typescript@rc 2.0.2

Code

with noImplicityAny being true

function id<T>(p: T) {}
id(() => 123)

Expected behavior:

It compiles. id is inferred as function id<() => number>(p: () => number): void

Actual behavior:

It does not compile.
Compiler error:

Function implicitly has return type 'any' because it does not have a return type annotation and is referenced directly or indirectly in one of its return expressions.

p is inferred as () => any

This code works in TS1.8.

[yuit]

After spending time debugging through our code in type-inference and contextual typing and talking with @vladima, the fix for this one will not be trivia at all and would require re-architecture on how we are doing type-inference/contextual typing. What happen here is that when compiler is checking arrow function, in trying to figure out return type of the function, it will then request contextual signature and trying to figure out return type of the contextual signature. This is the part that make this code broke in 2.0 but not 1.8, in 2.0 we introduce concept of literal type in 2.0 so in knowing whether the return type of the arrow function should be literal type of base primitive type (e.g number string) we end up having to figure out whether such position is sensitive to literal contextual type which in turn causes as to have to figure out return type of the contextual signature and the circulation begins.

[Psvensso]

Found another observation that probably relates to this.

function myFunc():void {
    return ""; //Gives compiler warning 'string is not assignable to void' as expected
}

function badMyFunc(): () => void {
    return () => {
        return ""; // Gives no compiler warning, expected return type error
    }
}

[HerringtonDarkholme]

I don't think this is that hard to fix, if I had read the code correctly.
As @yuit pointed out, we will getReturnTypeOfSignature twice: the first time is for resolving return type directly, and the second time is for figuring out contextual typing bound. For both times type checker will pushTypeResolution to mark whether a signature has been asked for resolution.

When asking for return type for the first time, compiler will not see signature marked so it proceeds to getReturnTypeFromBody, where contextual typing get resolved. To see whether a literal return value needs to be widen, compiler call getReturnTypeOfSignature again. This time compiler will see the signature marked so the return type of the signature is unknownType. Fortunately in getReturnTypeFromBody, unknownType is just used to determine whether return position isLiteralContextualType, so compiler just goes on and widens literal type.

Then the control flow comes back to the first time getReturnTypeOfSignature, where type is correctly resolved, e.g. number in the above example.

But popTypeResolution still gives false and compiler just blindly thinks the return type is unresolvable. If we first check if type is unknownType , then the correct answer can be found.

[HerringtonDarkholme]

Any update here?

[RyanCavanaugh]

@HerringtonDarkholme refer to this comment

the fix for this one will not be trivial at all and would require re-architecture on how we are doing type-inference/contextual typing

In other words, it's not going to be something we can fix anytime soon, assuming the investigation was correct. We'll review the PR to see if it is the right fix, though.

[masaeedu]

I was experimenting with a fix for #15016 in this branch, I believe it solves this scenario as well:

[gcnew]

I don't want to put your work down, but this example seems to be working with the vanilla compiler as well - link. I'm not sure whether the issue is still present in more complex use-cases though.

[masaeedu]

@gcnew You're right, I just blindly assumed the vanilla compiler was producing a compiler error for this scenario as described in the issue. The change I made is irrelevant here because no contextual typing is occurring.

Perhaps the issue was already fixed somewhere else? I'm not seeing any compiler errors in 2.2.2 with noImplicitAny enabled.

[mhegazy]

Duplicate of #9659