Skip to content

[AST] Prefer 'synthesized' conformances to 'implied' ones consistently. #14385

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

Merged
merged 2 commits into from
Feb 3, 2018

Conversation

DougGregor
Copy link
Member

When determining which declaration context should own a particular
protocol conformance that was not explicitly spelled out, prefer
"synthesized" contexts (i.e., which is always the nominal type itself)
for automatically-generated conformances (such as a raw-valued enum's
conformance to RawRepresentable) to conformances that are "implied" by
conformance to a more-refined protocol. Previously, we biased the
other way---but because conformances due to more-refined protocols can
be discovered later, we could get into a problem where two files
disagreed on which context would own the conformance---and neither
would emit the corresponding witness table.

Biasing toward "synthesized" contexts, which are always trivially
discoverable from the nominal type declaration itself, eliminates the
issue.

Fixes SR-6839 / rdar://problem/36911943.

When determining which declaration context should own a particular
protocol conformance that was not explicitly spelled out, prefer
"synthesized" contexts (i.e., which is always the nominal type itself)
for automatically-generated conformances (such as a raw-valued enum's
conformance to RawRepresentable) to conformances that are "implied" by
conformance to a more-refined protocol. Previously, we biased the
other way---but because conformances due to more-refined protocols can
be discovered later, we could get into a problem where two files
disagreed on which context would own the conformance---and neither
would emit the corresponding witness table.

Biasing toward "synthesized" contexts, which are always trivially
discoverable from the nominal type declaration itself, eliminates the
issue.

Fixes SR-6839 / rdar://problem/36911943.
@DougGregor
Copy link
Member Author

@swift-ci please smoke test and merge

@swift-ci swift-ci merged commit bf4f284 into swiftlang:master Feb 3, 2018
@DougGregor DougGregor deleted the conformance-location-sr-6839 branch February 3, 2018 07:19
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