[PATCH] D66121: Debug Info: Nest Objective-C property function decls inside their container.

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Sep 17 17:51:08 PDT 2019


rjmccall added a comment.

In D66121#1673233 <https://reviews.llvm.org/D66121#1673233>, @aprantl wrote:

> I'm afraid I'm going to give up on fixing the AST and return to my debuginfo-only patch.
>
> While I was correct in figuring out that ObjCMethodDecl implementations are not linked up as redeclarations of ObjCMethodDecl decls in the interface, that wasn't the whole story: `ObjCMethodDecl::getNextRedeclarationImpl()` links them up *implicitly* by finding the implementation for a decl and vice versa by looking up the selector in the interface/implementation (See https://github.com/llvm/llvm-project/blob/244e738485445fa4b72bfef9b9b2f9625cee989e/clang/lib/AST/DeclObjC.cpp#L905).
>
> I can make this mechanism work by adding the method to the ObjCImplementationDecl, so it gets found by getNextRedeclarationImpl(). But if I do that, CodeGen falls over completely, because the new property accessor redeclarations don't actually have any function bodies. CodeGen in several places special-cases property accessors to generate them on-the-fly. I think this may work neatly if we actually created an AST for the function body in SemaObjCProperty too, and remove the functionality from CodeGen, but that is beyond what I'm prepared to do.


Can you just check for a method that doesn't have a body and use that as the trigger for emitting the synthetic getter/setter body, and get rid of the old IRGen code that looks for property implementations and emits them?


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

https://reviews.llvm.org/D66121





More information about the cfe-commits mailing list