-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[GSB] Reduce use of potential archetypes when describing constraints #12536
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
[GSB] Reduce use of potential archetypes when describing constraints #12536
Conversation
We're still eagerly resolving the subject to a potential archetype everywhere, but this refactoring allows us to start introducing laziness.
…he class. It's getting big, and there will soon be an ordering dependency with FloatingRequirementSource. NFC
Eliminate potential archetypes from most of the public interface of RequirementSource.
…ces. Refactor the interfaces that involve “walking” a requirement source (e.g., minimization, computation of the affected type, etc.) to rely only on interface types and not potential archetypes.
@swift-ci please smoke test |
Eliminates another too-early source of realization of potential archetypes.
/// Retrieve the generic signature builder with which this archetype is | ||
/// associated. | ||
/// FIXME: Only EquivalenceClassVizIterator gets to use this. | ||
GenericSignatureBuilder *getBuilder() const { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is this still needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are several callers still, but not so many that we can't eliminate their dependence on getBuilder()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sigh, that took longer than expected. It's gone now.
The remaining two uses after this refactor are... stubborn.
This allows us to eliminate `getBuilder()`.
Now that getBuilder() is gone, stash an ASTContext into root PotentialArchetypes instead of a GenericSignatureBuilder. This eliminates some ickiness where we had to re-root potential archetypes when moving a GenericSignatureBuilder.
@swift-ci please smoke test |
@swift-ci please test compiler performance |
@swift-ci please smoke test |
@swift-ci please test compiler performance |
Build comment file:Compilation-performance test failed |
@graydon there was a failure with the compiler performance test |
@swift-ci please smoke test compiler performance |
1 similar comment
@swift-ci please smoke test compiler performance |
Start delaying the realization of potential archetypes in a few ways:
Constraint
can now store a dependent type that will be lazily (and explicitly) realized to a potential archetypeRequirementSource
APIs traffic mostly in dependent types now