[PATCH] D68108: Redeclare Objective-C property accessors inside the ObjCImplDecl in which they are synthesized.

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Nov 5 12:10:59 PST 2019


rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Okay, thanks for patiently working through all this review.  I'm happy with this now.



================
Comment at: clang/lib/CodeGen/CodeGenModule.cpp:5063
                                  const_cast<ObjCImplementationDecl *>(D), PID);
     }
   }
----------------
aprantl wrote:
> rjmccall wrote:
> > aprantl wrote:
> > > rjmccall wrote:
> > > > Is this special treatment still necessary?  Won't we encounter the getter and setter on the normal pass over the method definitions in the `@implementation`?
> > > We don't know which ObjMethodDecls without bodies are property accessor implementations since there is no pointer from the ObjCMethodDecl back to the ObjCPropertyImplDecl.
> > I mean, this doesn't seem like an unreasonable thing to be able to discover given just an `ObjCMethodDecl`.  We can certainly set something on the declaration that says that it represents a synthesized method definition (and is therefore a definition for the purposes of `isDefined` or anything similar).
> If we were to move this into the loop / function that emits each method decl, we would still somehow need to get back to the `ObjCPropertyImplDecl `. There is no pointer in that direction, so we'd have to loop over all property impls until we find it. This here is going to be faster. Storing a pointer to a possible `ObjCPropertyImplDecl` in `ObjCMethodDecl` seems wasteful. Let me know if I misunderstood what you were suggesting.
Oh, in order to find the associated ivar?  I hadn't considered that.  Okay, WFM.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68108/new/

https://reviews.llvm.org/D68108





More information about the cfe-commits mailing list