-
Notifications
You must be signed in to change notification settings - Fork 10.4k
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
[ABI] Initial draft of canonicalization and minimization of generic signatures #12740
[ABI] Initial draft of canonicalization and minimization of generic signatures #12740
Conversation
docs/ABI/GenericSignature.md
Outdated
2. Constraints follow, ordered first by the | ||
[type parameter ordering](#type-parameter-ordering) of the left-hand | ||
operand and then by constraint kind. The left-hand side of a constraint | ||
is always a type parameter `T`, which can be a generic parameter of a |
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.
"a generic parameter or a"?
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.
Got it, thanks.
docs/ABI/GenericSignature.md
Outdated
nested type thereof (e.g., `T.SubSequence.Iterator.Element`). | ||
Constraints are ordered as follows: | ||
1. A superclass constraint `T: C`, where `C` is a class. | ||
2. A layout constraints (e.g., `T: some-layout`), where the right-hand |
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.
"A layout constraint"
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.
Got it, thanks.
docs/ABI/GenericSignature.md
Outdated
|
||
### Same-type constaints | ||
|
||
The canonical form of superclass, layout, and conformance constraints are trivially canonicalized using the anchor of the appropriate equivalence class. Same-type constraints, on the other hand, are responsible for forming those equivalence classes. Let's expand our running example to include a third `Collection`: |
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.
What about superclass constraints where the right hand side is a generic class?
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.
Yeah, I should call that out. The RHS needs to be a canonical concrete type.
It's not clear to me how we canonicalize concrete structural types that contain type parameters inside of them, eg |
Canonicalizing concrete structural types containing type parameters needs to be called out. I'll push an update shortly that does so, thanks! |
Also address Slava's feedback on the first draft.
I think this is in "good enough" shape to merge. Additional comments are certainly welcome! |
This is a rough, initial draft describing the canonicalization and minimization of generic signatures for the purposes of the ABI. Comments greatly appreciated!
Addresses the documentation part of SR-3733 and rdar://problem/31412994.