Object key completions on overloaded generic function incorrectly shows keys for primitive types

[coder-hxl]

Bug Report

🔎 Search Terms

Refactored function parameter hints with generics are incorrect

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about Functions and Generics .

⏯ Playground Link

No generics normal: Playground link with relevant code

There are generics, the object wording prompt is incorrect: Playground link with relevant code

There are generics, swapping the overloaded function position shows normal: Playground link with relevant code

💻 Code

// We can quickly address your report if:
//  - The code sample is short. Nearly all TypeScript bugs can be demonstrated in 20-30 lines of code!
//  - It doesn't use external libraries. These are often issues with the type definitions rather than TypeScript bugs.
//  - The incorrectness of the behavior is readily apparent from reading the sample.
// Reports are slower to investigate if:
//  - We have to pare too much extraneous code.
//  - We have to clone a large repo and validate that the problem isn't elsewhere.
//  - The sample is confusing or doesn't clearly demonstrate what's wrong.

type GetRes<T> = {
  data: T
}

function get<T = any>(config: string): GetRes<T>
function get<T = any>(config: { url: string }): GetRes<T>
function get<T = any>(config: string | { url: string }): GetRes<T> {
  const url = typeof config === 'string' ? config : config.url
  const data = 1111

  return { data } as GetRes<T>
}

// The object wording prompt is incorrect
get()

🙁 Actual behavior

I also don't know why the position of the string parameter refactoring function affects the type hint of the object parameter refactoring function.

🙂 Expected behavior

Does not affect type hints.

[fatcerberus]

I don't understand - what exactly is it here that you think is a bug? The behavior in all of your examples looks the same to me.

[coder-hxl]

@fatcerberus You can try passing in an object, and you will find that there is no type hint

[RyanCavanaugh]

declare function fn1(s: string): void;
declare function fn1(s: { name: string, age: number }): void;
fn2({ /* ctrl-space here: good (shows name, age) */ })

// Same as fn1 but has a type parameter
declare function fn2<T>(s: string): void;
declare function fn2<T>(s: { name: string, age: number }): void;
fn2({ /* ctrl-space here: bad (shows charAt, etc) */ })

[Andarist]

The difference between those 2 starts in getCandidateForOverloadFailure. This specifically chooses pickLongestCandidateSignature when some signatures have type parameters because choosing createUnionOfSignaturesForOverloadFailure would be too complex here (according to the comment there). And that essentially means here that the first overload is chosen.

Both of those argument types (string | { name: string; age: number; }) reach the completions-related code in the variant without type parameters but the string is successfully discarded by this getApparentProperties call. When type parameters are present we could perhaps discard string to avoid those very dubious completions but we can't easily provide completions for name and age - this would likely require some bigger changes or smarter "candidates for overload failure" selection.