You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR moves that call from inferFromObjectTypesWorker() to the third case. Consequently
inferFromIndexTypes() isn't called twice in the second (array) case
it isn't called at all in the first (tuple) case, so f2(values) is 1 like f1(values)
FYI f1(values) is currently 1 unlike f2(values) because parameter and argument are the same generic type (tuple) and handled by
if(getObjectFlags(source)&ObjectFlags.Reference&&getObjectFlags(target)&ObjectFlags.Reference&&((<TypeReference>source).target===(<TypeReference>target).target||isArrayType(source)&&isArrayType(target))&&!((<TypeReference>source).node&&(<TypeReference>target).node)){// If source and target are references to the same generic type, infer from type argumentsinferFromTypeArguments(getTypeArguments(<TypeReference>source),getTypeArguments(<TypeReference>target),getVariances((<TypeReference>source).target));}
whereas f2(values) parameter (readonly tuple) and argument (tuple) aren't.
Heya @RyanCavanaugh, I've started to run the parallelized community code test suite on this PR at e427f3f. You can monitor the build here. It should now contribute to this PR's status checks.
Heya @RyanCavanaugh, I've started to run the extended test suite on this PR at e427f3f. You can monitor the build here. It should now contribute to this PR's status checks.
@weswigham Thanks a lot for taking a look at this! What you describe would call inferFromIndexTypes() just once, however it would still call it in the tuple case, so I assume it wouldn't resolve the test case included in this issue: Inferring an array type instead of a tuple type.
inferFromProperties() infers a tuple type element-wise, but then inferFromObjectTypesWorker() calls inferFromIndexTypes() which re-infers an array type. ❌
however it would still call it in the tuple case, so I assume it wouldn't resolve the test case included in this issue: Inferring an array type instead of a tuple type
Hm, if that's the case, can we copy the tuple check into the inferFromObjectTypesWorker instead of shifting inferFromIndexSignatures into inferFromProperties? I don't like the implicit linkage of index inference to property inference caused by the current layering.
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think this is fine now (it just moves a chunk of code out of a call and into the (only) caller), I just wanted @ahejlsberg to look at it briefly before it got in, which is why he's assigned iirc.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #33559
Fixes #33752
Fixes
#34924Fixes #34925
Fixes #34937
Fixes
#35136Fixes
#35258Currently
f2(values)
isnumber
whilef1(values)
is1
.There are three cases in
inferFromProperties()
inferFromIndexTypes()
But then
inferFromObjectTypesWorker()
callsinferFromIndexTypes()
again, in all casesThis PR moves that call from
inferFromObjectTypesWorker()
to the third case. ConsequentlyinferFromIndexTypes()
isn't called twice in the second (array) casef2(values)
is1
likef1(values)
FYI
f1(values)
is currently1
unlikef2(values)
because parameter and argument are the same generic type (tuple) and handled bywhereas
f2(values)
parameter (readonly tuple) and argument (tuple) aren't.