<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" 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>
    <p>Best, Jonas<br>
    </p>
    <div class="moz-cite-prefix">Am 17.01.19 um 00:35 schrieb JF Bastien
      via llvm-dev:<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>