[llvm] r224782 - Finish removing DestroySource.

[Rafael Espíndola]

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

LGTM with that.

Cheers,
Rafael