[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