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

[Philip Reames via llvm-dev]

This seems generally quite reasonable to me.  +1

I reserve the right to object to any particular RFC under the proposed 
process of course.  :)

On 1/16/19 3:35 PM, JF Bastien via llvm-dev wrote:
> 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
> 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/20190116/ecb917ac/attachment.html>