Skip to content
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

Merged
merged 3 commits into from
Aug 28, 2018
Merged

Conversation

ahejlsberg
Copy link
Member

Fixes #26409.

@ahejlsberg
Copy link
Member Author

@typescript-bot test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Aug 27, 2018

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.

Copy link
Member

@weswigham weswigham left a 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);
Copy link
Member

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?

Copy link
Member Author

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)) {
Copy link
Member

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.

Copy link
Member Author

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.

@sandersn
Copy link
Member

@ahejlsberg This causes some good errors to disappear in the user tests. Mind taking a look? #26712

@RyanCavanaugh
Copy link
Member

Logged #26714

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants