Support incomplete type metadata #15511
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
GenMeta is already making decisions about what work is done by these functions.
I de-templated MetadataState and MetadataRequest because we weren't relying on the template and because using the template was causing conversion problems due to the inability to directly template an enum in C++.
…asynchronous queries. I keep finding reasons to want such queries and then deciding that they're unnecessary. Let's at least do this much, though.
|
@swift-ci Please test. |
|
Build failed |
This functions returns the metadata purely for liveness purposes.
rjmccall
force-pushed
the
incomplete-type-metadata
branch
from
fe0e343 to
05a4570
Compare
|
@swift-ci Please test and merge. |
1 similar comment
|
@swift-ci Please test and merge. |
|
@swift-ci Please test. |
|
Build failed |
|
Build failed |
|
Build failed |
Most of the work of this patch is just propagating metadata states throughout the system, especially local-type-data caching and metadata-path resolution. It took a few design revisions to get both DynamicMetadataRequest and MetadataResponse to a shape that felt right and seemed to make everything easier. The design is laid out pretty clearly (I hope) in the comments on DynamicMetadataRequest and MetadataResponse, so I'm not going to belabor it again here. Instead, I'll list out the work that's still outstanding: - I'm sure there are places we're asking for complete metadata where we could be asking for something weaker. - I need to actually test the runtime behavior to verify that it's breaking the cycles it's supposed to, instead of just not regressing anything else. - I need to add something to the runtime to actually force all the generic arguments of a generic type to be complete before reporting completion. I think we can get away with this for now because all existing types construct themselves completely on the first request, but there might be a race condition there if another asks for the type argument, gets an abstract metadata, and constructs a type with it without ever needing it to be completed. - Non-generic resilient types need to be switched over to an IRGen pattern that supports initialization suspension. - We should probably space out the MetadataStates so that there's some space between Abstract and Complete. - The runtime just calmly sits there, never making progress and permanently blocking any waiting threads, if you actually form an unresolvable metadata dependency cycle. It is possible to set up such a thing in a way that Sema can't diagnose, and we should detect it at runtime. I've set up some infrastructure so that it should be straightforward to diagnose this, but I haven't actually implemented the diagnostic yet. - It's not clear to me that swift_checkMetadataState is really cheap enough that it doesn't make sense to use a cache for type-fulfilled metadata in associated type access functions. Fortunately this is not ABI-affecting, so we can evaluate it anytime. - Type layout really seems like a lot of code now that we sometimes need to call swift_checkMetadataState for generic arguments. Maybe we can have the runtime do this by marking low bits or something, so that a TypeLayoutRef is actually either (1) a TypeLayout, (2) a known layout-complete metadata, or (3) a metadata of unknown state. We could do that later with a flag, but we'll need to at least future-proof by allowing the runtime functions to return a MetadataDependency.
rjmccall
force-pushed
the
incomplete-type-metadata
branch
from
05a4570 to
a906f43
Compare
|
@swift-ci Please test. |
1 similar comment
|
@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.
I'll just copy the summary out of the commit message for the last patch in the sequence:
The design is laid out pretty clearly (I hope) in the comments on DynamicMetadataRequest and MetadataResponse, so I'm not going to belabor it again here. Instead, I'll list out the work that's still
outstanding:
I'm sure there are places we're asking for complete metadata where we could be asking for something weaker.
I need to actually test the runtime behavior to verify that it's breaking the cycles it's supposed to, instead of just not regressing anything else.
I need to add something to the runtime to actually force all the generic arguments of a generic type to be complete before reporting completion. I think we can get away with this for now because all existing types construct themselves completely on the first request, but there might be a race condition there if another asks for the type argument, gets an abstract metadata, and constructs a type with it without ever needing it to be completed.
Non-generic resilient types need to be switched over to an IRGen pattern that supports initialization suspension.
We should probably space out the MetadataStates so that there's some space between Abstract and Complete.
The runtime just calmly sits there, never making progress and permanently blocking any waiting threads, if you actually form an unresolvable metadata dependency cycle. It is possible to set up such a thing in a way that Sema can't diagnose, and we should detect it at runtime. I've set up some infrastructure so that it should be straightforward to diagnose this, but I haven't actually implemented the diagnostic yet.
It's not clear to me that swift_checkMetadataState is really cheap enough that it doesn't make sense to use a cache for type-fulfilled metadata in associated type access functions. Fortunately this is not ABI-affecting, so we can evaluate it anytime.
Type layout really seems like a lot of code now that we sometimes need to call swift_checkMetadataState for generic arguments. Maybe we can have the runtime do this by marking low bits or something, so that a TypeLayoutRef is actually either (1) a TypeLayout, (2) a known layout-complete metadata, or (3) a metadata of unknown state. We could do that later with a flag, but we'll need to at least future-proof by allowing the runtime functions to return a MetadataDependency.