Broken Autocomplete and Type Display For Parameters Dependent on Transitively Contextually Typed Return Type

🔎 Search Terms

contextually typed autocomplete, contextually typed type display, contextual return type

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ

⏯ Playground Link

https://www.typescriptlang.org/play/?ssl=2&ssc=13&pln=3&pc=3#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXwFsoBrEAJRAEdkQBnDAHgCh54BFGmATwAVYoCTAHwAKFvADmIDADFUALngjIWEKgyKA3vAAOMHDsWpkBAEYgY8AL4BKeAF4h7Tr34EANOJ1vaigHI4AJKoiBYMHBauMAJCnjaKAG44WMAA3ExMAPSZ8AASOAkWWKgS8AUW8AAGRKQU1HQYlfC0ABY4AO608BgtUBhVEdx80QRNWF3FoTBwwPBQXZVoxKgdqE1QqLOV3iO0Y104pvRqtFimEFzdXDogs-NVSyvta-DtLVhgLfDj3+h4EjBkDhkF12lget13l0wFAIBBvl0NvALPoYAA6Jg1chUGj0MSsVjKCCqdR2RzwFRqDCeAnwbLwACqpxKc2QGBwYBwBB0EGkCBaFgQtGQEik9C6K10+huMAwl1IXFoGNpmisnnpAD14ABBGASExUsqIK43eAAclVZoR8BW-XmpwkqCg5wQ7N0bj5lhwxrlpotUoMRhM5hgqWsZoxNnSmJI2PqePEhMp6i0AcMNuDFVsDicyepibpOSZxVKUDZHK5PL58AFcBtHWaIrFGC6CqVBdVcVSQA

💻 Code

declare function makeRequest<
  QueryParam
>(
  getFn: (client: { prop: number }) => QueryParam,
  params: NoInfer<QueryParam>,
): void;

// Hovering over `makeRequest` shows that `QueryParam` is inferred as `unknown` and `params` is obstensibly typed as `unknown` which is incongruous with this call is an error.
makeRequest(
    (client) => client,
    {},  // Using autocomplete in the object suggests no property keys.
// ^ Argument of type '{}' is not assignable to parameter of type '{ prop: number; }'.
);

makeRequest(
    (client: { prop: number }) => client,
    {}, // Using autocomplete here now suggests keys.
);

🙁 Actual behavior

The first call to makeRequest where client is contextually typed has broken autocomplete. No relevant properties are suggested. Furthermore hovering over makeRequest shows, incongruously, that params: unknown and yet the call {} causes an error expecting it to be of type { prop: number; }

🙂 Expected behavior

I expected auto-complete to work in all cases and the type display to be consistent.

Additional information about the issue

Related to #46916 but @Andarist hypothesized that the underlying root cause is different in this case so I decided to open it as its own issue for tracking purposes.