-
Notifications
You must be signed in to change notification settings - Fork 10.5k
IRGen: lazy initialize ForeignClassMetadata #22857
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
CC: @slavapestov |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs tests.
475dc39
to
a655b1c
Compare
CC: @mikeash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could reasonably have the constructor for ForeignMetadataCacheEntry
set the VWT if it's currently null. We should not try to initialize this in the completion function; I'm pretty sure the runtime assumes that the VWT will be set to something after allocation.
My concern with that would be that not every foreign metadata is a CF class. It feels brittle to me to assume that, if no VWT is set, the one for foreign classes is always the best one to fill in. |
a655b1c
to
b2a8156
Compare
@rjmccall I did try to do that, but, it is currently marked as rdata, and Im trying to track down why that is. @jckarter - hmm, we could use the VWT entry itself for storage to figure out if we should overwrite it. I imagine that no OS that we care about ATM would use anything in the first page, so that gives us a good range to play with. |
Hm, maybe it's fine if we check that the type context descriptor describes a class, and set the VWT during foreign metadata setup if it is. |
40f4b68
to
1a646cc
Compare
@swift-ci please test |
Build failed |
Build failed |
1a646cc
to
1167555
Compare
@swift-ci please test |
Build failed |
Build failed |
1167555
to
6105bfd
Compare
@swift-ci please test |
Build failed |
Build failed |
d536b71
to
8fff736
Compare
8fff736
to
333d269
Compare
@swift-ci please test |
333d269
to
aef7b94
Compare
@swift-ci please test |
Build failed |
aef7b94
to
0c700eb
Compare
@swift-ci please test |
Build failed |
Build failed |
@swift-ci please test |
Build failed |
@swift-ci please test macOS platform |
@rjmccall, @jckarter, @slavapestov - okay, so then this is good to merge? I will try to create a test case for the root protocol conformance, and then come back around to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a bunch of comment requests, but otherwise this LGTM.
This is needed for Windows which does not support cross-module data references without indirection. By lazy initializing the data, we can indirect through the IAT for the data pointer and fill in the parent pointer.
0c700eb
to
3f829c2
Compare
@swift-ci please test and merge |
Build failed |
@swift-ci please test macOS platform |
This is needed for Windows which does not support cross-module data
references without indirection. By lazy initializing the data, we can
indirect through the IAT for the data pointer and fill in the parent
pointer.
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.