<div dir="ltr">Strong +1 on the process, I really do think it captures both the desire to have *some* time input so we don't grow ever more stale, *and* the desire to upgrade for a reason and with a clear understanding of the cost/benefit to users.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 16, 2019 at 3:35 PM JF Bastien via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi C++ enthusiasts!<div><br></div><div>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><br></div><div>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><ul><li><a href="http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3" target="_blank">LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!"</a></li><li><a href="http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html" target="_blank">A Short Policy Proposal Regarding Host Compilers</a></li><li><a href="http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html" target="_blank">Using C++14 code in LLVM (2018)</a></li><li><a href="http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html" target="_blank">Using C++14 code in LLVM (2017)</a></li><li><a href="http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html" target="_blank">Using C++14 code in LLVM (2016)</a></li><li><a href="http://llvm.org/D47073" target="_blank">Document and Enforce new Host Compiler Policy</a></li><li><a href="http://llvm.org/D46723" target="_blank">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><br>I have a patch for you to review: <a href="https://reviews.llvm.org/D56819" target="_blank">https://reviews.llvm.org/D56819</a></div><div><br></div><div>Here’s what it currently says our policy should be:</div><div><br></div><div><font face="Courier" size="1">+We intend to require newer toolchains as time goes by. This means LLVM's<br>+codebase can use newer versions of C++ as they get standardized. Requiring newer<br>+toolchains to build LLVM can be painful for those building LLVM, it will<br>+therefore only be done through the following process:<br>+<br>+ * Generally, try to support LLVM and GCC versions from the last 3 years at a<br>+ minimum. This time-based guideline is not strict: we may support much older<br>+ compilers, or decide to support fewer ones.<br>+<br>+ * An RFC is sent to the `llvm-dev mailing list <<a href="http://lists.llvm.org/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/mailman/listinfo/llvm-dev</a>>`_<br>+<br>+ - Detail upsides of the version increase (e.g. allow LLVM to use newer C++<br>+ language or library features; avoid miscompiles in particular compiler<br>+ versions, etc).<br>+ - Detail downsides on important platforms (e.g. Ubuntu LTS status).<br>+<br>+ * Once the RFC reaches consensus, update the CMake toolchain version checks<br>+ and this document. We want to soft-error when developers compile LLVM. We<br>+ say "soft-error" because the error can be turned into a warning using a<br>+ CMake flag. This is an important step: LLVM still doesn't have code which<br>+ requires the new toolchains, but it soon will. If you compile LLVM but don't<br>+ read the mailing list, we should tell you!<br>+<br>+ * Ensure that at least one LLVM release has had this soft-error. Not all<br>+ developers compile LLVM tip-of-tree. These release-bound developers should<br>+ also be told about upcoming changes.<br>+<br>+ * Turn the soft-error into a hard-error after said LLVM release has branched.<br>+<br>+ * Update the :doc:`coding standards<CodingStandards>` to explicitly allow the<br>+ new features we've now unlocked.<br>+<br>+ * Start using the new features in LLVM's codebase.</font><br><br></div><div>Thanks,</div><div><br></div><div>JF</div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>