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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
