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