[llvm-dev] Using C++14 code in LLVM

[Justin Bogner via llvm-dev]

Mehdi Amini <mehdi.amini at apple.com> writes:
>> On Oct 3, 2016, at 10:38 AM, Justin Bogner via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> 
>> Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org
>> <mailto:llvm-dev at lists.llvm.org>> writes:
>>> A thread was started over the summer to discuss the timeline for bumping
>>> LLVM up to Visual Studio 2015 to enable the use of various new language
>>> features.  Currently the ETA for this is sometime in mid-October, so within
>>> 2-3 weeks.
>>> 
>>> With this happening imminently, I thought it would be worth tossing this
>>> out there and seeing what people think.
>>> 
>>> With VS on 2015, the major lagging compiler is going to be GCC.  Our
>>> minimum GCC requirement is 4.7, which is quite old (almost 4 years for
>>> anyone keeping count).  What are the challenges with pushing this forward?
>>> 
>>> With VS2015, the biggest remaining missing C++14 features are variable
>>> templates, sized allocation, and extended constexpr.  But it gains generic
>>> lambdas, init-captures, decltype(auto) return, and auto return without
>>> requiring the trailing -> decltype syntax.
>> 
>> I'm not convinced that the cost is worth the gain for these features.
>> Most of these are relatively straight forward (with more boilerplate) to
>> work around in C++11, and I'd rather we not get into a situation where
>> to bootstrap clang you need to build a C++11 compatible version so that
>> you can build a C++14 compatible one so that you can build a C++17
>> compatible one, etc. Consider that -std=c++17 isn't yet a valid flag on
>> trunk clang, so if we bump to C++14 now then we're practically
>> guaranteed that when we want to update to 17 we'll run into multi-stage
>> bootstrapping problems.
>
> I didn’t quite get this last part, can you elaborate please?

Consider if we adopt C++14 features today. Then to build clang-4.0 you
need a C++14 compatible compiler (Maybe clang-3.4, probably more like
clang-3.5 or clang-3.6 based on our current clang-3.1 claim). So to
bootstrap you build clang-3.5 (I think that's before we required C++11)
and then build clang-4.0.

That's not too bad, but then lets say we switch to requiring C++17 in
clang-4.4 - now, you need to build clang-3.5 first so that you can build
clang-4.0, *then* you use clang-4.0 to build clang-4.4. What I'm nervous
about here is increasing the number of steps to get to a working
compiler - I don't think we want to require C++14 before we can even
build C++17.