Skip to content

[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

Merged
merged 1 commit into from
Jan 19, 2019

Conversation

dingobye
Copy link
Contributor

@dingobye dingobye commented Jan 18, 2019

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 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.

Something I am not confident is how to handle the StaticBridged properties (e.g., this one). Being conservative, this patch still emits ivar names in this case.

@dingobye
Copy link
Contributor Author

@jrose-apple Hi Jordan, would you take a look at this, please?

Copy link
Contributor

@jrose-apple jrose-apple left a 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!

propTy->isTriviallyRepresentableIn(objcLang, propDC);
bool isStaticBridged =
ForeignRepresentableKind::StaticBridged ==
propTy->getForeignRepresentableIn(objcLang, propDC).first;
Copy link
Contributor

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.

Copy link
Contributor Author

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.
@dingobye
Copy link
Contributor Author

Thank you for the feedback, Jordan! I had the code updated. Would you help fire a test, please?

@jrose-apple
Copy link
Contributor

@swift-ci Please test

@jrose-apple jrose-apple self-assigned this Jan 18, 2019
@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 6e862025cea03afb9cdfa232fdc18ae749b56eb0

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 6e862025cea03afb9cdfa232fdc18ae749b56eb0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants