-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[IRGen] Generate proper type descriptors for ObjC subscript accessors #20559
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
@swift-ci Please test |
@swift-ci Please test source compatibility |
@@ -437,7 +437,8 @@ class ObjCProtocolInitializerVisitor | |||
Builder.CreateCall(protocol_addMethodDescription, getterArgs); | |||
|
|||
if (prop->isSettable(nullptr)) { | |||
emitObjCSetterDescriptorParts(IGM, prop, name, types, imp); | |||
emitObjCSetterDescriptorParts(IGM, prop, /*extended*/true, | |||
name, types, imp); |
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.
Is there rhyme or reason for why some of these use extended encodings and others don't?
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.
Protocols do, non-protocols don't. I don't know the story further than that, though; I just imitated what was already there. (That's why I tagged Greg for review, really.)
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.
Ah, I guess that makes as much sense as anything. Could you make the fact that that's the reason behind the decision more explicit in the source?
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.
Okay, I don't think this is correct after all. There's already a separate path for getting extended type encodings for protocols. @gparker42, how is this supposed to work?
These are only used in two places in the Apple Objective-C runtime: - A protocol's "extended method types" list - Block type descriptors We were using them when dynamically registering a protocol with the Objective-C runtime, but that's just expecting "normal" types; the "extended method types" list is never present in such a protocol.
@swift-ci Please test source compatibility |
Build failed |
*sigh* ObjCBool… |
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 seems reasonable to me. What's going on with ObjCBool
?
Oh, just that the test case I modified was already limited to |
We visited them twice, which led to registering them twice. Add a test for this feature so that we don't regress on this or on the use of non-extended types in the future (see previous commits).
@swift-ci Please test |
Build failed |
Build failed |
[IRGen] Generate proper type descriptors for ObjC subscript accessors https://bugs.swift.org/browse/SR-8356 (cherry picked from commit b060166)
[IRGen] Generate proper type descriptors for ObjC subscript accessors https://bugs.swift.org/browse/SR-8356 (cherry picked from commit b060166)
SR-8356 / rdar://problem/42284266