[llvm-dev] LLVMBuildLandingPad is wrong on 3.7

[Mehdi Amini via llvm-dev]

> On Sep 10, 2015, at 3:20 PM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> +Tom
> 
> Sorry, I should have noticed that the C API changed.

I don’t if there is a list of things to look for before a release, but that might be an idea to add: diff the include/llvm-c public headers with the last release to see what changed here.

— 
Mehdi


> 
> 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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev