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

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
<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190116/21cb8eef/attachment.html>

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>

Yep, that sounds like a clear expression of the discussed policy, indeed.

+1 to both the policy and to the phrasing.

On Wed, Jan 16, 2019 at 6:35 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> 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/751ea785/attachment.html>

Strong +1 on the process, I really do think it captures both the desire to
have *some* time input so we don't grow ever more stale, *and* the desire
to upgrade for a reason and with a clear understanding of the cost/benefit
to users.

On Wed, Jan 16, 2019 at 3:35 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> 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/20190117/eb793d25/attachment.html>

On 16/01/2019 23:35, 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.
I recall similar discussions about updating the required CMake version.

Should something be said about build requirements other than the 
compiler, or is that out of scope?

Thanks,

Stephen.

+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.

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
> 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/fea47c41/attachment-0001.html>

On Thu, Jan 17, 2019 at 1:49 AM Jonas Toth via llvm-dev <
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 listllvm-dev at
lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> 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/20190117/0060b85e/attachment.html>

> On Jan 17, 2019, at 1:11 AM, Stephen Kelly via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 16/01/2019 23:35, 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.
> 
> I recall similar discussions about updating the required CMake version.
> 
> Should something be said about build requirements other than the compiler,
or is that out of scope?
It’s definitely in scope of the developer policy, but out of scope for my
proposal. Good follow-up discussion to have.

> Thanks,
> 
> Stephen.
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Wed, Jan 16, 2019 at 3:35 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
>
This policy looks great to me!

Thanks for putting this together.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190117/c69d79b7/attachment.html>

This policy LGTM, great job JF.  Assuming no objections in the next couple days,
please feel free to land it.

-Chris
> On Jan 16, 2019, at 3:35 PM, JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org> 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
<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
<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/20190117/9d4769f0/attachment.html>