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

[Evan Cheng]

On Oct 27, 2013, at 11:18 AM, Chris Lattner <clattner at apple.com> wrote:

> On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <chandlerc at google.com> wrote:
>> Greetings,
>> 
>> This has been discussed many times, and there are a lot of pro's and con's on each side, but increasingly I think the project needs to draw a line in the sand and put in place long-term policies around support for building LLVM & Clang with older C++ toolchains. It also would have the benefit of removing divergence between LLVM sub-projects already using C++11 features. As they have grown in popularity and as code moves back and forth across project boundaries, I think this is a growing strain.
> 
> Awesome, thank you for spearheading this discussion.  We really need to move to some C++'11 support, it is just a question of how and when.  We also had a discussion from a few months ago about this, can you summarize where we left off?  I thought there was a tentative plan for LLVM 3.4 (or maybe it was after 3.4 branched).

I have a quick question on this. Apology if this has already been answered in the past. Am I correct in assuming this also force changes to other projects which link in LLVM?

Evan

> 
> 
>> I am seriously concerned that if we don't do this now, we will miss out on the accelerating trend of C++ as a language.
> 
> I'm not worried about the "accelerating trend", I just think we'll all be more productive.
> 
>> Concrete long term proposal:
>> 
>> We support building with C++ toolchains which were released and widely available on their respective target platforms at least 2 years prior to the next 6-month-cycle release. Immediately after each branch of a release, mainline can move the bar forward by 6 months. Thus, each release should build with the four previous releases.
> 
> I don't think it makes sense to have a hard policy like this.  It is fine to have a goal that allows us to continue picking up new features over time, but I think each such change will have to be discussed (at length) with the specifics of which interesting host configurations we would be dropping.
> 
>> Some observations:
>> - I specifically am wording this to enable the mainline to use features sooner. People who are unable to use an *even more* modern toolchain will necessarily stay with each release.
>> - This is an aggressive timeline. That is intentional. There is increasing pressure for LLVM to make use of new C++ language and library features.
>> - There is always the option of checking out an old release, building it, and then using that compiler to build the latest release or to build the mainline compiler.
>> - The goal is to only change the supported toolchain set and thus C++ dialect after a release branches to avoid confusion, churn, and impeding QA on a release. People can check out trunk and get an idea of whether they will have problems with the next release.
>> - I have historically been more conservative on this topic, but listening to many people and looking at some of the C++ features we are missing, I think the right strategy for the project is a more aggressive one.
> 
> I really want this to happen, but it needs to be done in the right way, balancing the cost to the community to obsolete old configurations.  As such, I agree with everything except your last point here :-)
> 
>> One short term caveat: Windows is special.
> 
> I don't see how it is special.  We should just look at all of the compilers we need to support, and factor that set in.  We should continue to increment the baseline compilers over time, but a global "two year old compilers only" policy doesn't make sense to me.  I also think that windows will be the lowest bar anyway.
> 
>> Now for the carrot: if we go with this plan, then immediately after branching for 3.4,  we would be able to use the vast majority of C++11 features, targeting the following as the oldest toolchains supported through the 3.5 release timeframe:
>> 
>> GCC 4.7
>> Clang 3.1
>> VS 2012
> 
> This seems overly aggressive to me.  Why not start by baselining at VC++ 2010, and bump up everything else to match?  That would give us some basic C++'11 features for 3.4, then we could bump it up to VS 2012 in 3.5 if that goes well.
> 
> -Chris
> 
>> 
>> Some notable features we would get to use:
>> 
>> - r-value references, move semantics, etc
>> - auto
>> - range for loops
>> - lambdas
>> - static_assert
>> - nullptr
>> - std::unique_ptr, std::tuple, some other nice library stuff
>> 
>> 
>> These days, this list seems increasingly worth the cost of forcing users to get a modern toolchain onto their systems.
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev