Refactor SerializerBase and SymbolGraphSerializer to use a visitor pattern described by the CRTP.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Great start but there are still some rough edges to polish!
clang/include/clang/ExtractAPI/Serialization/SerializerBase.h | ||
---|---|---|
19 | This shouldn't be needed at this point. | |
28–31 | This is very specific to SymbolGraphSerializer or at last to JSON. | |
37 | This shouldn't be needed anymore. | |
84 | This should visit some sort Protocol Records specifically. Likewise for interfaces. | |
100 | This should have a default implementation. | |
138–139 | I think that APIIgnoresList Should be pushed down into the SymbolGraphSerializer. | |
142–143 | Don't need a virtual destructor anymore. | |
clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h | ||
12 | ||
94 | I think these should still be called serializeXXX as they aren't part of the visitation interface and are very specific to the symbol graph format. | |
129–130 | I think we shouldn't need to have this method. APISetVisitor should handle calling the relevant visitMethods for the members. | |
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp | ||
221 | I think all these helper methods for serializing specific chunks of symbol graphs should still be names serialize |
clang/include/clang/ExtractAPI/Serialization/SerializerBase.h | ||
---|---|---|
28–31 | If there aren't any base visitor options, I'll just move this to SymbolGraphSerializer without any inheritance. | |
84 | Not sure I understand, these functions essentially replace the loops in the old SymbolGraphSerializer::serialize loops, which are now grouped as function calls in APISetVisitor::traverseAPISet. Should I add functions that take Protocols, Interfaces as parameters to visit them specifically? | |
clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h | ||
129–130 | I've been considering how to move it to APISetVisitor. Its current implementation doesn't seem like it would fit well with a generic base implementation. It would be overridden to call visitRelationship which relies on a RelationshipKind parameter. Since that's SymbolKit specific, I don't think we'd raise that to the base class. If there was a base relationship struct that RelationshipKind inherited from, it might solve that. |
This shouldn't be needed at this point.