[PATCH] D12618: Reserve a vendor reserved block ID for bitcode

[Rafael Espíndola via llvm-commits]

>> ./bin/llvm-dis: error: unknown linkage number 20. Input is likely from
>> a newer llvm version.
>
> This error is useful to compiler engineers, but probably not to our
> customers.
>
> We want to be able to say something along the lines of:
> --
> error: cannot read bitcode generated from newer clang (800.0.64)
> --
> where 800.0.64 is a hypothetical future Apple clang version that's
> embedded somehow (but predictably) in the bitcode it produces.

So, printing the producer version does require it being written
somewhere in the bitcode. It then comes down to the cost/benefit of
it.

In previous discussions about having a version number, I think the
main objections were

* Using the bitcode wrapper instead of the bitcode proper (doesn't
apply to this patch).
* The use of the version number for backwards compatibility checking.
The previous patches would add a version that would be known and
handled by the open source tools, it would then be just too easy to
start using it for compatibility instead of the current practice of
making the local structure self sufficient.

The second concern also doesn't apply directly to this patch, as long
as we make sure trunk always ignores VENDOR_RESERVED_ID.

In summary. I am OK with this, but please
* Make sure including the future version number in the error is really worth it.
* Put a comment saying VENDOR_RESERVED_ID should always be ignored in
the open source project.
* Get at least one extra LGTM (Nick, Chandler?)

Another think, should we have a vendor ID enum and define the format
of VENDOR_RESERVED_ID to always start with the vendor ID? That would
avoid, for example, apple tools trying to read unrelated scea data as
a clang version.

Cheers,
Rafael