[llvm-dev] LLVM C api changes

[Eric Christopher via llvm-dev]

+1 to this. Bikeshedding a bit I'd like to see something like
LLVMIntrinsicCopyOverloadedNameWithModule maybe... at which point you don't
have to move, but deprecate and migrate? Or
LLVMIntrinsicCopyOverloadedNameWithUnnamedType which seems to be a
mouthful, but...

Anyhow a few thoughts there. Tag me in the review and we can chat.

-eric

On Tue, Mar 23, 2021 at 5:29 PM James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>>
> _______________________________________________
> 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/b4b07c58/attachment-0001.html>