[cfe-dev] [LLVMdev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

[David Chisnall]

On 6 Nov 2013, at 08:10, Renato Golin <renato.golin at linaro.org> wrote:

> On 5 November 2013 10:12, <dag at cray.com> wrote:
>> I'm fine with the general plan but I do want to see a longer notice
>> period for toolchain changes on trunk.  1-2 months is too short.
> 
> I may be wrong, but I think the final consensus was: for every new change, warn on (at least) one previous release as when the changes go live.
> 
> If I'm mistaken, this is still my opinion on the matter.

I think his point was that we encourage out-of-tree projects to follow ToT[1] and so announcing in x.y that x.(y+1) will use C++11 (or C++14) feature Z means that people may start using that feature in ToT as soon as the x.y release is branched (which may be even before the announcement that x.(y+1) will use the new feature).

If the new feature requires out-of-tree LLVM users to upgrade their toolchains then we may only be giving them a month or less warning, even if we are giving downstream packagers 6 months.  

Given how hard we already make it for people to follow ToT for out-of-tree projects (and how much we shout at them when they don't), I'd rather that we didn't make it any harder.  

And with my downstream packager hat on, it's frustrating that we don't make it easier, because we end up having to make sure that it's possible to install half a dozen different versions of LLVM simultaneously because there are always some projects that depend on an old one and only have the manpower to handle the API churn every few releases - I think we've now finally got rid of the ones that depend on LLVM 2.6, but 2.8 is still quite popular.

David

[1] We make their life very hard by introducing new APIs long before we document them. For example, we still don't have adequate documentation of the new attributes classes, but that's a separate rant.