Skip to content

GSB: Better handling of unresolved DependentMemberTypes in maybeResolveEquivalenceClass() #35907

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

Conversation

slavapestov
Copy link
Contributor

A DependentMemberType can either have a bound AssociatedTypeDecl,
or it might be 'unresolved' and only store an identifier.

In maybeResolveEquivalenceClass(), we did not handle the unresolved
case when the base type of the DependentMemberType had itself been
resolved to a concrete type.

Fixes rdar://problem/71162777.

@slavapestov slavapestov requested a review from CodaFi February 11, 2021 05:16
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov slavapestov force-pushed the gsb-unresolved-nested-type-of-concrete-type branch from 8400c32 to 52e4cf7 Compare February 11, 2021 05:18
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

Cool, the PR test failed because this also resolved an older crasher.

@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

Copy link
Member

@DougGregor DougGregor 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, thanks!

return ResolvedType::forUnresolved(nullptr);

auto bestConcreteTypeIter =
std::min_element(concreteDecls.begin(), concreteDecls.end(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This rule is effectively arbitrary, because we don't have a way to handle ambiguity? I suppose that's no worse than what we have today.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copy and pasted the code from further down in the function. I should extract it out into a helper at some point.

…veEquivalenceClass()

A DependentMemberType can either have a bound AssociatedTypeDecl,
or it might be 'unresolved' and only store an identifier.

In maybeResolveEquivalenceClass(), we did not handle the unresolved
case when the base type of the DependentMemberType had itself been
resolved to a concrete type.

Fixes <rdar://problem/71162777>.
@slavapestov slavapestov force-pushed the gsb-unresolved-nested-type-of-concrete-type branch from 84c836b to 5acd795 Compare February 11, 2021 21:33
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov slavapestov merged commit aef551b into swiftlang:main Feb 12, 2021
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.

2 participants