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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
