[llvm-dev] [RFC] migrating past C++11 (original) (raw)

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 22 17:41:39 PST 2019

I have no objection to the end of March timeline for C++14.  This will still be a bit of a pain for us, but at the moment, I think we're on target for the previously communicated dates.  I'll note that having a lot of warning for this (Nov to March) was a key factor in my no objection response.  :)

Philip

On 1/22/19 1:44 PM, JF Bastien via llvm-dev wrote:

Hello fans of the auto keyword!

We now have a policy on how LLVM toolchains get updated <https://reviews.llvm.org/rL351765>! Let’s put that policy to good use, and talk about how we’ll move all monorepo projects past C++11.

Previous Discussions * LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond! <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>" * A Short Policy Proposal Regarding Host Compilers <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html> * Using C++14 code in LLVM (2018) <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html> * Using C++14 code in LLVM (2017) <http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html> * Using C++14 code in LLVM (2016) <http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html> * Document and Enforce new Host Compiler Policy <http://llvm.org/D47073> * Require GCC 5.1 and LLVM 3.5 at a minimum <http://llvm.org/D46723> * * 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. Timeline 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. Upsides 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 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf> * decltype(auto), Return type deduction for normal functions <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html> * Initialized/Generalized lambda captures (init-capture) <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html> * Generic (polymorphic) lambda expressions <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html> * Variable templates <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf> * Member initializers and aggregates (NSDMI) <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html> * A bunch of new constexpr language and library features * Various other language and library features See CppReference <https://en.cppreference.com/w/cpp/compilersupport> 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. Toolchains 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#Latestversions * GCC https://gcc.gnu.org/releases.html * MSVC https://en.wikipedia.org/wiki/MicrosoftVisualStudio 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 <https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html> (from C++14), Chromium started moving to C++14 <https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>, Firefox uses some C++14 <https://developer.mozilla.org/en-US/docs/Mozilla/UsingCXXinMozillacode>). 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: Release Distro Compiler C++14 lang 2003-10 RHEL 3 GCC 3.2 ❌ 2005-02 RHEL 4 GCC 3.4 ❌ 2007-03 RHEL 5 GCC 4.1 ❌ 2010-11 RHEL 6 GCC 4.4 ❌ 2013-05 Debian 7 wheezy GCC 4.7.2 ❌ 2013-12 RHEL 7 GCC 4.8 ❌ 2015-04 Debian 8 jessie GCC 4.9.2 ❌ 2015-05 OpenBSD 5.7 LLVM 3.5 ✅ 2015-10 OpenBSD 5.8 LLVM 3.5 ✅ 2016-03 OpenBSD 5.9 LLVM 3.5 ✅ 2016-04 Ubuntu 14.04 GCC 4.8.2 ❌ 2016-04 Ubuntu 16.04 GCC 5.3.1 ✅ 2016-09 OpenBSD 6.0 LLVM 3.8 ✅ 2017-04 OpenBSD 6.1 LLVM 4.0.0 ✅ 2017-06 Debian 9 stretch GCC 6.3.0 ✅ 2017-10 Ubuntu 17.10 GCC 7.2.0 ✅ 2017-10 OpenBSD 6.2 LLVM 5.0.0 ✅ 2018-04 Ubuntu 18.04 GCC 7.3.0 ✅ 2018-04 OpenBSD 6.3 LLVM 5.0.1 ✅ 2018-10 Ubuntu 18.10 GCC 8.1.0 ✅ 2018-?? Debian 10 buster GCC 8.1.0 ✅ The data comes from the following sources: * https://en.cppreference.com/w/cpp/compilersupport * https://packages.ubuntu.com/search?keywords=gcc * https://packages.debian.org/search?keywords=gcc * https://access.redhat.com/solutions/19458 * https://www.openbsd.org/63.html * https://en.wikipedia.org/wiki/Clang * https://releases.llvm.org 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. Thanks, JF

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190122/9744f0f6/attachment-0001.html>

More information about the llvm-dev mailing list