Treat trailing 'void' as optional for assignability #40231
Conversation
typescript-bot
added
Author: Team
For Uncommitted Bug
|
@typescript-bot perf test |
|
Heya @rbuckton, I've started to run the perf test suite on this PR at 3bbbe28. You can monitor the build here. Update: The results are in! |
|
@rbuckton Here they are:Comparison Report - master..40231
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
@typescript-bot test this |
rbuckton
force-pushed
the
optionalVoidAssignability
branch
from
a8e319b to
3bbbe28
Compare
| @@ -29,7 +29,7 @@ const inputALike: ArrayLike<A> = { length: 0 }; | |||
| const inputARand = getEither(inputA, inputALike); | |||
| >inputARand : ArrayLike<A> | Iterable<A> | |||
| >getEither(inputA, inputALike) : ArrayLike<A> | Iterable<A> | |||
| >getEither : <T>(in1: Iterable<T>, in2: ArrayLike<T>) => Iterable<T> | ArrayLike<T> | |||
| >getEither : <T>(in1: Iterable<T>, in2: ArrayLike<T>) => ArrayLike<T> | Iterable<T> | |||
There was a problem hiding this comment.
Its likely due to the fact that we now compare a signature with a trailing void that we would have previously skipped because the minArgumentCount didn't match, and as a result we encounter ArrayLike during type checking earlier than we do Iterable. As a result, ArrayLike ends up with an earlier type id and thus its order in the union changes.
|
I'll need to fix the DT tests for |
|
@typescript-bot user test this |
|
@weswigham the Parallel community tests are failing to create a PR for me to review. I know this normally happens if the PR already exists, but I can't find any PR created for this under https://github.com/typescript-bot/TypeScript/pulls. It's failing here: https://typescript.visualstudio.com/TypeScript/_build/results?buildId=83325&view=logs&j=275f1d19-1bd8-5591-b06b-07d489ea915a&t=d6d1571a-a17f-534d-f3cd-109ff09fc86e&l=33 |
|
Looks like the commit fails - it most commonly fails if there's no diff to commit. If there's no diff to commit, but it's still failing, it's usually because it had a crash, which is reported somewhere in the build log. Except, looking at the build log, it looks to me like there should be some diffs (some logs definitely changed, though the dockerfile tests seem to be failing on building a tarball of the compiler itself, which could indicate an issue with LKG), so it's possible the commit failed for another reason; but whatever it was, it wasn't reported on stderr... |
I’ve now fixed that in DefinitelyTyped/DefinitelyTyped#47049. I’ve also future‑proofed the tests so that |
|
As far as I can tell, all of the community test failures are just due to differences between the baselines and the current versions of the community projects, nothing seems to stand out as being related to this change. |
|
Local RWC run looks good (removes a few errors due to the assignability logic for treating |
|
I will look into adding |
This adds checking for
voidtypes ingetMinArgumentCountso that we not only treatvoidparams as optional for function calls, but also for assignability.This does not yet support the recent addition of treating
unknown,any, orundefinedas optional in JS files as there is noNodeavailable that can be used as the context for the assignment to know whether we are currently in a JS file.Related #36749
Fixes #40227
This does not address #29131, as that issue will require a separate change in overload resolution.