[5.7] IR generation for constrained existentials #42328
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ocols This is preparation for supporting parameterized protocols in protocol compositions. The `sameTypeRequirements` field will probably have to go; it's just not general enough to capture what we want. That's assuming that we keep ExistentialLayout in the long term at all, of course.
Another thing that will be necessary for correctness with compositions of parameterized protocols.
Smaller values of FormalLinkage are actually wider scopes, so std::min'ing with PublicUnique actually just gives you a result that's always PublicUnique. And we need to start with PublicNonUnique because even things derived solely from uniquely-emitted types are not themselves generally unique. I don't want to immediately open the can of worms that fixing this for everyone would entail, so I'm just adding the new version in parallel and moving new clients to it gradually.
Parameterized composition components are preserved over non-parameterized components on the same protocol. They are also preserved even if they are redundant with parameterized derived protocols. Otherwise, they're just put in usual protocol order. This assumes that argument lists on the same protocol are always redundant with each other, which may not be correct when we add abstract constraints. We are also, of course, still not making an effort to diagnose conflicts.
The basic concept here was previously laid out in the metadata system commits adding ExtendedExistentialTypeShape, but to recap, we want to produce (for any existential type, but we're really only going to use it for constrained or otherwise generalized existentials) a "shape" signature and type that will be agreed upon by all possible abstractions of the type. In this signature+type pair, any substitutable position in the original type is abstracted as a parameter in the signature, which the original type is a concrete application of. This permits agreement on the type in the face of runtime generic execution. I have made every effort to support protocol compositions in the code I've written, but of course until you're allowed to actually write them, that's all untested. I have not yet implemented signature minimization of the generalization signature. I think this will be necessary in order to ensure that there are no non-redundant parameters, especially for compositions, which is something the runtime currently assumes and is better for code size anyway. But it can wait a few days, I think.
structure for a string
Disabled for now; there's apparently a bug.
|
Please test with following pull request: @swift-ci Please test |
hborla
approved these changes
Apr 13, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
5.7 version of #42317