[LLVMbugs] [Bug 8653] New: ObjC++ synthesized property setter uses GetCopyStructFn

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=8653

           Summary: ObjC++ synthesized property setter uses
                    GetCopyStructFn
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jbenet at cs.stanford.edu
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Hello Everyone, 

Please excuse any breaches of protocol, this is my first time posting here.

If you look at CodeGen/CGObjC.cpp
(http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjC.cpp?view=markup
for quickness), within CodeGenFunction::GenerateObjCSetter, the second branch
of the if ends with:

EmitCall(Types.getFunctionInfo(getContext().VoidTy, Args,
FunctionType::ExtInfo()),
             GetCopyStructFn, ReturnValueSlot(), Args);

I believe this is incorrect. In the C world, memcpying the struct is perfectly
fine. But in ObjectiveC++, this means that no constructor gets called. This is
very damaging to any code that requires per-instance execution in the
constructor. Allow me to give you a very concrete example:

Consider the case of smart pointers. Constructors and assignment operator call
refIncrement, and destructor calls refDecrement. There is a big problem using
synthesized setter thus:

someNSObject.aSmartPtr = somePtr;

Neither the copy constructor or the assignment operator will be called on the
Ivar, and only the memory will be copied over. This causes one refIncrement to
be missed, making the count one less than it ought to be. 

Yuji's answer to this stack overflow question
http://stackoverflow.com/questions/3642979, has a simple implementation of this
behavior in action.

I asked about this in the IRC channel earlier and was advised to submit a bug
report, so here it is.

I tried to find a viable solution, and offhand (knowing almost nothing of
Clang's architecture) i would say that a call to getSetterCXXAssignment() (like
the third branch of the if statement) is in order.

In fact, a workaround is to force the execution of the third branch (by
declaring the property nonatomic, failing the first condition of the 2nd if),
however this is not a good solution, because library code (as smart pointers
are) will not be widely used if it has such a strong constraint.

Anyway, I hope that this can be resolved soon. It shouldn't take a lot of time,
and I'd be willing to contribute. 

Thanks for building great software!
Cheers!

Juan

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.