Compiler baselines (was: [Libreoffice-qa] minutes of ESC call ...)

[Stephan Bergmann]

[fuck gmail; this was meant to go to libreoffice at lists.freedesktop.org 
not libreoffice-qa at lists.freedesktop.org]


-------- Forwarded Message --------
Subject: Compiler baselines (was: [Libreoffice-qa] minutes of ESC call ...)
Date: Tue, 24 Jul 2018 12:28:21 +0200
From: Stephan Bergmann <sbergman at redhat.com>
To: libreoffice-qa at lists.freedesktop.org

On 19/07/18 16:50, Michael Meeks wrote:
> * GCC 4.8 support no longer needed for master by City of Munich (Michael W)
>      + prolly the only ones still using this vs. master.
>      + 6.1 is the last one built for Ubuntu 14.04
>      + new base-line is Ubuntu 18.04
>          + gcc 7
>      + would also require bumping base-line on TDF linux builds (Christian)
>      + ideally wait for Stephan (Michael)
>      + this may help wrt. C++ features, the VS 2017 upgrade didn’t much (Miklos)
>          + due to older gcc baseline.
>      + CentOS6 – continues until 2020, CentOS 7 til 2024 (Christian)
>      + would like to build more KDE on a newer baseline (Thorsten)
>      => when Stephan is back.

So what would we gain re C++11/14/17 support if we bump the current 
master (towards LO 6.2) Linux GCC baseline from 4.8.1 to, say, 7?

One limiting factor is MSVC, where---IIUC---our current baseline is VS 
2017 15.0 (aka 19.10), but many features are only available in later 
15.x (aka 19.y), see 
<https://en.cppreference.com/w/cpp/compiler_support>.  Is there any good 
reason to stick with an older version of VS 2017, or could we require 
the latest version (which appears to be 15.7 aka 19.14) or at least the 
second-latest one (15.6 aka 19.13)?

According to the feature matrix at 
<https://en.cppreference.com/w/cpp/compiler_support>, bumping to GCC 7 
and MSVC 2017 15.7 would give us almost complete C++17 support, which 
would of course be a great step forward.  Staying at MSVC 2017 15.0 
would limit that substantially.  (Clang has never been a limiting factor 
in recent years.  I didn't check now, but would assume that our 
macOS/Xcode baseline is recent enough to provide all the features.)

As an example, the relevant feature-test macros we currently have in 
config_host/config_global.h.in would be satisfied as follows:

* HAVE_CXX14_CONSTEXPR: yes (GCC 5, Clang 3.4, MSVC 19.10, "Extended 
constexpr" at <https://en.cppreference.com/w/cpp/compiler_support#cpp14>).

* HAVE_GCC_PRAGMA_OPERATOR: yes (GCC 4.3, Clang, MSVC 19.0, "C99 
preprocessor" at 
<https://en.cppreference.com/w/cpp/compiler_support#cpp11>; so this 
should already be satisfied today).

* HAVE_GCC_DEPRECATED_MESSAGE: yes (GCC 4.9, Clang 3.4, MSVC 19.0, 
"[[deprecated]] attribute" at 
<https://en.cppreference.com/w/cpp/compiler_support#cpp14>).

* HAVE_BROKEN_CONST_ITERATORS: yes (see "We should be able to drop the 
below check when bumping the GCC baseline to 4.9 [...]" in configure.ac).

* HAVE_GCC_ATTRIBUTE_WARN_UNUSED: yes, if we don't stick to MSVC 15.0 
(GCC 7, Clang 3.9, MSVC 19.11, "[[nodiscard]] attribute" at 
<https://en.cppreference.com/w/cpp/compiler_support#cpp17>).

* HAVE_CPP_GUARANTEED_COPY_ELISION: yes, if we don't stick to MSVC 15.0 
(GCC 7, Clang 4, MSVC 19.13, "Guaranteed copy elision" at 
<https://en.cppreference.com/w/cpp/compiler_support#cpp17>).

(And we would get rid of the nuisance that GCC 4.8 still required an 
explicit

   return OUString("foo")

instead of just

   return "foo";

.)

For the TDF Linux builds on CentOS 6 with Developer Toolset (where we 
currently use Deverloper Toolset 2 with GCC 4.8.2, IIUC), my 
understanding would be that Developer Toolset 7 with GCC 7 should be 
available to use instead (searching the web I found 
<https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/>)?