[llvm] r224782 - Finish removing DestroySource.

Juergen Ributzka juergen at apple.com
Mon Mar 2 11:03:45 PST 2015

Hi Rafael and Sean,

I committed the patch in r230988 with the changes you suggested.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150302/6e103a06/attachment.html>

More information about the llvm-commits mailing list