[llvm] r240010 - Update LLVM bindings after r239940. Apparently these aren't included in

[Reid Kleckner]

I forgot to mention I fixed this in r242372. LLVMBuildLandingPad has the
old API and sets the personality on the parent function.

On Wed, Jul 15, 2015 at 2:16 PM, Juergen Ributzka <juergen at apple.com> wrote:

> Any updates on this? This is currently breaking our use of the C API in
> WebKit.
>
> —Juergen
>
> On Jul 6, 2015, at 4:04 PM, Reid Kleckner <rnk at google.com> wrote:
>
> On Thu, Jun 18, 2015 at 6:42 PM, Eric Christopher <echristo at gmail.com>
> wrote:
>>
>> On Thu, Jun 18, 2015 at 6:35 PM David Majnemer <david.majnemer at gmail.com>
>> wrote:
>>
>>> On Thu, Jun 18, 2015 at 6:19 PM, Sean Silva <chisophugis at gmail.com>
>>> wrote:
>>>>
>>>> On Thu, Jun 18, 2015 at 5:26 PM, Eric Christopher <echristo at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Sean,
>>>>>
>>>>> Daniel is a few time zones ahead and likely won't get this, probably
>>>>> best if you do.
>>>>>
>>>>> That said, we should also talk to David (on the to: line) who put in
>>>>> the personality function change in the first place :)
>>>>>
>>>>
>>>> Yeah. David, is there something reasonable we can do here to avoid
>>>> breaking compatibility? It looks like this just moved from the instruction
>>>> to the function. Could we set it on the function instead? (From your commit
>>>> message on r239940, it seems like any existing correct code already had all
>>>> of the personality functions within a given function the same, so can we
>>>> just set the landingpad on the function?)
>>>>
>>>
>>> We could do that but it would be inconsistent with what we have done
>>> with linkage.  For example: LLVMSetLinkage with LLVMDLLImportLinkage
>>> doesn't call setDLLStorageClass for you.
>>>
>>> I wasn't under the impression that LLVMBuildLandingPad was part of a
>>> stable interface.  Do we have any documentation or comments to that
>>> effect?  I couldn't find anything official looking which stated whether or
>>> not the C bindings are supposed to be link, source or otherwise backwards
>>> compatible.
>>>
>>>
>>
>> It's been a long standing part of the project (though, like you, I
>> couldn't find the explicit documentation) that the C API is source
>> compatible and that we try very hard to keep it as such. You'll notice lots
>> of places we've done odd commits to try to do so.
>>
>
> IMO we should just make LLVMBuildLandingPad() set the personality of the
> parent function. Any frontend using the C API will just keep working. It
> might break more sophisticated users of the C API, but so be it.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150717/1996fecf/attachment.html>