<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>This seems generally quite reasonable to me. +1</p>
<p>I reserve the right to object to any particular RFC under the
proposed process of course. :)<br>
</p>
<div class="moz-cite-prefix">On 1/16/19 3:35 PM, JF Bastien via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2E819B58-A3F3-4618-9198-7D54CEFDC076@apple.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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="" moz-do-not-send="true">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="" moz-do-not-send="true">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="" moz-do-not-send="true">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="" moz-do-not-send="true">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="" moz-do-not-send="true">Using C++14 code in LLVM
(2016)</a></li>
<li class=""><a href="http://llvm.org/D47073" class=""
moz-do-not-send="true">Document and Enforce new Host
Compiler Policy</a></li>
<li class=""><a href="http://llvm.org/D46723" class=""
moz-do-not-send="true">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=""
moz-do-not-send="true">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 class="" size="1" face="Courier">+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="" moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</body>
</html>