<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Rafael and Sean,<div class=""><br class=""></div><div class="">I committed the patch in r230988 with the changes you suggested.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Juergen</div><div class=""> </div><div class=""><div><blockquote type="cite" class=""><div class="">On Feb 26, 2015, at 2:16 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" class="">chisophugis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Feb 25, 2015 at 6:05 AM, Rafael Espíndola <span dir="ltr" class=""><<a href="mailto:rafael.espindola@gmail.com" target="_blank" class="">rafael.espindola@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> LLVM should have its own process in place for ensuring that C API stability<br class="">
> guidelines are obeyed. These guidelines, as I understand them, are that<br class="">
> once a C API function or type makes it into a release, it must not be<br class="">
> removed without some period of deprecation. Function names, signatures,<br class="">
> type names, and enum members should be part of that to enable source-level<br class="">
> compatibility. If that isn't the policy now, then that's the policy I would<br class="">
> ask for.<br class="">
<br class="">
</span>More or less. We never documented a policy for the C api, only for the IR.<br class="">
<br class="">
There was some discussion on it. My opinion is that it is simply<br class="">
impossible to guarantee perfect compatibility. If libclang has a off<br class="">
by one bug somewhere, someone might be compensating for it and<br class="">
therefore depending on the bug. Every bug fix is a potential<br class="">
compatibility issue.<br class="">
<br class="">
I think our policy should be to not break existing users. What that<br class="">
translates to is that llvm developers have to do a judgment call on<br class="">
how risky a give change is. If they get it wrong (like I did for this<br class="">
one) and someone finds that their program broke, we put that api back<br class="">
in, and go the slow route of deprecating it with a Release note.<br class="">
<br class="">
This does put a burden on the users (WebKit) to test with release<br class="">
candidates to make sure it still works. I honestly think that is fair,<br class="">
since they are the ones that benefit from this and maintaining C api<br class="">
compatibility has a substantial cost.<br class="">
<br class="">
On the trunk patch:<br class="">
<br class="">
+ LLVMLinkerPreserveSourceRemoved = 1 /* If used, this behaves like<br class="">
+ LLVMLinkerDestroySource. */<br class="">
<br class="">
Just note in the comment that this is deprecated and should not be used.<br class=""></blockquote><div class=""><br class=""></div><div class="">Tiny bikeshed, but LLVMLinkerPreserveSource_Removed (i.e. adding an underscore) is likely to be slightly better in that it is more likely to avoid confusion as to whether the "Removed" is actually a part of the name or not. We don't use underscores otherwise in the surrounding names, so the underscore should hopefully be a slightly better indication.</div><div class=""><br class=""></div><div class="">-- Sean Silva</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br class="">
LGTM with that.<br class="">
<br class="">
Cheers,<br class="">
Rafael<br class="">
<div class=""><div class="h5">_______________________________________________<br class="">
llvm-commits mailing list<br class="">
<a href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a><br class="">
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br class="">
</div></div></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">llvm-commits mailing list<br class=""><a href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a><br class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br class=""></div></blockquote></div><br class=""></div></body></html>