[IRGen] Fix issues impacting the mangled name <-> roundtrip verification #19958
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
…ata. The instantiation of an Objective-C class or definition of an Objective-C category can depend (at runtime) on Swift metadata, which is triggered (only) by mangled name round-trip verification. Teach the JIT to call the registration functions for Objective-C classes and categories after we’ve called all of the metadata registration functions.
…ype reference. The root generic parameter of an associated type reference in a generic requirement is not shifted by one.
|
@swift-ci please test |
DougGregor
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.
Introduce two small fixes that address problems discovered by mangle name <-> metadata roundtrip verification in the runtime:
IRGen for the JIT: register Objective-C classes/categories after other type metadata, because the registration might need to lookup type metadata
IRGen for generic requirements: we were improperly encoding the root generic parameter for associated type requirements, meaning any requirement based on generic parameter with a flat index greater than 0 would be incorrectly interpreted. I suspect we have conditional-conformances failures due to this.