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

[Duncan P. N. Exon Smith via llvm-commits]

> On 2015-Sep-08, at 07:59, Rafael Espíndola via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
>> What about when LLVM 4.0 will be here? What if some 4.0 bitcode is fed
>> through LLVM 3.8?
> 
> It should not crash.

Sure, we should fix crashes.  This is more about quality of error
messages for end users.

>> Even if we don’t crash on the Bitcode *format*, which shouldn’t really
>> happen, what about the optimizer generating intrinsics that are not
>> supported by the backend?
> 
> Still, it should not crash. It should error saying it got an unknown intrinsic.

But whether there's an unknown intrinsic, some new record type, or
a record with a different number of fields isn't helpful to our
end users.

>> I am confident we can get there by fuzz testing.
>> 
>> Good idea!
>> 
> 
> 
>> With what we have in trunk we should be able to implement errors like:
>> 
>> Error: unknown linkage number XX. Input is likely from a newer llvm version.
>> 
>> Would that be sufficient?
>> 
>> 
>> Possibly, can you point me to the mechanism involved here?
> 
> Right now we have
> 
> static GlobalValue::LinkageTypes getDecodedLinkage(unsigned Val) {
>  switch (Val) {
>  default: // Map unknown/new linkages to external
>  case 0:
> 
> Which is IMHO a really bad idea. It should look something like the
> attached patch (which is missing the error propagation). With it
> llvm-dis on the attached testcase prints
> 
> ./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.