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.

Sign up for GitHub

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

Jump to bottom

[Generic Signature Builder] Improve the handling of typealiases in protocols. #7389

Merged
merged 3 commits into from Feb 21, 2017
Merged

[Generic Signature Builder] Improve the handling of typealiases in protocols. #7389

merged 3 commits into from Feb 21, 2017

Conversation

huonw
Copy link
Contributor

@huonw huonw commented Feb 10, 2017 •
edited

Previously, the following example

protocol P {
    associatedtype A
    typealias X = A
}
protocol Q {
    associatedtype B: P
}

func requirementOnNestedTypeAlias<T>(_: T) where T: Q, T.B.X == Int {}

would result in the T.B.X == Int requirement being dropped, because it adopted the (Protocol) RequirementSource of the T.B.X == T.B.A same-type requirement implied by the typealias declaration.

DougGregor
DougGregor requested changes Feb 10, 2017
View reviewed changes
lib/AST/ArchetypeBuilder.cpp Outdated
SubstitutionMap subMap;
subMap.addSubstitution(self, concreteSelf);
subMap.addConformance(self, ProtocolConformanceRef(proto));
auto typeHere = typeInProtocol.subst(subMap);
Copy link
Member

Choose a reason for hiding this comment

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

@slavapestov is going to be grouchy at building the substitution map this way. Can you just provide the trivial lookup functions that handle "self -> concreteSelf" and the construction of the abstract conformance? There's no need to build a full substitution map here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, I didn't realize I could subst with a closure.

Copy link
Member

Choose a reason for hiding this comment

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

Even better would be to use the new SubstitutionMap::getProtocolSubstitutions() function. It handles exactly this case where you're replacing Self and you have a conformance.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks! I noticed that and have it in my local branch already... currently trying to make the rest of the patch work properly/clean.

lib/AST/ArchetypeBuilder.cpp Outdated
// (e.g. protocol P { associatedtype A; typealias B = A }), so we need to
// resolve that.
auto concrete = pa->getConcreteType();
auto rhsPA = resolveArchetype(concrete, basePA);
Copy link
Member

Choose a reason for hiding this comment

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

The assertion above is the reason we don't need to recursively call resolveArchetypeOrTypeThroughTypeAlias here, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes; I'll add a comment.

lib/AST/ArchetypeBuilder.cpp Outdated
return type;

pa = pa->getRepresentative();
if (!pa->getParent() || !pa->getTypeAliasDecl())
Copy link
Member

Choose a reason for hiding this comment

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

Hmm... it occurs to me that there might be direct callers to addSameTypeRequirementBetweenArchetypes that unknowingly end up with a typealias for one of the archetypes. Should this logic be sunk down into that function instead?

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 think the only remaining direct callers are either addSameTypeRequirement, or are in places where equating to the type alias PA directly seems correct, specifically: potential archetype typo correction, equating any new PAs inside getNestedType itself, and recursively to merge the PAs.

However, having it inside addSameTypeRequirementBetweenArchetypes does seem like it might be nicer.

@huonw
Copy link
Contributor Author

huonw commented Feb 16, 2017

I've updated this in a fairly invasive way.

DougGregor
DougGregor approved these changes Feb 16, 2017
View reviewed changes
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.

This is way cleaner. Looks great!

@DougGregor
Copy link
Member

@swift-ci please smoke test

1 similar comment
@DougGregor
Copy link
Member

@swift-ci please smoke test

@DougGregor
Copy link
Member

Looks like some compiler crashers regressed due to the llvm_unreachable.

huonw
huonw commented Feb 16, 2017
View reviewed changes
lib/AST/GenericSignatureBuilder.cpp Outdated
PotentialArchetype *getPotentialArchetype() const {
return paOrT.dyn_cast<PotentialArchetype *>();
}
bool isUnresolvedTypeAlias() const { return unresolvedTypeAlias; }
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note to self: this needs renaming.

lib/AST/GenericSignatureBuilder.cpp Outdated
// (e.g. protocol P { associatedtype A; typealias B = A }), so we need to
// resolve that. However, the archetype should always be resolved far enough
// upon creation to not be another type alias (verified by the assertion
// below), and hence this function doesn't need to be recursive..
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note to self: this comment is outdated.

@slavapestov slavapestov mentioned this pull request Feb 17, 2017
Merged
@huonw huonw changed the title [AST] Use the correct Self PA for resolution of typealiases in protocols. [Generic Signature Builder] Improve the handling of typealiases in protocols. Feb 20, 2017
@huonw
Copy link
Contributor Author

huonw commented Feb 20, 2017

Another update, removing the reimplementation of #7563, among other things.

There's an unfortunate FIXME in getNestedType that is stopping diagnostics about typealiases with mismatching types from being emitted eagerly, instead they are currently only emitted when the typealias is used.

@huonw
[Generic signature builder] resolve types deeper in same type require…
f64ef03 
…ments.

This adds the concept of an "unresolved type" and a "resolved type",
where the latter involves stripping away any typealias archetype layers
from the former, to get to the "true" potential archetype or concrete
type that something refers to.
@huonw
[Generic signature builder] diagnose typealiases with the same name a…
d514e01 
…nd different types.

At the moment, these are only done on demand, when the typealias is
actually used somewhere, because there's currently a recursive
validation loop that stops doing it more eagerly from working in many
cases.
@huonw
[Generic signature builder] paper over problems with generic typealia…
d671a65 
…ses in protocols.

Generic typealiases are entirely broken as archetypes, but some things
mostly worked with them before introducing ResolvedType, so let's
restore that behaviour.
@huonw
Copy link
Contributor Author

huonw commented Feb 21, 2017

@swift-ci Please test

@swift-ci
Copy link
Collaborator

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 4927c77e0c4aa3b48db75e29435e994ced831354
Test requested by - @huonw

@swift-ci
Copy link
Collaborator

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 4927c77e0c4aa3b48db75e29435e994ced831354
Test requested by - @huonw

@DougGregor
Copy link
Member

I recommend smoke tests :)

@huonw
Copy link
Contributor Author

huonw commented Feb 21, 2017

@swift-ci Please smoke test and merge

@DougGregor
Copy link
Member

@swift-ci please smoke test Linux

@huonw huonw merged commit e58c6b3 into apple:master Feb 21, 2017
@huonw huonw deleted the protocol-type-aliases branch February 21, 2017 20:49
huonw added a commit to huonw/swift that referenced this pull request Feb 23, 2017
@huonw
[Test] -typecheck -> -emit-ir in test fixed by apple#7389.
39dd23d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@slavapestov slavapestov slavapestov left review comments

@DougGregor DougGregor DougGregor approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@huonw @DougGregor @swift-ci @slavapestov