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:
Require GCC 5.1 and LLVM 3.5 at a minimum
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.
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:
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.
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.
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.
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.
