[llvm] r200721 - DIBuilder: simplify array generation to produce true zero-length arrays

[Eric Christopher]

On Mon, Feb 10, 2014 at 5:43 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
> On Feb 10, 2014, at 16:59, Eric Christopher <echristo at gmail.com> wrote:
>
>> On Mon, Feb 10, 2014 at 4:42 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>>
>>> On Feb 10, 2014, at 16:14, David Blaikie <dblaikie at gmail.com> wrote:
>>>
>>>> +Bob & Adrian who particularly care about this
>>>>
>>>> I think the general consensus was to just bump the version number for each LLVM release (or private release - when any developer has one for which they need this).
>>>>
>>>> So I think we essentially want to flag the tree as "we've broken compatibility" and whoever hits a release first (internal or LLVM official) should bump the version at that point and then the tree is "unbroken". Rather than bumping it for every change.
>>>>
>>> If we do this we need to document the official procedure somewhere. We would need to have a Debug info canary somewhere as the flag that current trunk is incompatible to any previously released version although the version number is the same and then anyone who cares may reset the flag and bump the version number (at any time?).
>>>
>>
>> ... I suppose we could. But largely it's a documentation and not a code issue.
>>
>>> We really need to make sure that it will not be easy to accidentally release two incompatible incarnations of LLVM with the same Debug info version number.
>>>
>>
>> We can probably just assume it needs to bump every time we cut a
>> release branch :p
>>
>> That said we don't want to update all of the testcases all the time.
>> It's just a somewhat annoying churn.
>>
>>>> We don't want to do this more often than necessary because it involves updating /all/ the debug info test cases.
>>>>
>>>
>>> We should also provide a script that recursively greps for
>>>  ![[0-9]]+ = metadata !{i32 2, metadata !"Dwarf Version", i32 [[0-9]]+}
>>> and bump the version. I guess it could also reset the canary.
>>>
>>>
>>> Now that I think about it, I believe it would be better to provide only this script and run it every time someone breaks compatibility. Why? Suppose we have two changes on trunk that break compatibility: Change 1 sets the flag. Change 2 later doesn't, because it's already there, and there was no release in the meantime. When someone needs to cherry-pick only Change 2 into a release branch, because it fixes an important bug, there is no way to tell whether that branch should bump the version number or not. (Obviously version numbers are only meaningful within the same "family" of releases.)
>>>
>>
>> I disagree here. If you're cherry-picking then you'd better know what
>> the change does - including breaking compatibility and can update the
>> default value yourself.
>
> I agree with the "you better know what you're doing"-part, but if I want to make both a release with Change1 and later one with Change1+Change2, I'm running out of consecutive version numbers.
>
> This implies that in a private namespace one would have to multiply the version number by some constant, so there are some holes left to fill in the version history. I guess in practice people will just use the release version number instead..
>

Right, and we explicitly discarded increasing the version number for
every breaking change when we talked about this originally :)

-eric