- The name SymbolGraph is inappropriate and confusing for the new library for clang-extract-api. Refactor and rename things to make it clear that ExtractAPI is the core functionality and SymbolGraph is one serializer for the API information.
- Add documentation comments to ExtractAPI classes and methods to improve readability and clearness of the ExtractAPI work.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/include/clang/ExtractAPI/API.h | ||
---|---|---|
36 | You should use the actual name of the type or "This" | |
39 | If it wouldn't make things simpler we wouldn't have it. IMHO it is better to use definitive terms in documentation. here it would "This simplifies calculating [...]" | |
105 | Nit: instead of "of a" maybe use "associated with" | |
125 | This is new so I don't think it belongs in this patch. | |
131 | why is stuff reordered in the patch? | |
clang/include/clang/ExtractAPI/DeclarationFragments.h | ||
114 | Not sure an explanation of the process is needed. Anyway "quicking" is not a word ;) I would suggest "Other is moved from and can not be used after a call to this method". | |
clang/include/clang/ExtractAPI/Serialization/SerializerBase.h | ||
34 | If we are going for a base class, I am not sure that the base should be JSON specific. | |
clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h | ||
35 | Not sure why we need this. | |
clang/lib/ExtractAPI/API.cpp | ||
34 | "Create the record if it does not already exist." | |
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp | ||
195 | The kind of serializer should be made configurable somehow. | |
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp | ||
26 | This is unnecessary imho. |
Would you mind putting a high level description of the intent at the top of the main header.
Maybe even a link at https://github.com/apple/swift-docc-symbolkit
Address review issues.
clang/include/clang/ExtractAPI/API.h | ||
---|---|---|
125 | This is to follow the LLVM Coding Standards guideline of providing an out-of-line virtual method anchor for a class defined in a header file and has a vtable. Still coding style/standard fix/improvement. | |
131 | I looked into some other class definitions inside Clang, and was trying to list "interesting" APIs upfront and less-interesting stuff like constructors near the end for large class definitions to make them more readable. | |
clang/include/clang/ExtractAPI/DeclarationFragments.h | ||
114 | Whops didn't realize that I typed that. Friday's work huh? :p | |
clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h | ||
35 | As above. Refactor to follow LLVM Coding Standards. | |
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp | ||
195 | Yes for sure. I didn't include that change here because it would probably involve adding command line options and changing the driver, which should have its own patch later. |
LGTM once the last few bits of feedback I left are considered.
clang/include/clang/ExtractAPI/API.h | ||
---|---|---|
131 | OK that is a nice change then, I wasn't aware that this is a thing. I was just complaining because it made the diff harder to parse for me ;) | |
139 | Maybe we should document that the caller is meant to keep Name and USR alive. Name is expected to refer to the appropriate Decl member so it shouldn't be an issue, but this usage should be documented. WRT USR these comments would be a good place to mention the existence of recordUSR and the copyString method as a way of getting USR strings that are guaranteed to have the right lifetime. | |
194 | Should this be a private member function? The overload that doesn't take in an allocator makes sense since it uses the APISet's allocator, but this one does not seem like it should be publicly accessible, since it just ties the lifetime of the returned String to that of an arbitrary allocator? | |
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp | ||
195 | Yeah that makes sense, we can do this as a follow up patch, definitely not urgent as SymbolGraph is the only use case at the moment. However, we should do this relatively soon so that the structure of the existing command line arguments is stable before we are fully done with this. | |
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp | ||
30 | You don't need both static an anonymous namespace afaik. |
Address review issues:
- Documenting the responsibility of keeping StringRefs alive for APISet
- Remove unnecessary static for helper functions in an anonymous namespace
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp | ||
---|---|---|
159 | Hi! Thanks for the report! Do you have a link to the failed build or detailed error output and compile configuration? |
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp | ||
---|---|---|
159 | Renamed the variable in 826e661a96a2aa7eb309dbca16c85a3d05edcec8 |
You should use the actual name of the type or "This"