[llvm-dev] [RFC] migrating LLVM to C++14
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 1 16:07:27 PDT 2019
On Mon, Apr 1, 2019 at 1:16 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello folks (except fans of April 1st: this is *not* a joke),
>
> We discussed migrating past C++11
> <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html> recently
> and got consensus. This led us to bump our minimum toolchain requirements
> <https://reviews.llvm.org/D57264> to a point where C++14 was supported by
> all compilers. Following our policy
> <http://llvm.org/docs/DeveloperPolicy.html#toolchain>, I’m now suggesting
> that we make this official by creating a patch which will:
>
>
> - Update the C++ standard version
> <http://llvm.org/docs/CodingStandards.html#c-standard-versions> to
> C++14, allowing the usage of the following language and library features:
> - Binary literals <https://wg21.link/N3472>:
> - Without restrictions.
> - decltype(auto) <https://wg21.link/N3638>, Return type deduction
> for normal functions:
> - As with auto
> <http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>,
> only where it makes code more readable.
> - Initialized/Generalized lambda captures (init-capture)
> <https://wg21.link/N3648>:
> - Without restriction.
> - Generic (polymorphic) lambda expressions <https://wg21.link/N3649>
> :
> - As with auto
> <http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>,
> only where it makes code more readable.
> - Variable templates <https://wg21.link/N3651>:
> - Without restriction.
> - Member initializers and aggregates (NSDMI)
> <https://wg21.link/N3653>:
> - Without restriction.
> - More constexpr everywhere:
> - Without restriction.
> - Single quote as digit separator <https://wg21.link/N3781>:
> - Not allowed.
> - std::quoted <https://wg21.link/N3654>:
> - Without restriction.
> - std::exchange <https://wg21.link/N3668>:
> - Without restriction.
> - Change the minimum toolchain requirement from a “soft-error” to a
> “hard-error” such that CheckCompilerVersion.cmake now says:
> - set(GCC_MIN 5.1)
> set(GCC_SOFT_ERROR 5.1)
> set(CLANG_MIN 3.5)
> set(CLANG_SOFT_ERROR 3.5)
> set(APPLECLANG_MIN 6.0)
> set(APPLECLANG_SOFT_ERROR 6.0)
> set(MSVC_MIN 19.1)
> set(MSVC_SOFT_ERROR 19.1)
> - The above makes LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN useless until
> we try upgrading toolchain versions again.
> - Use C++14 in the code somewhere.
>
>
> When we last discussed this we said we’d revisit at the end of March 2019
> and see if everyone was able to upgrade their toolchains. Remember that by
> now any build of LLVM with an old toolchain has received a “soft-error”
> which people had to read and disable using a CMake argument. This includes
> anyone building LLVM 8 because the change made it to the branch. There were
> plenty of discussions on Phabricator, on the mailing lists, and at the dev
> meeting. The was a PSA
> <http://lists.llvm.org/pipermail/llvm-dev/2019-February/130117.html> and
> emails were sent to all bot maintainers with older bots. At this point
> there’s no way that you didn’t know that you needed to upgrade you
> toolchain.
>
> This would mean that LLVM 9 would require a newer toolchain.
>
> Is anyone not ready for this move?
>
FWIW, despite making good progress, we're not quite finished.
> If so, what does your timing look like?
>
We are significantly closer than when we last talked (two separate big
milestones landed). We're basically on the last step which, for us, is
switching to libc++. AFAIK, we don't have any major blockers, and folks are
mostly trying to land the necessary changes. Optimistically, we'll finish
in April. Conservatively, it might slip a week or two into May, but that
seems unlikely at this point (there are few unknowns left).
>
> Thanks,
>
> JF
>
>
>
> On Jan 22, 2019, at 1:44 PM, JF Bastien via llvm-dev <
> llvm-dev at lists.llvm.org> 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
> https://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/20190401/b4e2784c/attachment-0001.html>
More information about the llvm-dev
mailing list