Ignore bivariance in subtype relationship#41979
Ignore bivariance in subtype relationship#41979RyanCavanaugh wants to merge 10 commits intomicrosoft:masterfrom
Conversation
…rameters, allow identical type parameter lists to merge in union signatures
30aca09 to
376a03b
Compare
|
Rebuilt on top of #31023 which is an effective prerequisite to this being palatable |
|
@typescript-bot test this |
|
Heya @RyanCavanaugh, I've started to run the parallelized community code test suite on this PR at 7479b8a. You can monitor the build here. |
|
Heya @RyanCavanaugh, I've started to run the extended test suite on this PR at 7479b8a. You can monitor the build here. |
|
Heya @RyanCavanaugh, I've started to run the parallelized Definitely Typed test suite on this PR at 7479b8a. You can monitor the build here. |
| } | ||
| else if (isArray(visited)) { | ||
| visitedNode = (lift || extractSingleNode)(visited); | ||
| visitedNode = (lift || extractSingleNode)(visited as unknown as NodeArray<Node>); |
There was a problem hiding this comment.
cc @weswigham @ahejlsberg interesting break here. visited is narrowed to Node[] here, but lift is undefined | (arg: NodeArray<Node>) => Node, so we were passing what we only proved to be a Node[] to something that needed a subtype of Node[]. It's not immediately clear to me if this is a bug-in-fact but it's definitely not correct per our normal definitions, i.e. you could not have written
if (lift) lift(visited);on this line
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
|
Closing in favor of the more targeted fix |
Evaluates a potential fix for #41977