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

[Chandler Carruth]

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/cfe-dev/attachments/20131027/8d1e1df3/attachment.html>