Repository navigation
.call on an union with different arguments counts fails when passing any #58468
Description
🔎 Search Terms
call union expected arguments but got
🕗 Version & Regression Information
Before version 4.5 both the .calls in the example below failed. Since then, .call(null, something-not-any) is accepted and .call(null, something-any) failes.
⏯ Playground Link
💻 Code
declare const fn: (() => void) | ((a: number) => void)
declare const x: number;
declare const y: any;
fn.call(null, x); // ok
fn.call(null, y); // error
fn(y); // ok
fn(x); // ok🙁 Actual behavior
The line marked as // error gives the following error:
Expected 1 arguments, but got 2.
🙂 Expected behavior
It should be accepted, the same as the other lines are accepted.
Additional information about the issue
No response
TODO for myself: Remove @ts-ignore in https://github.com/babel/babel/blob/main/packages/babel-generator/src/printer.ts#L717 once this is fixed
Activity
Andarist commentedon May 8, 2024
I love fun issues. Expect me digging into this one later 😉
Andarist commentedon May 9, 2024
So in this case we end up with multiple inference candidates. We have:
[any][]and[a: number]When multiple inference candidates are present, TS tries to select the best match based on different criteria. Since contravariant candidates don't overlap sufficiently enough the first one gets picked as overall
inferredContravariantType. Not: This is order-dependent so when you switch the order of ur union members it magically works because the other one gets picked there.Since we have both
inferredCovariantTypeandinferredContravariantTypewe also need to pick between those 2. It happens so thatpreferCovariantTypegets computed asfalsein your case. It's rejected based on this check:[any]is not a subtype of either of the contravariant candidates, it's not a subtype of[]and it's not a subtype of[a: number]. So it ends up picking the covariant candidate and it fails to typecheck ur arguments against inferred signature further down the line.So it turns out one of my PR fixes this case alrady: #57909
But what happens in the implementation here got me thinking... why do we even have multiple contravariant candidates here? we do have that because the inference infer from each of your signatures separately here. This is kinda a single call though. TS is able to combine union (or intersection) signatures into one. Shouldn't we then infer from that combined signature here?
So that led me to creating this experiment that also addresses this issue: #58482