[llvm-dev] LLVMBuildLandingPad is wrong on 3.7

[Hans Wennborg via llvm-dev]

+Tom

Sorry, I should have noticed that the C API changed.

Looks like the fix is now merged in r247191. However, that means the
API is changing between 3.7.0 and 3.7.1 :-/ I don't know if that's
better or worse though.

On Tue, Sep 8, 2015 at 8:38 AM, Reid Kleckner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> That really sucks. I wasn't aware that we fixed it after the branch point.
> We could merge it and try to rush out a 3.7.1 release, but I think Hans is
> all release-d out for now.
>
> Given that we already broke compatibility in a released version of LLVM, I'd
> be OK removing the compatibility hack and shipping the modified
> LLVMBuildLandingPad. Personalities no longer live on landingpads.
>
> On Sun, Sep 6, 2015 at 2:19 AM, deadal nix via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> Hi all,
>>
>> During the dev in between 3.6 and the release of 3.7, the personality
>> function was moved from the landingpad to the function itself.
>>
>> During theses events, LLVMBuildLandingPad was changed, twice. The first
>> time in a backward incompatible way, the second in a backward compatible
>> way.
>>
>> As things are now, the backward incompatible way is in 3.7 and the
>> backward compatible in master.
>>
>> Meaning master is backward compatible with 3.6 but not 3.7.
>>
>> That is bad. If there is ever a plan for 3.7.1, that'd be great to cherry
>> pick 7c898facbc5c707c77f25f7fd9b512a099af62a8 . Alternatively, master can be
>> made compatible with 3.7 .
>>
>> I'd like to add that having some actual testing for the C API would have
>> prevented the whole confusion in the first place. I have a diff out to start
>> moving in that direction: http://reviews.llvm.org/D10725 . The damn thing is
>> out since June and nothing have moved since then.
>>
>> If core devs are swaped and can't handle this, please delegate. I know
>> there is some discussion about the state of the C API, but the thread is
>> dead for weeks now, reasonable options have been presented, and I'm not sure
>> what is expected to move things here. ALL alternative proposed in the thread
>> pretty much are better than the status quo. I'm not sure what is expected
>> for thing to move forward. It seems that cores devs just aren't using that
>> API, but people actually using it or willing to work on it lack the power to
>> do so.
>>
>> Please make something happen. Sooner rather than later. I'm here to help,
>> but really, if 2.5 month is what is required to get a test in, I'd be
>> probably dead of old age before being able to have any significant impact.
>> Same goes for others C API users.