Resolve cyclic dependencies in in-place metadata initialization of value types #18214
Conversation
This file contains 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. |
|
Build failed |
rjmccall
force-pushed
the
in-place-value-metadata-dependencies
branch
from
cb936cd
to
ac14b77
Compare
|
@swift-ci Please test. |
|
Build failed |
|
Build failed |
rjmccall
force-pushed
the
in-place-value-metadata-dependencies
branch
from
ac14b77
to
a471111
Compare
|
@swift-ci Please test. |
|
Build failed |
|
Build failed |
rjmccall
force-pushed
the
in-place-value-metadata-dependencies
branch
from
a471111
to
1b94dc3
Compare
…t layout. The central thrust of this patch is to get these metadata initializations off of `swift_once` and onto the metadata-request system where we can properly detect and resolve dependencies. We do this by first introducing runtime support for resolving metadata requests for "in-place" initializations (committed previously) and then teaching IRGen to actually generate code to use them (this patch). A non-trivial amount of this patch is just renaming and refactoring some of existing infrastructure that was being used for in-place initializations to try to avoid unnecessary confusion. The remaining cases that are still using `swift_once` resolution of metadata initialization are: - non-generic classes that can't statically fill their superclass or have resilient internal layout - foreign type metadata Classes require more work because I'd like to switch at least the resilient-superclass case over to using a pattern much more like what we do with generic class instantiation. That is, I'd like in-place initialization to be reserved for classes that actually don't need relocation. Foreign metadata should also be updated to the request/dependency scheme before we declare ABI stability. I'm not sure why foreign metadata would ever require a type to be resolved, but let's assume it's possible. Fixes part of SR-7876.
rjmccall
force-pushed
the
in-place-value-metadata-dependencies
branch
from
1b94dc3
to
dc052e6
Compare
|
Failed to protect against |
|
@swift-ci Please smoke test. |
1 similar comment
|
@swift-ci Please smoke 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.
The central thrust of this PR is to get these metadata initializations off of
swift_onceand onto the metadata-request system where we can properly detect and resolve dependencies. We do this by first introducing runtime support for resolving metadata requests for "in-place" initializations and then teaching IRGen to actually generate code to use them.The remaining cases that are still using
swift_onceresolution of metadata initialization are:non-generic classes that can't statically fill their superclass or
have resilient internal layout
foreign type metadata
Classes require more work because I'd like to switch at least the resilient-superclass case over to using a pattern much more like what we do with generic class instantiation. That is, I'd like in-place initialization to be reserved for classes that actually don't need relocation. Maybe that doesn't work given some of our goals of allowing system classes to be updated to become Swift in the future.
Foreign metadata should also be updated to the request/dependency scheme before we declare ABI stability. I'm not sure why foreign metadata would ever require a type to be resolved, but let's assume it's possible.