Skip to content

[4.0] [GSB] Record unresolved potential archetypes as delayed requirements. #10410

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

Conversation

DougGregor
Copy link
Member

@DougGregor DougGregor commented Jun 20, 2017

Explanation: Whenever we form a potential archetype that is unresolved, use the delayed-requirements mechanism to ensure that every such potential archetype gets resolved
Scope: We've seen several different compiler crashers from this, several of which (but not all) involving typo correction within generic signatures.
Radar: rdar://problem/31401161, rdar://problem/31048352, rdar://problem/32077627.
Risk: Relatively low; uses existing mechanisms and is effectively a no-op where it wasn't needed.
Testing: Compiler regression testing.

DelayedRequirements were using the general RequirementKind, which was
at best an approximation (we smoothed over the difference between
Superclass and Conformance requirements). Split out the Kind into its
own type, so we can extend it with GSB-specific kinds.

(cherry picked from commit aac0574)
Whenever we form a potential archetype that is unresolved (because it
names a member wasn't known at the time the potential archetype was
formed), create a corresponding delayed requirement to resolve the
potential archetype. This ensures that all potential archetypes get a
chance to be resolve, fixing the

  nested type should have matched associated type

assertion in rdar://problem/31401161 (and others).

(cherry picked from commit 4860607)
Rather than performing typo correction at the very end of finalize(),
do it as part of delayed requirement handling when we cannot otherwise
make progress. This is a cleaner way to cope with typo correction that
gives us a better chance of getting to a sane result.

Fixes rdar://problem/31048352 by eliminating the need for tracking the
number of unresolved potential archetypes altogether. Fixes
rdar://problem/32077627.

(cherry picked from commit fe7ba8b)
(cherry picked from commit 9f0f71d)
@DougGregor DougGregor added this to the Swift 4.0 milestone Jun 20, 2017
@DougGregor DougGregor requested review from slavapestov and huonw June 20, 2017 20:08
@DougGregor
Copy link
Member Author

@swift-ci please test

@slavapestov
Copy link
Contributor

LGTM!

/*AllowReplacements=*/true,
maxScore);
assert(dist > 0 && "nested type should have matched associated type");
if (bestEditDistance == 0 || dist == bestEditDistance) {
Copy link
Contributor

Choose a reason for hiding this comment

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

(Couldn't this special case be removed by starting with unsigned bestEditDistance = maxScore + 2; or something similar?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I could probably clean this up. It didn't touch it in this particular PR; just moved it earlier so I could make use of it.

@ematejska ematejska merged commit 2d93b21 into swiftlang:swift-4.0-branch Jun 21, 2017
@DougGregor DougGregor deleted the gsb-unresolved-types-4.0 branch June 21, 2017 04:37
@huonw huonw mentioned this pull request Jun 21, 2017
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.

4 participants