<div dir="ltr">Yes, it is not guaranteed. However, when it is <i>not</i> 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).<div><br></div><div>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.)</div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 23, 2021 at 4:11 PM Arthur Eubanks via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><a href="https://llvm.org/docs/DeveloperPolicy.html#c-api-changes" target="_blank">https://llvm.org/docs/DeveloperPolicy.html#c-api-changes</a> 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).<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 23, 2021 at 12:26 PM via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> For <a href="https://reviews.llvm.org/D99173" rel="noreferrer" target="_blank">https://reviews.llvm.org/D99173</a> I need to introduce an extra<br>
> 'LLVMModuleRef' argument to 'LLVMIntrinsicCopyOverloadedName',<br>
> so that we correctly handle intrinsics with arguments based on<br>
> unnamed types.<br>
> <br>
> Can this be done ? Or is it recommended to add a<br>
> 'LLVMIntrinsicCopeOverloadedName2' with the extra argument ?<br>
> And keep the original one for backwards compatibility ?<br>
<br>
The C API has a strict backward compatibility rule; you will need<br>
to add a new function that has the additional parameter.<br>
<br>
--paulr<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>