C++17 is here. Should we use it?

# JF Bastien (2 years ago)

Hello WebKilters,

Our Chrome-y friends are considering the use of C++14 groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ. I have to say that C++14 in WebKit has been quite amazing, and we should consider using C++17: it has many wonderful new things tvaneerd/cpp17_in_TTs/blob/master/ALL_IN_ONE.md, some of which we already use through WTF’s re-implementation of library features. By now (table as witness en.cppreference.com/w/cpp/compiler_support) most C++17 languages features are in clang and GCC, and MSVC isn’t doing too bad either. Language things can just come through WTF if we really want them.

So how about it?

JF

Contact us to advertise here
# Yusuke SUZUKI (2 years ago)

I really like C++17, if with initializer is super great. Awesome constexpr lambda and if. And std::optional and std::variant...

However, IIRC, WebKitGTK+ needs to support some old compilers. The current GCC support is 5.0.0, which is recently upgraded. bugs.webkit.org/show_bug.cgi?id=174155

Possibly, mcatanzaro and clopez know much about WebKitGTK+ compiler dependencies.

# Michael Catanzaro (2 years ago)

On Fri, Aug 4, 2017 at 3:48 PM, Yusuke SUZUKI <utatane.tea at gmail.com>

wrote:

Possibly, mcatanzaro and clopez know much about WebKitGTK+ compiler dependencies.

As a result of the C++14 discussion on this list a few months ago, we relaxed our dependencies policy [1] to allow upgrading to GCC 5 one year earlier than planned, to the displeasure of some of our distributors who now have to build a custom compiler as part of their WebKit builds. We would prefer not to relax the policy further.

Our current schedule looks like:

  • GCC 6 could be required in April 2018 (next Ubuntu LTS release)
  • GCC 7 (required for C++17) could be required likely late in 2019 (next Debian stable release)

Is that acceptable for Apple?

Michael

[1] trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy

# JF Bastien (a year ago)

Hello again WebKitten!

April 2018 is fast approaching, which means that we might be able to require GCC 6 and all the great C++17 features that’ll come with it. So what say you? From C++17 it looks like we wouldn’t get quite a few things, but we’d be able to use a few nice things (see the table en.cppreference.com/w/cpp/compiler_support).

JF

# Michael Catanzaro (a year ago)

On Fri, Mar 23, 2018 at 4:32 PM, JF Bastien <jfbastien at apple.com> wrote:

Hello again WebKitten!

April 2018 is fast approaching, which means that we might be able to require GCC 6 and all the great C++17 features that’ll come with it. So what say you? From C++17 it looks like we wouldn’t get quite a few things, but we’d be able to use a few nice things (see the table).

JF

Hi,

I've been asking around, and it sounds like this will be a significant inconvenience for some Igalia projects where upgrading the compiler is a bit difficult, but everyone agrees the time specified in the dependencies policy (the next Ubuntu LTS release) is fast approaching, and that the policy is a good compromise. It looks like the next Ubuntu release is due on April 26 [1], one month from today, so we should be good to require GCC 6 at that time. Sound good?

Michael

[1] wiki.ubuntu.com/BionicBeaver/ReleaseSchedule

# JF Bastien (a year ago)

On Mar 26, 2018, at 07:38, Michael Catanzaro <mcatanzaro at igalia.com> wrote:

On Fri, Mar 23, 2018 at 4:32 PM, JF Bastien <jfbastien at apple.com> wrote:

Hello again WebKitten!

April 2018 is fast approaching, which means that we might be able to require GCC 6 and all the great C++17 features that´ll come with it. So what say you? From C++17 it looks like we wouldn´t get quite a few things, but we´d be able to use a few nice things (see the table en.cppreference.com/w/cpp/compiler_support).

JF

Hi,

I've been asking around, and it sounds like this will be a significant inconvenience for some Igalia projects where upgrading the compiler is a bit difficult, but everyone agrees the time specified in the dependencies policy (the next Ubuntu LTS release) is fast approaching, and that the policy is a good compromise. It looks like the next Ubuntu release is due on April 26 [1], one month from today, so we should be good to require GCC 6 at that time. Sound good?

Michael

[1] wiki.ubuntu.com/BionicBeaver/ReleaseSchedule, wiki.ubuntu.com/BionicBeaver/ReleaseSchedule

Thanks! I’d be very happy to bring a few new features in! Let’s see if anyone else wants to chime in by then :-)

# Alex Christensen (2 months ago)

It’s always fun to reply to two year old emails.

I would like to have a plan to start using and requiring C++17 in WebKit. Based on my minimal research, I believe that DebianBuster is frozen but not yet released. Is there something we are still waiting for, or could we begin making the switch?

# Alex Christensen (2 months ago)

I’m interpreting the lack of objection to mean there is no reason not to proceed with bugs.webkit.org/show_bug.cgi?id=197131 once I get everything working nicely.

# Konstantin Tokarev (2 months ago)

20.04.2019, 01:16, "Alex Christensen" <achristensen at apple.com>:

It’s always fun to reply to two year old emails.

I would like to have a plan to start using and requiring C++17 in WebKit. Based on my minimal research, I believe that DebianBuster is frozen but not yet released. Is there something we are still waiting for, or could we begin making the switch?

[1] says: "we support each major Debian version until one year after the release of the next major version"

Given that Buster is not released yet, bumping GCC requirement to 7 seems to be premature.

OTOH, GCC 6 has partial support of C++17 [2,3] under -std=c++1z, which might be sufficient for now.

[1] trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy [2] gcc.gnu.org/projects/cxx-status.html#cxx17 [3] gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017

# Michael Catanzaro (2 months ago)

On Tue, Apr 23, 2019 at 10:50 AM, Konstantin Tokarev

<annulen at yandex.ru> wrote:

[1] says: "we support each major Debian version until one year after the release of the next major version"

Given that Buster is not released yet, bumping GCC requirement to 7 seems to be premature.

The dependencies policy states that toolchains are only supported until the release of the next major version, but yes, the Debian Buster release has not happened yet and is likely still several months away.

Still, it's been two weeks since Alex proposed to require GCC 7, and no objections have been posted to this list. After talking with Berto, I've confirmed that Debian is OK with building packages with Clang if need be, and if it works for Debian it should work for Ubuntu as well. So instead of requiring that WebKit build with the default system compiler, we can just require that it build with some system compiler.

We do need to support the distro's libstdc++ for the full year after the next release, though, as otherwise it won't be possible for the distros to continue to update WebKit. The current policy language regarding toolchains does not account for that. So I'd like to simplify this by saying that we support some system compiler for one year after the release of the next major version, but not necessarily the default system compiler.

My proposed changes to trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy are:

Keep:

""" Our dependencies policy is simple:

  • We support each major Debian version until one year after the release of the next major version.
  • We support each Ubuntu LTS until one year after the release of the next Ubuntu LTS. """

Then replace all the rest with:

""" During the support period, we intend for WebKit to remain buildable on these distributions using some system-provided compiler, not necessarily the default system compiler, and with the default system libstdc++. The purpose of this policy is to ensure distributions can provide updated versions of WebKit during the support period to ensure users receive security updates. """

Now, those changes would imply that we can require GCC 7 now, but not yet libstdc++ 7, since the policy would normally require that we continue supporting Debian Stretch for another year. But we can make a one-time decision to ignore that, because Stretch isn't receiving WebKit security updates, so it doesn't really matter. Now, good news: Debian Buster will be the first version to receive WebKit updates, thanks to our promises of stable dependencies and Ubuntu's success with providing WebKit updates during the last two years. The goal of providing security updates to Debian will fail if we drop support for Debian's libstdc++ within their primary security support period (one year after release of the next version), though; that would be a major setback. So my proposed change makes it easier to increase our GCC requirement (if the old distros can build with old clang, then we can do it), but harder to increase our libstdc++ requirement (need to wait one additional year to do so).

The proposed future would look like this:

  • Imminently: require GCC 7 and libstdc++ 7
  • April 2021: require libstdc++ 8 (one year after Ubuntu 20.04 release)
  • Late 2021 or early 2022: require libstdc++ 9 (one year after the successor to Debian Buster is released)

Then we can require new GCCs whenever we want, as long as the old clangs suffice. Ubuntu 18.04 has clang 6.0, for instance, so as long as clang 6.0 works, then we can advance to GCC 8 whenever desired. Debian Buster has clang 7.0, so come April 2021 we'd be able to require that. But one of the system compilers would need to work for the full three years. Then the long support period for libstdc++ is required to make sure our users don't get cut off from security updates. There's no way around that: if we want to require newer standard libraries, then our users will no longer receive updates, period.

Is this OK?

OTOH, GCC 6 has partial support of C++17 [2,3] under -std=c++1z, which might be sufficient for now.

Beware that GCC 9, released yesterday, is the first version in which C++ 17 support is no longer experimental. Most things should work in GCC/libstdc++ 7, but as always, there's going to be bugs that we're going to have to live with.

Michael

# Michael Catanzaro (2 months ago)

Since there were no objections, I've updated the policy on the wiki:

trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy, trac.webkit.org/wiki/WebKitGTK/GCCRequirement

Michael

# Konstantin Tokarev (2 months ago)

07.05.2019, 16:53, "Michael Catanzaro" <mcatanzaro at igalia.com>:

Since there were no objections, I've updated the policy on the wiki:

trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy, trac.webkit.org/wiki/WebKitGTK/GCCRequirement

Note that since we have to support libstdc++ 6.x, most of C++17 standard library features () should be disallowed. Those include std::filesystem, std::string_view, etc. Core language features should be fine.

# Alex Christensen (2 months ago)

If you have a minimum-requirements system that you want to keep building, put build infrastructure on build.webkit.org so we can see when things break.

We plan to actively push to update requirements again in 2021.

# Michael Catanzaro (2 months ago)

On Tue, May 7, 2019 at 1:53 PM, Alex Christensen

<achristensen at apple.com> wrote:

If you have a minimum-requirements system that you want to keep building, put build infrastructure on build.webkit.org so we can see when things break.

We already have stable release bots to test the lowest-supported configurations, but most developers should only ever need to worry about EWS, as always.

Michael

# Michael Catanzaro (2 months ago)

On Tue, May 7, 2019 at 1:46 PM, Konstantin Tokarev <annulen at yandex.ru>

wrote:

Note that since we have to support libstdc++ 6.x, most of C++17 standard library features () should be disallowed. Those include std::filesystem, std::string_view, etc. Core language features should be fine.

With my suggested one-time exception to drop support for Debian Stretch early due to lack of security updates there, I think it's perfectly fine to require libstdc++ 7 now. Igalia's EWS and stable release bots might need to be updated, but this is not a problem.

Michael

# Yusuke Suzuki (2 months ago)

Cool! So,

  1. We can use GCC 7
  2. We can use libstdc++7

Is my understanding correct? Basically, this means that we can use cool C++17 features super aggressively :)

Best

# Konstantin Tokarev (2 months ago)

11.05.2019, 02:47, "Yusuke Suzuki" <ysuzuki at apple.com>:

Cool! So,

  1. We can use GCC 7
  2. We can use libstdc++7

Is my understanding correct? Basically, this means that we can use cool C++17 features super aggressively :)

Not so aggressively with library features, a few of them require libstdc++ 8 or even 9[1]. However, there is portable implementation of std::filesystem [2] which we could use as a "polyfill" if needed.

[1] gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017 [2] gulrak/filesystem

# Michael Catanzaro (2 months ago)

On Fri, May 10, 2019 at 6:47 PM, Yusuke Suzuki <ysuzuki at apple.com>

wrote:

  1. We can use GCC 7
  2. We can use libstdc++7

Is my understanding correct? Basically, this means that we can use cool C++17 features super aggressively :)

I would say you can use cool C++ 17 features cautiously, enjoying those features when they work, and expecting the possibility of libstdc++7 bugs causing them to not work.

I think our EWS bots are not yet on GCC 7, but that should be addressed soon.

Michael

# Sam Weinig (11 days ago)

Did we ever land on conclusion here?

I tried to use c++17 structured bindings (see bugs.webkit.org/show_bug.cgi?id=198905) and it looks like most of the EWS bots are ok with it, but the jsc-mips and jsc-armv7 bots are not into it. Looking at the output, it seems like those bots may still be using GCC 6.4.0 (but I could be wrong here).

If the issue is getting these bots updated, can we do that? Are there any other bots that might need updating as well?

# Michael Catanzaro (10 days ago)

Alex already switched all WebKit ports to building with C++17 enabled in bugs.webkit.org/show_bug.cgi?id=197131.

On Sun, Jun 16, 2019 at 8:25 PM, Sam Weinig <weinig at apple.com> wrote:

If the issue is getting these bots updated, can we do that? Are there any other bots that might need updating as well?

We've previously agreed that we can increase the GCC version limit to GCC 7, but nobody ever implemented this. Reported bugs.webkit.org/show_bug.cgi?id=198914.

The easiest way to sniff out which bots should be upgraded is to just land the change and see which bots break. But I'll ask internally to ensure all remaining Igalia bots are upgraded to GCC 7 soon.

Be aware that while GCC 7 has basic support for structured bindings, there are limitations documented at gcc.gnu.org/projects/cxx-status.html which are not supported until GCC 8.

Michael

# Guillaume Emont (10 days ago)

Quoting Sam Weinig (2019-06-17 03:25:15)

Did we ever land on conclusion here?

I tried to use c++17 structured bindings (see bugs.webkit.org/show_bug.cgi?id=198905) and it looks like most of the EWS bots are ok with it, but the jsc-mips and jsc-armv7 bots are not into it. Looking at the output, it seems like those bots may still be using GCC 6.4.0 (but I could be wrong here).

If the issue is getting these bots updated, can we do that? Are there any other bots that might need updating as well?

Sorry, yes indeed, jsc-mips and jsc-armv7 still use an old gcc. I've been working on updating this but got sidetracked. This is now on top of my priority list for this week. Thank you for your patience.

Guillaume

# Sam Weinig (10 days ago)

On Jun 17, 2019, at 8:45 AM, Guillaume Emont <guijemont at igalia.com> wrote:

Quoting Sam Weinig (2019-06-17 03:25:15)

Did we ever land on conclusion here?

I tried to use c++17 structured bindings (see bugs.webkit.org/show_bug.cgi?id=198905, bugs.webkit.org/show_bug.cgi?id=198905) and it looks like most of the EWS bots are ok with it, but the jsc-mips and jsc-armv7 bots are not into it. Looking at the output, it seems like those bots may still be using GCC 6.4.0 (but I could be wrong here).

If the issue is getting these bots updated, can we do that? Are there any other bots that might need updating as well?

Sorry, yes indeed, jsc-mips and jsc-armv7 still use an old gcc. I've been working on updating this but got sidetracked. This is now on top of my priority list for this week. Thank you for your patience.

Guillaume

Thanks Guillaume.

# Guillaume Emont (3 days ago)

Quoting Sam Weinig (2019-06-17 03:25:15)

Did we ever land on conclusion here?

I tried to use c++17 structured bindings (see bugs.webkit.org/show_bug.cgi?id=198905) and it looks like most of the EWS bots are ok with it, but the jsc-mips and jsc-armv7 bots are not into it. Looking at the output, it seems like those bots may still be using GCC 6.4.0 (but I could be wrong here).

If the issue is getting these bots updated, can we do that? Are there any other bots that might need updating as well?

The jsc-mips and jsc-armv7 EWS bots, as well as the corresponding buildbots have been updated. They now use gcc 8.3.0. The armv7 softfp ABI buildbot[1] still needs updating, but there is no corresponding EWS. I hope to have that last update done during the week.

# Guillaume Emont (a day ago)

Quoting Guillaume Emont (2019-06-24 19:03:53)

Quoting Sam Weinig (2019-06-17 03:25:15)

Did we ever land on conclusion here?

I tried to use c++17 structured bindings (see bugs.webkit.org/show_bug.cgi?id=198905) and it looks like most of the EWS bots are ok with it, but the jsc-mips and jsc-armv7 bots are not into it. Looking at the output, it seems like those bots may still be using GCC 6.4.0 (but I could be wrong here).

If the issue is getting these bots updated, can we do that? Are there any other bots that might need updating as well?

The jsc-mips and jsc-armv7 EWS bots, as well as the corresponding buildbots have been updated. They now use gcc 8.3.0. The armv7 softfp ABI buildbot[1] still needs updating, but there is no corresponding EWS. I hope to have that last update done during the week.

The update of the last bot has now been done. Also, forgot the address[1] of the bot in my previous email:

[1] build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Thumb2%20SoftFP%20Release

Want more features?

Request early access to our private beta of readable email premium.