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

CallableFunction inference does not match runtime behavior #30294

Closed
karol-majewski opened this issue Mar 9, 2019 · 4 comments · May be fixed by #52944
Closed

CallableFunction inference does not match runtime behavior #30294

karol-majewski opened this issue Mar 9, 2019 · 4 comments · May be fixed by #52944
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@karol-majewski
Copy link

TypeScript Version: 3.4.0-dev.20190309

Search Terms: CallableFunction, call, bind, inference

Code

Promise.resolve.call(1)           // Compiles without error, throws in runtime
Promise.resolve.call(Promise, 1); // Compile-time error, works fine in runtime

Expected behavior:

  • Promise.resolve.call(1) should trigger a compile-time error
  • Promise.resolve.call(Promise, 1) should compile

Actual behavior:

The situation is reversed. The one that works in runtime does not compile. The one that does compile throws a runtime error.

  • Promise.resolve.call(1) compiles without error, throws Uncaught TypeError: PromiseResolve called on non-object in runtime
  • Promise.resolve.call(Promise, 1) gives a compile-time error (Expected 1 arguments, but got 2.), works fine in runtime (returns a Promise<number>)

I'm using "lib": ["dom", "esnext"], "target: "es2015". Tested on Chrome 72.0.3626.121, V8 7.2.502.28.

Playground Link: The compile-time error is not there, but the runtime exception can be observed

@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Mar 19, 2019
@RyanCavanaugh
Copy link
Member

@rbuckton bug or no?

@rbuckton
Copy link
Member

rbuckton commented Mar 19, 2019

@RyanCavanaugh: This is likely due to overload resolution related to --strictBindCallApply, as we see the same error in this case:

declare class C {
  static x(y: number): number;
  static x(): number;
}
C.x.call(C, 1); // error, but should be ok
C.x.call(C); // ok
C.x.call(1); // ok (not an error because the `this` type of `x` is not constrained)

@rbuckton
Copy link
Member

rbuckton commented Mar 19, 2019

Note that if you switch the order of the overloads, you get the exact opposite results (C.x.call(C, 1) works but C.x.call(C) and C.x.call(1) fail).

@rbuckton
Copy link
Member

@RyanCavanaugh: Not a bug per se, as we have documented this is the expected behavior, however it does result in a poor user experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
3 participants