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.


cfe-commits mailing list

Reply via email to