<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Sure!<br>
</p>
<div class="moz-cite-prefix">Am 17.01.19 um 11:02 schrieb Chandler
Carruth:<br>
</div>
<blockquote type="cite"
cite="mid:CAAwGriFofrFunayKKjh6_6VYkeV6GPU7VrcRDCC5GiPL84Zdrw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Thu, Jan 17, 2019 at 1:49 AM Jonas Toth via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>+1 for keeping up to date :)<br>
</p>
<p>Should the policy say something about old code as well?</p>
<p>Do we consider it as good/reasonable to modernize our
code once the new standards are allowed?<br>
I am thinking of clang-tidy modernization as an approach
to modernize automatically and reduce manual burden.<br>
In general we aim for a consistent style in the
code-base and a view words regarding this issue would be
interesting in my opinion.</p>
</div>
</blockquote>
<div>I think the coding standards used with new code should be
a very separate discussion. While the motivation here is
about moving to C++14 and/or C++17, what is actually being
discussed is just the host toolchain, as that is the part
that requires tooling and other mechanical things we need to
get right along side any policy. (It also has much more
impact on the library *users* IMO, as opposed to primarily
impacting LLVM *developers*. While these overlap, they're
not the same.)</div>
<div><br>
</div>
<div>I'd have a separate discussion about establishing coding
standards and actually updating the language standard when
we have toolchains in place that support it.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Best, Jonas<br>
</p>
<div class="gmail-m_-4264825289329728821moz-cite-prefix">Am
17.01.19 um 00:35 schrieb JF Bastien via llvm-dev:<br>
</div>
<blockquote type="cite"> 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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">Using
C++14 code in LLVM (2016)</a></li>
<li><a href="http://llvm.org/D47073" target="_blank"
moz-do-not-send="true">Document and Enforce new
Host Compiler Policy</a></li>
<li><a href="http://llvm.org/D46723" target="_blank"
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><br>
I have a patch for you to review: <a
href="https://reviews.llvm.org/D56819"
target="_blank" moz-do-not-send="true">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 size="1" face="Courier">+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" moz-do-not-send="true">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>
<br>
<fieldset
class="gmail-m_-4264825289329728821mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-4264825289329728821moz-quote-pre">_______________________________________________
LLVM Developers mailing list
<a class="gmail-m_-4264825289329728821moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<a class="gmail-m_-4264825289329728821moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>