[5.0] Recursive metadata fixes omnibus #18383
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
…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.
Leave space for new kinds of non-generic metadata initialization (one of which I'm about to claim for "foreign") and non-default type namespaces.
As part of this, rename TypeMetadataRecordKind to TypeReferenceKind and consistently give it three bits of storage. The better modelling of these type references appears to have been sufficient to make dynamic conformance checks succeed, which is good but unexpected.
|
@swift-ci Please test. |
|
Build failed |
|
Build failed |
|
@swift-ci test |
|
Build failed |
|
Build failed |
|
@swift-ci clean test |
|
Build failed |
|
Build failed |
- `swift_getForeignTypeMetadata` is now a request/response function. - The initialization function is now a completion function, and the pointer to it has moved into the type descriptor. - The cache variable is no longer part of the ABI; it's an implementation detail of the access function. - The two points above mean that there is no special header on foreign type metadata and therefore that they can be marked constant when there isn't something about them that needs to be initialized. The only foreign-metadata initialization we actually do right now is of the superclass field of a foreign class, and since that relationship is a proper DAG, it's not actually possible to have recursive initialization problems. But this is the right long-term thing to do, and it removes one of the last two clients of once-based initialization.
Previously, when a tuple type had non-fixed layout, we would compute a layout by building the metadata for that tuple type and then extracting the layout from the VWT. This can be quite expensive because it involves constructing the exact metadata for types like arrays and functions despite those types being fixed-layout across all instantiations. It also tends to cause unnecessary recursive-type issues, especially with enums where tuples are currently used to model cases with mutliple payloads. Since we just need a layout, computing it directly from element layouts instead of constructing metadata for the formal type lets us take advantage of all the other fast paths for layout construction, e.g. for fixed types and single-field aggregates. This is a good improvement overall, but it also serves to alleviate some of the problems of rdar://40810002 / SR-7876 in a way that might be suitable for integration to 4.2.
rjmccall
force-pushed
the
metadata-fixes-5.0
branch
from
516fe43 to
f56af9b
Compare
|
Screwed up one of the cherry-picks. |
|
@swift-ci Please test. |
|
Build failed |
|
Build failed |
|
@swift-ci test |
|
Build failed |
|
Failures are exactly the same as on #18376, presumably because there's just an SDK mismatch. |
|
@swift-ci Please test macOS |
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.
Cherry-pick a bunch of recursive-metadata fixes over to the temporary Swift 5.0 qualification branch.
rdar://problem/42756323