SILGen: Emit property descriptors for conditionally Copyable and Escapable types. #81617
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
|
@swift-ci Please test |
xedin
approved these changes
May 19, 2025
jckarter
force-pushed
the
no-non-escapable-property-descriptors
branch
from
177d989 to
2ae0954
Compare
|
@swift-ci Please test |
jckarter
force-pushed
the
no-non-escapable-property-descriptors
branch
from
2ae0954 to
3aedcc0
Compare
|
@swift-ci Please test |
|
@swift-ci Please test Linux |
slavapestov
reviewed
May 24, 2025
|
|
||
| // If the type is an archetype, then it just needs Copyable and Escapable | ||
| // constraints imposed. | ||
| if (ty->is<ArchetypeType>()) { |
There was a problem hiding this comment.
lookupConformance() returns an abstract conformance if you give it an archetype or a type parameter. Is this conditional necessary?
There was a problem hiding this comment.
lookupConformance seems to actually check the conformances of ArchetypeTypes, which I don't want here. The doc comment for lookupConformance does say it doesn't check conditional conformances, so it seems like it would be morally appropriate for it to unconditionally return an abstract conformance given an archetype, but (at least for 6.2) I didn't want to track down all the reliances on the existing behavior.
…pable types. Key paths can't reference non-escapable or non-copyable storage declarations, so we don't need to refer to them resiliently, and can elide their property descriptors. However, declarations may still be conditionally Copyable and Escapable, and if so, then they still need a property descriptor for resilient key path references. When a property or subscript can be used in a context where it is fully Copyable and Escapable, emit the property descriptor in a generic environment constrained by the necessary conditional constraints. Fixes rdar://151628396.
jckarter
force-pushed
the
no-non-escapable-property-descriptors
branch
from
3aedcc0 to
22eb7e6
Compare
|
@swift-ci Please test |
jckarter
changed the title
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.
Key paths can't reference non-escapable or non-copyable storage declarations,
so we don't need to refer to them resiliently, and can elide their property
descriptors.
However, declarations may still be conditionally Copyable and Escapable, and
if so, then they still need a property descriptor for resilient key path
references. When a property or subscript can be used in a context where it
is fully Copyable and Escapable, emit the property descriptor in a generic
environment constrained by the necessary conditional constraints.
Fixes rdar://151628396.