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

Tue Aug 13 16:52:50 PDT 2019

I tried removing the “soft errors” last Thursday night, and no bot complained. I reverted it and am now sending it through a proper patch with review:
https://reviews.llvm.org/D66188 <https://reviews.llvm.org/D66188>
Once it sticks I’ll bump the minimum language version and commit actual C++14 code :)

> On Aug 4, 2019, at 10:04 AM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Awesome! Thanks for going through it. 
> 
> Next step is to wind down all the older bots, then hard-failing the older compilers instead of having the opt-out. Finally, bump the -std= version and use C++14. 
> 
> I’ll reach out to bot owners on Monday. It’ll probably take a few tries to hard-fail the old compilers. 
> 
> 
>> On Aug 4, 2019, at 8:24 AM, Eric Fiselier <eric at efcs.ca> wrote:
>> 
>> 
>> 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 <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> 
>>> On May 6, 2019, at 2:08 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
>>> 
>>> On Mon, May 6, 2019 at 2:44 PM James Y Knight <jyknight at google.com <mailto: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 <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 <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 
>>> 
>>>> On May 6, 2019, at 11:02 AM, Chandler Carruth <chandlerc at gmail.com <mailto: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 <mailto:jfbastien at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On Apr 1, 2019, at 4:10 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Apr 1, 2019, at 4:07 PM, Chandler Carruth <chandlerc at gmail.com <mailto: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 <mailto: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 <mailto: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 <http://releases.llvm.org/>
>>>>>>> Apple clang https://trac.macports.org/wiki/XcodeVersionInfo <https://trac.macports.org/wiki/XcodeVersionInfo> and https://en.wikipedia.org/wiki/Xcode#Latest_versions <https://en.wikipedia.org/wiki/Xcode#Latest_versions>
>>>>>>> GCC https://gcc.gnu.org/releases.html <https://gcc.gnu.org/releases.html>
>>>>>>> MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio <https://en.wikipedia.org/wiki/Microsoft_Visual_Studio> and https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance <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://en.cppreference.com/w/cpp/compiler_support>
>>>>>>> https://packages.ubuntu.com/search?keywords=gcc <https://packages.ubuntu.com/search?keywords=gcc>
>>>>>>> https://packages.debian.org/search?keywords=gcc <https://packages.debian.org/search?keywords=gcc>
>>>>>>> https://access.redhat.com/solutions/19458 <https://access.redhat.com/solutions/19458>
>>>>>>> https://www.openbsd.org/63.html <https://www.openbsd.org/63.html>
>>>>>>> https://en.wikipedia.org/wiki/Clang <https://en.wikipedia.org/wiki/Clang>
>>>>>>> https://releases.llvm.org <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 <mailto:llvm-dev at lists.llvm.org>
>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20190813/0599631a/attachment-0001.html>