[llvm] r224782 - Finish removing DestroySource.

Sean Silva chisophugis at gmail.com
Thu Feb 26 14:16:41 PST 2015


On Wed, Feb 25, 2015 at 6:05 AM, Rafael EspĂ­ndola <
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
> 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/20150226/1b177a68/attachment.html>


More information about the llvm-commits mailing list