<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 6:05 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><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>
> guidelines are obeyed.  These guidelines, as I understand them, are that<br>
> once a C API function or type makes it into a release, it must not be<br>
> removed without some period of deprecation.  Function names, signatures,<br>
> type names, and enum members should be part of that to enable source-level<br>
> compatibility.  If that isn't the policy now, then that's the policy I would<br>
> ask for.<br>
<br>
</span>More or less. We never documented a policy for the C api, only for the IR.<br>
<br>
There was some discussion on it. My opinion is that it is simply<br>
impossible to guarantee perfect compatibility. If libclang has a off<br>
by one bug somewhere, someone might be compensating for it and<br>
therefore depending on the bug. Every bug fix is a potential<br>
compatibility issue.<br>
<br>
I think our policy should be to not break existing users. What that<br>
translates to is that llvm developers have to do a judgment call on<br>
how risky a give change is. If they get it wrong (like I did for this<br>
one) and someone finds that their program broke, we put that api back<br>
in, and go the slow route of deprecating it with a Release note.<br>
<br>
This does put a burden on the users (WebKit) to test with release<br>
candidates to make sure it still works. I honestly think that is fair,<br>
since they are the ones that benefit from this and maintaining C api<br>
compatibility has a substantial cost.<br>
<br>
On the trunk patch:<br>
<br>
+  LLVMLinkerPreserveSourceRemoved = 1 /* If used, this behaves like<br>
+                                         LLVMLinkerDestroySource. */<br>
<br>
Just note in the comment that this is deprecated and should not be used.<br></blockquote><div><br></div><div>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><br></div><div>-- Sean Silva</div><div><br></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>
LGTM with that.<br>
<br>
Cheers,<br>
Rafael<br>
<div class=""><div class="h5">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>