[llvm-dev] LLVM C api changes

[James Y Knight via llvm-dev]

Yes, it is not guaranteed. However, when it is *not* necessary to break it,
then you shouldn't. And here it's not necessary. So, yes, add the "2"
version, and leave the old one as well (marked deprecated, pointing to the
new function).

Additionally, if it is necessary to break compatibility, then it's
desirable to break it as obviously as possible. E.g., if the Module
parameter is strictly required, and the old function could no longer
operate, then it's still better to go ahead and introduce a new "2"
version, and also delete the original function. That'll cause a link or
load error if someone's using it, rather than potentially
mysterious behavior from a mismatch between the caller and callee argument
lists. (Since the purpose of these APIs is other-language interop, you
can't necessarily depend on a C compiler seeing the change in the header
and throwing a "missing argument" error -- there may not be a C compiler,
and the header may not be involved.)


On Tue, Mar 23, 2021 at 4:11 PM Arthur Eubanks via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> https://llvm.org/docs/DeveloperPolicy.html#c-api-changes doesn't say we
> guarantee strict backward compatibility, in fact it implies the opposite,
> that's it's "best effort" but can be broken when necessary (except within a
> release branch).
>
> On Tue, Mar 23, 2021 at 12:26 PM via llvm-dev <llvm-dev at lists.llvm.org>
> wrote:
>
>> > For https://reviews.llvm.org/D99173 I need to introduce an extra
>> > 'LLVMModuleRef' argument to 'LLVMIntrinsicCopyOverloadedName',
>> > so that we correctly handle intrinsics with arguments based on
>> > unnamed types.
>> >
>> > Can this be done ? Or is it recommended to add a
>> > 'LLVMIntrinsicCopeOverloadedName2' with the extra argument ?
>> > And keep the original one for backwards compatibility ?
>>
>> The C API has a strict backward compatibility rule; you will need
>> to add a new function that has the additional parameter.
>>
>> --paulr
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210323/0cd34334/attachment.html>