-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Improve indexed access type relations #26698
Conversation
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at d369cec. You can monitor the build here. It should now contribute to this PR's status checks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good - I actually like this more than the existing index type constraint code by a bit - it much more clearly defines the hierarchy of constraints we check. Just some clarifying questions.
return constraint && constraint !== errorType ? constraint : undefined; | ||
const objectType = getConstraintOfType(type.objectType) || type.objectType; | ||
if (objectType !== type.objectType) { | ||
const constraint = getIndexedAccessType(objectType, type.indexType, /*accessNode*/ undefined, errorType); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this still result in a type we may need to get the constraint of if the constraint of tyoe.objectType
is a generic mapped type (since an index on a mapped type is trivially bounded by the mapped type's template)? Or is getConstraintOfType
not the variant that can do that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the constraint of type.objectType
is a mapped type, we do indeed fetch that here and form a new indexed access. If type.objectType
itself is a mapped type, the getConstraintOfType
function does nothing, and we'll fall into the base constraint code below.
@@ -7074,9 +7079,6 @@ namespace ts { | |||
if (t.flags & TypeFlags.Substitution) { | |||
return getBaseConstraint((<SubstitutionType>t).substitute); | |||
} | |||
if (isGenericMappedType(t)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes the constraint of a generic mapped type itself, right? I guess that makes sense since indexed accesses work that way already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. I'm not sure why this code was here, but it definitely isn't right. Removing it had no effect on baselines (including RWC baselines), but it fixes the second issue I found while exploring #26409.
@ahejlsberg This causes some good errors to disappear in the user tests. Mind taking a look? #26712 |
Logged #26714 |
Fixes #26409.