LLVM C api changes

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 ?

Thanks,

Jeroen Dobbelaere

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

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).

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.)

+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