Don't let reflection handle noncopyable types yet. #64295
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
|
@swift-ci Please test |
mikeash
approved these changes
Mar 10, 2023
jckarter
force-pushed
the
noncopyable-hide-field-types
branch
from
3872b69 to
9983b9d
Compare
|
@swift-ci Please test |
jckarter
force-pushed
the
noncopyable-hide-field-types
branch
from
9983b9d to
7509453
Compare
|
@swift-ci Please test |
1 similar comment
|
@swift-ci Please test |
We don't have any language or runtime support for noncopyable types as generic or dynamic types yet, and existing reflection code almost certainly assumes it can copy the values it's working with, and will trap or corrupt state if it does so with noncopyable types. But a class can have noncopyable fields while the type itself is copyable, and existing code assumes that it can use `Mirror` or other reflection mechanisms to safely traverse the contents of an arbitrary class. Allow this sort of code to continue working, while still preparing for forward compatibility with future runtimes that do support noncopyable generics, by emitting the type references for fields using a function that probes the address of a new symbol in the Swift runtime. The symbol will either be missing or defined with an absolute address of zero in current or previous runtime versions, but can be changed to a non-null address in the future.
jckarter
force-pushed
the
noncopyable-hide-field-types
branch
from
7509453 to
4d6d765
Compare
|
@swift-ci Please test |
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.
We don't have any language or runtime support for noncopyable types as generic or dynamic types yet, and existing reflection code almost certainly assumes it can copy the values it's working with, and will trap or corrupt state if it does so with noncopyable types. But a class can have noncopyable fields while the type itself is copyable, and existing code assumes that it can use
Mirroror other reflection mechanisms to safely traverse the contents of an arbitrary class.Allow this sort of code to continue working, while still preparing for forward compatibility with future runtimes that do support noncopyable generics, by emitting the type references for fields using a function that probes the address of a new symbol in the Swift runtime. The symbol will either be missing or defined with an absolute address of zero in current or previous runtime versions, but can be changed to a non-null address in the future. If the symbol is missing or zero, then lie to the requester and say that the field has empty tuple type, so that they hopefully pass over the field without being able to do anything with the value.