[llvm-dev] Using C++14 code in LLVM (original) (raw)

André Jansen Medeiros Villar via llvm-dev llvm-dev at lists.llvm.org
Fri Nov 10 17:07:21 PST 2017

Given that no policy existed before the adoption of it should include a grace period. So it should read:

2017-11-01 14:24 GMT-02:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>:

On Tue, Oct 31, 2017 at 11:23 PM Zachary Turner <zturner at google.com> wrote:

I’m ok with that, but the reason I’m pushing is because there is no clear plan of action. Even if the plan of action is “When X happens, we can enable C++14”, that’s fine too. I just want to know, concretely, what is X.

We should either be able to say never or give a reasonable set of conditions that would enable a switch. All I’ve seen though is “it’s hard” which just means I’m going to ask again next year, and the year after, etc due to lack of clear guidance. To address your point though , this isn’t really about building everything with clang. You don’t need to bootstrap Clang to build a hypothetical C++17 enabled LLVM, you could also bootstrap a more modern version of GCC. This is really more fundamentally about “Can we have a clearly defined policy about how often we can bump the minimum compiler version, like we have for MSVC?” To make this even more concrete, let me offer a proposal: * We can bump the minimum required non-Microsoft toolchain version every 4 years. Having something written like this allows us to have a schedule, and having a schedule allows downstream consumers to plan upgrades as needed so as to minimize disruption. 4 years is also a pretty reasonable amount of time IMO, but we can certainly discuss the exact value of N. I haven't said anything here about what it can be bumped to. But in the interest of making progress, I'm separating the decisions out into smaller pieces so we can focus on one thing at a time.

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/20171110/af0c05e4/attachment.html>

More information about the llvm-dev mailing list