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

[Mehdi Amini via llvm-dev]

> On Oct 3, 2016, at 11:14 AM, Justin Bogner <mail at justinbogner.com> wrote:
> 
> 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.

OK, got it.

— 
Mehdi