[webkit-dev] C++17 is here. Should we use it?

[Michael Catanzaro]

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 
https://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