[llvm-dev] [RFC] migrating past C++11

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/compiler_support> 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#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 
> <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/Using_CXX_in_Mozilla_code>). 
> 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/compiler_support
>   * 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>