[PATCH] D41102: Setup clang-doc frontend framework

Julie Hockett via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Feb 20 16:33:00 PST 2018


juliehockett added a comment.

In https://reviews.llvm.org/D41102#1011299, @lebedev.ri wrote:

> I don't know the protocol, but i think it might be a good idea
>  to add a new entry to `CODE_OWNERS.TXT` for `clang-doc`?
>
> `clang-doc` going to be quite distinctive, and bigger/complicated
>  than what already is in `clang-tools-extra`.


Does anyone know what the protocol on this would be?



================
Comment at: clang-doc/ClangDocBinary.cpp:88
+  Stream.Emit((unsigned)'C', 8);
+  Stream.Emit((unsigned)'S', 8);
+}
----------------
lebedev.ri wrote:
> juliehockett wrote:
> > lebedev.ri wrote:
> > > General comment: shouldn't the bitcode be versioned?
> > Possibly? My understanding of the versioning (which could be incorrect) was that it was for the LLVM IR and how it is written in the given file -- I'm not writing to LLVM IR here, just using it as a data storage format, and so didn't think it was necessary. Happy to add it in though, but which version number should I use?
> The question i'm asking is: what will happen if two different (documenting different attributes, with non-identical `enum {something}Id`, etc) clang-doc's were used to generate two different parts of the docs (two different TU's)?
> When merging two parts, if the older clang-doc is used, will it only accept the part if bc it understands? Or fail altogether?
> And, does it make sense to allow to generate such mixed-up documentation?
> 
After some thought, I think it will depend on how the bitcode changes in the future. The reader can be implemented to simply ignore anything it doesn't recognize (with a default switch case), so that route is possible, but if the representation shifts in a major way it should probably just bail if the version is too early. 

I think this a good question to consider in implementing the reader and reducer portions of the tool -- for now, I've added the version number to the writer, so it can be checked in that part.


https://reviews.llvm.org/D41102





More information about the cfe-commits mailing list