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

[Chandler Carruth]

(re-sending to the actual mailing lists... go go gadget typos!)


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.
>
> 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.
>
> 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.
>
> 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.
>
>
> One short term caveat: Windows is special.
>
> I don't think we should follow the 2-year rule for Windows. It really is
> special for at least three reasons:
> 1) We can't bootstrap on Windows. While there is tons of exciting work
> going on here to change that, even then the quality of Windows support is
> likely to change very rapidly.
> 2) Visual Studio's C++ support moved very slowly for a long time, and is
> now improving at an amazing rate. We shouldn't be hampered by past problems
> and should take advantage of this recent progress.
> 3) We have less insight into when new versions of the MSVC++ toolchain
> will arrive.
>
> So my suggestion is that, at least during the rapid evolution of VS's
> C++11 support and Clang's Windows support, we support building with the
> most recent 2 versions of VS available at the *prior* release. For example
> when we branch for 3.4, the two versions will be 2012 and 2013. Those two
> would be supported on mainline from then through 3.5, and when we branch
> for 3.5 we would re-evaluate.
>
> NOTE: This would drop support for VS 2010!!! That is a huge change, hence
> my suggesting it only *after* we branch for 3.4. It gives us an entire
> release cycle of notice for people relying on it.
>
>
> 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
>
> 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.
>
> -Chandler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131027/4f3bc573/attachment.html>