[llvm-dev] Explicitly spelling out the lack of stability for the C++ API in the Developer Policy? (original) (raw)

David Chisnall via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 23 08:38:38 PDT 2020

On 23/07/2020 16:28, Nicolai Hähnle via llvm-dev wrote:

I'm generally on board with this, certainly between LLVM releases, but I feel like it would be friendlier to use (potentially short-lived) deprecation as a tool for LLVM trunk.

We maintain an out-of-tree compiler[0] and try to be good citizens by following LLVM trunk very closely. It is always frustrating when a very central part of LLVM (like the Builders, or Instructions) have a "flag-day" change, where our frontend must be changed in a way where the new version doesn't work with LLVM trunk that is even a few days old, and the old version doesn't work with current LLVM trunk. In many, many cases it is almost zero effort for the person making the chance in LLVM to split it up into a sequence of logical changes: 1) Add the new API. 2) Use it in llvm-project. 3) Add LLVMATTRIBUTEDEPRECATED to the old API. 4) Remove the old API. 1-3 could be in a single commit, but having a few weeks between them and point 4 helpsmassively. It allows us to keep compiling against LLVM trunk in our CI, while one person goes and fixes up our use of the API (which we can detect automatically thanks to the warning or -Werror). It also makes it easier for us to bisect regressions across such API changes. With the alternative, where 1-4 are all in a single commit, our integration with LLVM trunk is blocked until somebody can fix it -- which is usually as quick as 1 or 2 days, but during that time window we don't catch anyother regressions in LLVM trunk that might affect us. So please, let's make it a common rule to use this two-step, transactional approach to changes in APIs that are relatively "core" (which mostly means llvm/IR, llvm/ADT, llvm/Support, perhaps with a side of llvm/Analysis). I am perfectly fine with this rule being broken occasionally, for changes where it would be exceedingly tricky to do them in a non-flag-day way. But in our experience, most of the changes that would actually affect an out-of-tree frontend aren't this tricky.

I agree that deprecation is much more friendly but the last time I proposed it there was a lot of push-back. Given this thread is about documenting the existing policy, rather than changing the policy, I I'd recommend starting a new RFC thread about deprecation.

David

More information about the llvm-dev mailing list