[llvm-dev] [RFC] migrating LLVM to C++14
Eric Fiselier via llvm-dev
llvm-dev at lists.llvm.org
Sun Aug 4 05:32:26 PDT 2019
I'm happy to announce that Google has migrated to libc++, and we're ready
for C++14 and beyond.
JF, what are the remaining blockers?
/Eric
On Mon, May 6, 2019 at 5:12 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On May 6, 2019, at 2:08 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
>
> 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.
>
>
> Yeah I don’t think it’s worth pushing for this if we can just wait a bit
> more and get a clean transition. Since this is our first toolchain bump in
> a while I’d like it to be as clean as it can so we all have a fond memory
> of it and don’t balk at subsequent toolchain bumps :)
>
>
> [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
>>>
>>
> _______________________________________________
> 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/20190804/cef26999/attachment-0001.html>
More information about the llvm-dev
mailing list