Implmenting a YAML generator from the emitted bitcode summary of declarations. Emits one YAML file per declaration information.
For a more detailed overview of the tool, see the design document on the mailing list: RFC: clang-doc proposal
Paths
| Differential D43667
[clang-doc] Implement a YAML generator ClosedPublic Authored by juliehockett on Feb 22 2018, 6:20 PM.
Details
Summary Implmenting a YAML generator from the emitted bitcode summary of declarations. Emits one YAML file per declaration information. For a more detailed overview of the tool, see the design document on the mailing list: RFC: clang-doc proposal
Diff Detail Event Timelinejuliehockett added a parent revision: D43341: [clang-doc] Implement reducer portion of the frontend framework.Feb 22 2018, 6:20 PM Comment Actions Please run Clang-format and Clang-tidy modernize over new code.
Comment Actions I may be mistaken, but Clang source code didn't use llvm namespace by default. Insetad you should include clang/Basic/LLVM.h and use llvm:: for rest of things.
Comment Actions Updating to for adjustments to the internal representation & cleaning up duplication. Comment Actions I'm a bit late on this, but I'd say that YAML is usually not a 'final' format. What would be the use-cases for this? And if is meant as an alternative intermediate format, why not instead of having one big file, have one file per input file? Just wondering what the particular motivation for that could be (Don't mind the previous and inline comment, it was old and I never got to submit it. Differential doesn't let me remove it unfortunately) Comment Actions
The idea is that it's a generally-consumable output format, and so could be interpreted by external software fairly trivially. The bitsream format is compact and good for things that will live entirely in the clang-doc tool, but is harder to deal with outside that scope. YAML bridges that gap. I haven't thought too much about splitting it up, but it might make sense, given that the one file could get very large. By file might work--let me play with it a bit to see what makes the most sense. Comment Actions
That's what I expected :). The primary advantage of one file per output to us was granularity. That allows you to do incremental builds and distribute them at this stage (locally over multiple cores, but also remotely if need be).
juliehockett marked 11 inline comments as done. Comment ActionsUpdating for better integration with MR framework, the generator now takes in an info and an output stream and emits the YAML to that stream. Each info is emitted to its own YAML file.
This revision is now accepted and ready to land.Jun 5 2018, 1:10 AM
Revision Contents
Diff 149997 clang-doc/CMakeLists.txt
clang-doc/Generators.h
clang-doc/Generators.cpp
clang-doc/Representation.h
clang-doc/YAMLGenerator.cpp
clang-doc/tool/ClangDocMain.cpp
test/clang-doc/yaml-comments.cpp
test/clang-doc/yaml-namespace.cpp
test/clang-doc/yaml-record.cpp
|
nit: This seems a bit redundant as the virtual method has been set to 0.