[llvm-dev] [RFC] migrating LLVM to C++14

Mon May 6 14:08:02 PDT 2019

On Mon, May 6, 2019 at 2:44 PM James Y Knight <jyknight at google.com> wrote:

> Given the small number of library features added by c++14, and given that
> they were mostly already implemented in libstdc++ 4.9 [1], I suspect that
> moving to c++14 with that stdlib as the minimum probably will not actually
> cause friction for developers who are using normal toolchains to be able to
> keep compatibility with it.
>
> The main thing missing seems to be heterogeneous lookup in associative
> containers. While llvm often uses its own containers, that's not
> universally the case, so it is possible someone may run into that
> deficiency when trying to write new code.
>

Again, I'm not really opposed to this, but I'd like to understand what the
process is for keeping these from creeping into the codebase. I mean, we
can just revert all the patches that introduce failures here, but that
seems somewhat unfriendly w/o build bots. What I don't think we can do is
commit to fixing (without revert) any patch that introduces an issue.

>
> [1]
> https://gcc.gnu.org/onlinedocs/gcc-4.9.4/libstdc++/manual/manual/status.html#status.iso.2014
>
>
> On Mon, May 6, 2019 at 2:08 PM JF Bastien via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On May 6, 2019, at 11:02 AM, Chandler Carruth <chandlerc at gmail.com>
>> wrote:
>>
>> I know you'll be shocked that we've slipped in our efforts. ;] I don't
>> have a super meaningful ETA update though -- a bunch of unknows have been
>> found and addressed, and again, I feel like we might finish this in roughly
>> a month.
>>
>> On the flip side, I do want to clarify the immediate concern we have: we
>> need to be able to use LLVM libraries with libstdc++4.9. We can set
>> `-std=c++14` (or newer) w/o issue. So in some senses, if LLVM folks want to
>> move to C++14, that's fine. But if it involves moving the minimum supported
>> GCC version (and thus libstdc++ version tested on build bots) past
>> libstdc++4.9, any changes that break with that version would be a big
>> problem for us.
>>
>>
>> Thanks for the update! No worries, stuff’s hard. About your suggestion:
>> at least for me I don’t think the headache is really worth the rush. I’d
>> much rather do a clean migration when all is ready.
>>
>>
>> On Mon, May 6, 2019 at 11:51 AM JF Bastien <jfbastien at apple.com> wrote:
>>
>>>
>>>
>>> On Apr 1, 2019, at 4:10 PM, JF Bastien via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>
>>>
>>> On Apr 1, 2019, at 4:07 PM, Chandler Carruth <chandlerc at gmail.com>
>>> wrote:
>>>
>>> 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).
>>>
>>>
>>> No problem, and thanks for the update. Let’s take another look in May.
>>>
>>> In the meantime, we can discuss the rest of the proposal. All that’ll be
>>> left for May is to rubber-stamp the patch.
>>>
>>>
>>> Hello all! It’s May and I was wondering: how are things going with the
>>> libc++ migration? Is everything ready and sufficiently settled so that we
>>> can migrate LLVM to C++14?
>>>
>>> Thanks!
>>>
>>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>>
>> _______________________________________________
>> 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/20190506/027b612c/attachment.html>