[llvm-dev] [RFC] Toolchain update policy (migrating LLVM past C++11)

Thu Jan 17 04:21:43 PST 2019

Sure!

Am 17.01.19 um 11:02 schrieb Chandler Carruth:
> On Thu, Jan 17, 2019 at 1:49 AM Jonas Toth via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     +1 for keeping up to date :)
>
>     Should the policy say something about old code as well?
>
>     Do we consider it as good/reasonable to modernize our code once
>     the new standards are allowed?
>     I am thinking of clang-tidy modernization as an approach to
>     modernize automatically and reduce manual burden.
>     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.
>
> 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.)
>
> 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.
>  
>
>     Best, Jonas
>
>     Am 17.01.19 um 00:35 schrieb JF Bastien via llvm-dev:
>>     Hi C++ enthusiasts!
>>
>>     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.
>>
>>     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: 
>>
>>       * LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!"
>>         <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>
>>       * A Short Policy Proposal Regarding Host Compilers
>>         <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
>>       * Using C++14 code in LLVM (2018)
>>         <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
>>       * Using C++14 code in LLVM (2017)
>>         <http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
>>       * Using C++14 code in LLVM (2016)
>>         <http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
>>       * Document and Enforce new Host Compiler Policy
>>         <http://llvm.org/D47073>
>>       * Require GCC 5.1 and LLVM 3.5 at a minimum
>>         <http://llvm.org/D46723>
>>
>>     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.
>>
>>     I have a patch for you to review: https://reviews.llvm.org/D56819
>>
>>     Here’s what it currently says our policy should be:
>>
>>     +We intend to require newer toolchains as time goes by. This
>>     means LLVM's
>>     +codebase can use newer versions of C++ as they get standardized.
>>     Requiring newer
>>     +toolchains to build LLVM can be painful for those building LLVM,
>>     it will
>>     +therefore only be done through the following process:
>>     +
>>     +  * Generally, try to support LLVM and GCC versions from the
>>     last 3 years at a
>>     +    minimum. This time-based guideline is not strict: we may
>>     support much older
>>     +    compilers, or decide to support fewer ones.
>>     +
>>     +  * An RFC is sent to the `llvm-dev mailing list
>>     <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_
>>     +
>>     +    - Detail upsides of the version increase (e.g. allow LLVM to
>>     use newer C++
>>     +      language or library features; avoid miscompiles in
>>     particular compiler
>>     +      versions, etc).
>>     +    - Detail downsides on important platforms (e.g. Ubuntu LTS
>>     status).
>>     +
>>     +  * Once the RFC reaches consensus, update the CMake toolchain
>>     version checks
>>     +    and this document. We want to soft-error when developers
>>     compile LLVM. We
>>     +    say "soft-error" because the error can be turned into a
>>     warning using a
>>     +    CMake flag. This is an important step: LLVM still doesn't
>>     have code which
>>     +    requires the new toolchains, but it soon will. If you
>>     compile LLVM but don't
>>     +    read the mailing list, we should tell you!
>>     +
>>     +  * Ensure that at least one LLVM release has had this
>>     soft-error. Not all
>>     +    developers compile LLVM tip-of-tree. These release-bound
>>     developers should
>>     +    also be told about upcoming changes.
>>     +
>>     +  * Turn the soft-error into a hard-error after said LLVM
>>     release has branched.
>>     +
>>     +  * Update the :doc:`coding standards<CodingStandards>` to
>>     explicitly allow the
>>     +    new features we've now unlocked.
>>     +
>>     +  * Start using the new features in LLVM's codebase.
>>
>>     Thanks,
>>
>>     JF
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190117/beab25b8/attachment.html>