-
Notifications
You must be signed in to change notification settings - Fork 12.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preserve generic substitutions through instantiation more often #53758
base: main
Are you sure you want to change the base?
Preserve generic substitutions through instantiation more often #53758
Conversation
@typescript-bot test this |
Heya @weswigham, I've started to run the perf test suite on this PR at b6f371f. You can monitor the build here. Update: The results are in! |
Heya @weswigham, I've started to run the tarball bundle task on this PR at b6f371f. You can monitor the build here. |
Heya @weswigham, I've started to run the diff-based top-repos suite on this PR at b6f371f. You can monitor the build here. Update: The results are in! |
Heya @weswigham, I've started to run the parallelized Definitely Typed test suite on this PR at b6f371f. You can monitor the build here. Update: The results are in! |
Heya @weswigham, I've started to run the extended test suite on this PR at b6f371f. You can monitor the build here. |
Hey @weswigham, 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 |
@weswigham Here they are:
CompilerComparison Report - main..53758
System
Hosts
Scenarios
TSServerComparison Report - main..53758
System
Hosts
Scenarios
StartupComparison Report - main..53758
System
Hosts
Scenarios
Developer Information: |
Hey @weswigham, the results of running the DT tests are ready. |
@weswigham Here are the results of running the top-repos suite comparing Everything looks good! |
Fixes #53343
This fix ended up being relatively simple, but the issue is anything but. A conditional like
string extends T
produces substitutions onstring
within the true branch of the conditional, so we know allstring
instances can be used asT
s (something sometimes needed to satisfy constraint checks). When we go to instantiate a substitute like this, we would see thatstring
(the base of the substitute) isn't a generic, and go "oh, well, this can just be an intersection then, we don't really need any substitution behaviors anymore", and would instantiate it down to a plainstring & T
. Unfortunately, this discards the information that thatT
came in from a substitution constraint, which, in turn, allows inferring to thatT
. That isn't necessarily bad - it is here, because the inference result doesn't satisfy the condition that produced the substitution, but inferences like this could be producing useful results (especially for conditionals which are usually true). In any case, by preserving the substitution type in instantiation when the constraint is still a type variable, we preserve the substitution-ness of the position into inference, and then skip performing the inferences to the substitution constraint (because we always walk substitution types on the target side back to their base type).I would say that if it turns out these substitution constraint position inferences (which this PR is effectively removing) are actually used usefully in the wild, we could totally keep them (by explicitly inferring to the substitution constraint), but we need to make them at a much lower priority than we do now (so they don't override other, non-conditional inferences), or, better yet, conditionalize them on the result of their associated conditional passing with the given inference candidate. (which we could do by tracking conditions as we descend through inference and instantiating and testing them all as we produce inference results.)