-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[IRGen] Do not emit ObjC property ivar field when getters and setters are non-trivial. #21976
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
@jrose-apple Hi Jordan, would you take a look at this, please? |
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.
Thanks for picking this up!
lib/IRGen/GenClass.cpp
Outdated
propTy->isTriviallyRepresentableIn(objcLang, propDC); | ||
bool isStaticBridged = | ||
ForeignRepresentableKind::StaticBridged == | ||
propTy->getForeignRepresentableIn(objcLang, propDC).first; |
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 don't think static bridging counts. It looks like we use that for the closure <-> block bridge, and that's still going to be stored as a closure in memory.
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.
Done!
…entable types. This patch prevents writing ivar field for ObjC property whose type is not trivially representable in ObjC within its DeclContext. For example, in the case of the property `@objc var foo: String`, it is accessed as an NSString on the ObjC side. Without this patch, this property is backed with an ivar, to which direct accesses would fail. Resolves: SR-9557.
Thank you for the feedback, Jordan! I had the code updated. Would you help fire a test, please? |
@swift-ci Please test |
Build failed |
Build failed |
This patch prevents writing ivar field for ObjC property whose type is not trivially representable in ObjC within its DeclContext, as spotted by Jordan Rose when reviewing SR-9541.
For example, in the case of the property
@objc var foo: String
, it is accessed as anNSString
on the ObjC side. Without this patch, this property is backed with an ivar, to which direct accesses would fail.Resolves SR-9557.
Something I am not confident is how to handle theStaticBridged
properties (e.g., this one). Being conservative, this patch still emits ivar names in this case.