<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi C++ enthusiasts!<div class=""><br class=""></div><div class="">It’s a new year, so let’s try a new approach in getting LLVM’s codebase past C++11. Instead of discussing toolchain versions and whether C++14 or 17 is best, let’s just focus on one baby step: agreeing on a policy. This policy will be used to update our toolchain, hopefully warning people in LLVM 8 and actually moving past C++11 for LLVM 9.</div><div class=""><br class=""></div><div class="">Good news! I believe we already have agreement on this policy. I went through all the discussions (again) and I think I captured everyone’s points of view and concerns. Here are the discussions: </div><div class=""><ul class=""><li class=""><a href="http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3" class="">LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!"</a></li><li class=""><a href="http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html" class="">A Short Policy Proposal Regarding Host Compilers</a></li><li class=""><a href="http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html" class="">Using C++14 code in LLVM (2018)</a></li><li class=""><a href="http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html" class="">Using C++14 code in LLVM (2017)</a></li><li class=""><a href="http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html" class="">Using C++14 code in LLVM (2016)</a></li><li class=""><a href="http://llvm.org/D47073" class="">Document and Enforce new Host Compiler Policy</a></li><li class=""><a href="http://llvm.org/D46723" class="">Require GCC 5.1 and LLVM 3.5 at a minimum</a></li></ul>When replying to this email, please avoid having the same discussions again. Please provide references to anything I might have missed. If you’re making a new point, say so. And don’t assume ill-will, I’m just trying to get us off C++11.</div><div class=""><br class="">I have a patch for you to review: <a href="https://reviews.llvm.org/D56819" class="">https://reviews.llvm.org/D56819</a></div><div class=""><br class=""></div><div class="">Here’s what it currently says our policy should be:</div><div class=""><br class=""></div><div class=""><font face="Courier" size="1" class="">+We intend to require newer toolchains as time goes by. This means LLVM's<br class="">+codebase can use newer versions of C++ as they get standardized. Requiring newer<br class="">+toolchains to build LLVM can be painful for those building LLVM, it will<br class="">+therefore only be done through the following process:<br class="">+<br class="">+ * Generally, try to support LLVM and GCC versions from the last 3 years at a<br class="">+ minimum. This time-based guideline is not strict: we may support much older<br class="">+ compilers, or decide to support fewer ones.<br class="">+<br class="">+ * An RFC is sent to the `llvm-dev mailing list <<a href="http://lists.llvm.org/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/mailman/listinfo/llvm-dev</a>>`_<br class="">+<br class="">+ - Detail upsides of the version increase (e.g. allow LLVM to use newer C++<br class="">+ language or library features; avoid miscompiles in particular compiler<br class="">+ versions, etc).<br class="">+ - Detail downsides on important platforms (e.g. Ubuntu LTS status).<br class="">+<br class="">+ * Once the RFC reaches consensus, update the CMake toolchain version checks<br class="">+ and this document. We want to soft-error when developers compile LLVM. We<br class="">+ say "soft-error" because the error can be turned into a warning using a<br class="">+ CMake flag. This is an important step: LLVM still doesn't have code which<br class="">+ requires the new toolchains, but it soon will. If you compile LLVM but don't<br class="">+ read the mailing list, we should tell you!<br class="">+<br class="">+ * Ensure that at least one LLVM release has had this soft-error. Not all<br class="">+ developers compile LLVM tip-of-tree. These release-bound developers should<br class="">+ also be told about upcoming changes.<br class="">+<br class="">+ * Turn the soft-error into a hard-error after said LLVM release has branched.<br class="">+<br class="">+ * Update the :doc:`coding standards<CodingStandards>` to explicitly allow the<br class="">+ new features we've now unlocked.<br class="">+<br class="">+ * Start using the new features in LLVM's codebase.</font><br class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">JF</div></body></html>