[Development] Are we already allowed to use C++17 in dev?

[Olivier Goffart]

On 2020-01-08 23:50, Thiago Macieira wrote:
> On Wednesday, 8 January 2020 14:12:17 PST Olivier Goffart wrote:
>> On 08.01.20 18:21, Thiago Macieira wrote:
>>> qcc doesn't seem to support it.
>>>
>>>    kernel/qcoreapplication.cpp: In static member function 'static void
>>
>> Not yet:
>>
>> - qmake isn't build with -std=c++17 yet, so you can't have C++17 in the
>> files used by the boostrap lib. (.cpp or .h)
> 
> qcoreapplication.cpp is not part of the bootstrap, so it's never included in
> qmake.
> 
>> - examples and tests are not yet build with C++17 by default
> 
> Not my case.

Right, I was replying in general, not for your particular case.

> 
>> - We still build for MacOS 10.13 which do not support the C++17 stdlib
> 
> Same solution as the current problem. Just remove that OS/compiler.
> 
>> But the CI would still fail because it still runs with MacOS 10.13
>> and we don't want running the test with MacOS 10.13 just yet because tests
>> are not run on MacOS 10.14 because they are failling:
>>
>> https://codereview.qt-project.org/c/qt/qt5/+/284310
>>
>> https://bugreports.qt.io/browse/QTQAINFRA-3108
>> https://bugreports.qt.io/browse/QTBUG-75786
>>
>> IMHO, these two issues should be P0 because if we are serious about using
>> C++17 fir Qt6, we should be able to do it now. This has been a blocker for
>> months. If some tests are can't be fixed on MacOs 10.14, they should then
>> be blacklisted so we can still proceed with C++17.
> 
> I might regret asking this, but how is our macOS 10.15 support now?
> 
>> And this issue you have in
>> "LinuxRHEL_7_6x86_64QNXQNX_700armv7GCCqtci-linux-RHEL-7.6", is maybe
>> something else. (Maybe
>> https://codereview.qt-project.org/c/qt/qtbase/+/283832 fixes it, maybe not)
> 
> It doesn't.

Well it might, since this patch forces the use of C++17 everywhere, regardless 
of the configure test. which i believe is the problem.

> 
> Anyway, you made me actually look at why this compiler isn't compiling my
> C++17 code. That's because C++17 failed in configure:
> 
> Checking for C++17 support...
> [...]
>> main.cpp:8:19: fatal error: variant: No such file or directory
> 
> #include <variant> was added in 5b6eb8e247d246a28bdc8ce533c52d7647a44a90
> (5.12) to work around the macOS 10.13 issue. So when we boot macOS 10.13 from
> the CI, we can remove the #include and allow this compiler to pass detection
> as C++17-capable.
> 
> Note how our requirement of C++17 does not extend to the Standard Library.
> 
> Or we declare that <variant> is required and boot this compiler from the CI
> too. I don't care which is preferred.
> 
> Third option is to upgrade the compiler for QNX to a more recent version. Is
> there one that is C++17 Standard Library compliant? I thought QNX was going to
> change to libc++ so this shouldn't be a problem.
> 

It would be nice to be able to use the std library if possible. If only for 
things like std::optional.

-- 
Olivier