To achieve this we hook into the preprocessor during the
ExtractAPIAction and record definitions for macros that don't get
undefined during preprocessing.
Details
- Reviewers
zixuw ributzka QuietMisdreavus
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Still going through the declaration fragments builder and ExtractAPIVisitor/Consumer/Action changes, but it seems that the patch needs a rebase onto the latest main right now as it's missing several already landed changes.
clang/include/clang/ExtractAPI/API.h | ||
---|---|---|
127 | Now that we are re-ordering it, would it look more organized if we push GVKind Kind further down so that the two StringRefs could be adjacent, and we also keep a common list of arguments (Name, USR, Loc, Availability, ..., SubHeading) the same across all kinds of records upfront? So maybe push to the end after SubHeading and before Signature. | |
127 | Also it seems that it becomes a requirement for the *Record c'tors that Name should be the first parameter in order to use the addTopLevelRecord template, though that's hidden in an anonymous namespace in the implementation file. | |
385 | Don't we also need sub-headings for macros? | |
391 | Need out-of-line virtual anchor as this struct inherits a virtual table. |
clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h | ||
---|---|---|
22 | Why do we need this include? | |
clang/lib/ExtractAPI/API.cpp | ||
31 | Does it make sense to just directly make the *RecordMap types in APISet as a template using? | |
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp | ||
634–645 | Worth moving this change and the APISet move and relevant structural changes into its own patch, as mentioned in D122446. | |
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp | ||
17 | Why do we need this include? |
clang/include/clang/ExtractAPI/API.h | ||
---|---|---|
127 | Good catch! Correct, it isn't really a requirement in the sense that we could pass it in twice but since this was the only place that needed the change I felt it would improve the ergonomics of addTopLevelRecord to make the change here. The way I see it it depends on whether we want to make use of addTopLevelRecord to associate stuff in the relevant map using a key that isn't the name of the record. If we don't want to do that, it might make sense to make the maps sets, which would convey the intent a bit better IMHO, but that would be a follow up patch. Alternatively if we want to keep the structure as is, the easiest thing to do is to put a comment on top of the APIRecord base class that says that derived classes need to put the Name parameter as the first thing. | |
clang/lib/ExtractAPI/API.cpp | ||
31 | Yup agreed! |
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp | ||
---|---|---|
634–645 |
This change is causing 9 test failures on a buildbot, can you please take a look and revert if you need time to investigate?
Looks like either this or your other commit at the same time broke tests on windows: http://45.33.8.238/win/55345/step_7.txt
Please take a look, and revert for now if it takes a while to fix.
(Also, please add a "Differential Revision: https://reviews.llvm.org/D122611" line to the bottom of your commit, to make it easy to find the review from the commit message.)
I have what should be a NFC fix that should fix the issue, just checking everything still works and will commit it.
Committed a revert of the changes in that particular function in commit 985eaa1a3da2a1b88ea70a65ffd5783aa82ea65e
@thakis I am UK based so I am logging off as it's 9pm over here. The fix I committed has fixed the issue on other buildbots that were failing due to this. If it still fails on Windows, would you be able to revert the change for me?
Now that we are re-ordering it, would it look more organized if we push GVKind Kind further down so that the two StringRefs could be adjacent, and we also keep a common list of arguments (Name, USR, Loc, Availability, ..., SubHeading) the same across all kinds of records upfront? So maybe push to the end after SubHeading and before Signature.