Hello fans of the auto keyword!
We now have a policy on how LLVM toolchains get updated! Let’s put that policy to good use, and talk about how we’ll move all monorepo projects past C++11.
- LLVM dev meeting 2018 BoF “Migrating to C++14, and beyond!”
- A Short Policy Proposal Regarding Host Compilers
- Using C++14 code in LLVM (2018)
- Using C++14 code in LLVM (2017)
- Using C++14 code in LLVM (2016)
- Document and Enforce new Host Compiler Policy
- Require GCC 5.1 and LLVM 3.5 at a minimum
Migrate to what?
I’m only proposing that we migrate to C++14 for now. If you want to propose C++17, please do the work required by the policy. In particular, document which toolchains this would require, and what features you’d unlock. As per policy, I want to start soft-errors when building LLVM 8, so that LLVM 9 can use more than C++11.
At the LLVM dev meeting BoF, the room already agreed to move past C++11. Late March 2019 was proposed as a time when we’d start migrating, pending large contributors’ readiness. I’m sticking to that timeline, we’ll see if everyone is ready at the end of March. I nonetheless want to get the soft-errors into the LLVM 8 branch so that we give a sufficient heads-up to developers who only compile releases.
One clear upside of dropping older toolchains: they don’t even support C++11 very well. We have a handful of workarounds left in ADT (particularly around type traits) and I’d like to get rid of them.
The compiler versions I propose allow us to use all of C++14, which includes:
- Binary literals
- decltype(auto), Return type deduction for normal functions
- Initialized/Generalized lambda captures (init-capture)
- Generic (polymorphic) lambda expressions
- Variable templates
- Member initializers and aggregates (NSDMI)
- A bunch of new constexpr language and library features
- Various other language and library features
See CppReference for details.
Of these, I think polymorphic lambdas are the big feature. Of course, just like Almost Always Auto, we should use such things only where it makes sense.
We’re currently mandating:
- Clang 3.1 (released 2012/05)
- Apple Clang 3.1 (released 2012/05)
- GCC 4.8 (released 2013/03)
- Visual Studio 2015 (Update 3) (released 2016/06)
I propose instead:
- Clang 3.5 (released 2014/07) to get -std=c++14 instead of -std=c++1y
- Apple Clang 6.0 (released 2014/07) to match clang 3.5
- GCC 5.1 (released 2015/04) because C++14 mostly came to be in GCC 5
- Visual Studio 2017 (released 2017/03) so that we get extended constexpr and NSDMI
Version information from:
- Clang http://releases.llvm.org
- Apple clang https://trac.macports.org/wiki/XcodeVersionInfo and https://en.wikipedia.org/wiki/Xcode#Latest_versions
- GCC https://gcc.gnu.org/releases.html
- MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio and https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
My previous attempts pointed out that WebKit / Chromium / Firefox are all past C++11 (WebKit is moving to C++17 (from C++14), Chromium started moving to C++14, Firefox uses some C++14). This means that platforms which distribute a modern browser can already bootstrap a browser. That’s a nice datapoint, but isn’t sufficient for platforms which compile / use LLVM (especially as a library).
Here’s a table from the LLVM dev meeting BoF detailing version info for distros that seemed relevant:
Debian 7 wheezy
Debian 8 jessie
Debian 9 stretch
Debian 10 buster
The data comes from the following sources:
I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody complained at the BoF. I’d like to understand if we should care about documenting these: ideally the toolchain update policy would list which platforms need to be considered and how far back in time is relevant.