When adding an Objective-C retainable type member to a C++ class, also check the LangOpts.ObjCWeak flag and the lifetime qualifier so __weak qualified Objective-C pointer members cause the class to be a non-POD type with non-trivial special members, so the compiler always emits the necessary runtime calls for copying, moving, and destroying the weak member. Otherwise, Objective-C++ classes with weak Objective-C pointer members compiled with -fobjc-weak exhibit undefined behavior if the C++ class is classified as a POD type.
Details
- Reviewers
rjmccall benlangmuir rsmith doug.gregor - Commits
- rG036603ac59d7: [Objective-C] C++ Classes with __weak Members non-POD Types when using -fobjc…
rC299008: [Objective-C] C++ Classes with __weak Members non-POD Types when using -fobjc…
rL299008: [Objective-C] C++ Classes with __weak Members non-POD Types when using -fobjc…
Diff Detail
Event Timeline
lib/AST/DeclCXX.cpp | ||
---|---|---|
726 | Similarly, I think the best way of expressing this is to re-arrange the blocks like so: if (T.hasNonTrivialObjCLifetime()) { // Objective-C Automatic Reference Counting: // If a class has a non-static data member of Objective-C pointer // type (or array thereof), it is a non-POD type and its // default constructor (if any), copy constructor, move constructor, // copy assignment operator, move assignment operator, and destructor are // non-trivial. setHasObjectMember(true); struct DefinitionData &Data = data(); Data.PlainOldData = false; Data.HasTrivialSpecialMembers = 0; Data.HasIrrelevantDestructor = false; } else if (!Context.getLangOpts().ObjCAutoRefCount) { setHasObjectMember(true); } | |
lib/Sema/SemaDeclCXX.cpp | ||
4407 | I think this entire check can just be: if (FieldBaseElementType.hasNonTrivialObjCLifetime()) The language-options checks are almost certainly slower than just checking the qualifiers. |
lib/Sema/SemaDeclCXX.cpp | ||
---|---|---|
4407 | I see. handleObjCOwnershipTypeAttr() in SemaType.cpp only adds OCL_Weak or OCL_ExplicitNone outside of ARC and it's a compile error to use __weak without -fobjc-arc or -fobjc-weak, so hasNonTrivialObjCLifetime() is indeed much more simple. Thanks! |
Thank you @rjmccall for the approval. I don't have commit access; would someone be willing to commit this path for me please? Thanks!
You have a lot of patches here. :) I would encourage you to just ask for commit access; it's not a strenuous process. http://llvm.org/docs/DeveloperPolicy.html
John.
Similarly, I think the best way of expressing this is to re-arrange the blocks like so: