Repository navigation
Experiment: Remove lower priority from contextual signature instantiation return type inference - #58321
Conversation
|
TypeScript Bot (@typescript-bot) test top200 |
|
Starting jobs; this comment will be updated as builds start and complete.
|
|
TypeScript Bot (@typescript-bot) pack this |
|
Hey Andrew Branch (@andrewbranch), I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running There is also a playground for this build and an npm module you can use via |
|
TypeScript Bot (@typescript-bot) test top200 |
|
Hey Andrew Branch (@andrewbranch), I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running There is also a playground for this build and an npm module you can use via |
| !!! error TS2322: Type 'Obj[K]' is not assignable to type 'U[K]'. | ||
| !!! error TS2322: Type 'Obj' is not assignable to type 'U'. | ||
| !!! error TS2322: 'U' could be instantiated with an arbitrary type which could be unrelated to 'Obj'. No newline at end of file | ||
| !!! error TS2322: Type '{ [K in keyof U]: Obj[K]; }' is not assignable to type '{ [x: string]: number; }'. |
There was a problem hiding this comment.
I wrote this test to exercise a very specific inference code path in the PR that introduced it, so it's not grounded in a real world scenario, but I don't think the new error is worse? Maybe the connection between the error and the actual code is more surprising now just because we end up inferring T = { [x: string]: number } instead of T = U.
Maybe that's a separate problem with signature comparison: it's not immediately clear to users that we've done inference in order to compare two signatures, and it's not immediately clear what the result of that inference was.
|
Andrew Branch (@andrewbranch) Here are the results of running the top 400 repos comparing Something interesting changed - please have a look. Details
|
No description provided.