Add support for Objective-C interface declarations in ExtractAPI.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/ExtractAPI/DeclarationFragments.cpp | ||
---|---|---|
624–662 | If I am not mistaken, these do the same thing but need separate overloads because the types don't share a common super class. If this is true we should still remove the duplication here. There are two ways of doing this AFAIK:
| |
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp | ||
245 | Shouldn't we be recording this string in the StringAllocator for reuse later. I have a patch in progress for macro support that will do the serialization once the AST isn't available anymore so we really shouldn't be taking in StringRefs for stuff in the AST. | |
455 | I think we need to allocate these string in the StringAllocator. |
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp | ||
---|---|---|
375 | this should probably be more explicit to keep in line with how things are currently done. Maybe something like "instance.variable" |
- Address review comments:
- Use template to reuse logic for building function signatures for FunctionDecl and ObjCMethodDecl.
- Move the change of objc_interface.m test in this patch from D122511.
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp | ||
---|---|---|
245 | Right but that only makes sense once we kill the AST before serialization right? I mean I'm happy to wrap these in copyString now if we know for sure that we're doing that in a later patch. But it feels beyond the scope of this particular patch. Especially that we'd also need to go through the previous code to copy the names of global records, enums, etc. anyway. I feel like that the change to surface APISet and punt serialization should be separated out from the macro change. And we can wrap all the name strings in that patch so that it's a meaningful atomic commit. | |
455 | Same as above. | |
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp | ||
375 | Right, naming completely new things here so worth the discussion. |
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp | ||
---|---|---|
245 | Yeah sounds good! | |
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp | ||
375 | 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. |
clang/lib/ExtractAPI/DeclarationFragments.cpp | ||
---|---|---|
645–651 | Do we need to explicitly instantiate them? Wouldn't they get instantiated as needed? | |
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp | ||
245 | I have looked into it a bit more and the ASTContext will still be live at that point (it gets deallocated right after we will be doing the serialization) so this is fine. |
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp | ||
---|---|---|
245 | I thought it would still make sense to split the macro patch in two so here we go: https://reviews.llvm.org/D122648 |
clang/lib/ExtractAPI/DeclarationFragments.cpp | ||
---|---|---|
672 | We shouldn't be appending the +/- here. We can discuss this more offline |
clang/lib/ExtractAPI/DeclarationFragments.cpp | ||
---|---|---|
645–651 | 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. | |
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp | ||
375 | 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. |
Do we need to explicitly instantiate them? Wouldn't they get instantiated as needed?