[PATCH] D122446: [clang][extract-api] Add Objective-C interface support

[Zixu Wang via Phabricator via cfe-commits]

zixuw marked an inline comment as done.
zixuw added inline comments.


================
Comment at: clang/lib/ExtractAPI/DeclarationFragments.cpp:642-648
+// Instantiate template for FunctionDecl.
+template FunctionSignature
+DeclarationFragmentsBuilder::getFunctionSignature(const FunctionDecl *);
+
+// Instantiate template for ObjCMethodDecl.
+template FunctionSignature
+DeclarationFragmentsBuilder::getFunctionSignature(const ObjCMethodDecl *);
----------------
dang wrote:
> Do we need to explicitly instantiate them? Wouldn't they get instantiated as needed?
Yeah since we are implementing the templated method here instead of in the header file, we need to explicitly instantiate it so that the symbol ends up in `DeclarationFragments.o` and picked up by the linker.


================
Comment at: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp:375
+  case APIRecord::RK_ObjCIvar:
+    Kind["identifier"] = AddLangPrefix("ivar");
+    Kind["displayName"] = "Instance Variable";
----------------
dang wrote:
> zixuw wrote:
> > dang wrote:
> > > this should probably be more explicit to keep in line with how things are currently done. Maybe something like "instance.variable"
> > Right, naming completely new things here so worth the discussion.
> > To keep in line with the current convention, I don't see instance methods having an `instance.` prefix. It's just `method` as opposed to `type.method`.
> > Also global variable is just `var`, if we really need to add the `instance.` prefix (which I still don't think makes much sense for the above reason), wouldn't it be `instance.var`?
> Actually, now that I think about it, we should just make them properties. There is already a precedent of doing that for struct fields, and ivars are pretty much the equivalent of a struct field for an interface.
For my understanding, struct fields got named "property" because they behave similar as properties, and there are no other possible member kinds in a struct to overload that concept. While in an Objective-C container, there are actual literal Objective-C "properties." How do we distinguish between ivars and properties if they're the same kind?

We might also reconsider the kind for struct fields as "instance property" isn't really accurate and largely Objective-C-ish.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122446