[Development] Switching Qt default builds to C++20 where supported

[Thiago Macieira]

On Monday 14 October 2024 06:13:49 GMT-7 Giuseppe D'Angelo via Development 
wrote:
> Do you foresee any problems at actually guaranteeing that we still work 
> with C++17, should one force the C++ version (via whatever means)?
> I mean, we have to keep work in C++17 anyhow (for some toolchains), 
> what's the harm at saying that Qt actually works everywhere that way?

I don't think we need to guarantee that it works for anybody but us, for the 
platforms where C++20 is available. So "if it passes the CI, it's good 
enough".

> Is it an implementation concern, or e.g. because by default the CI won't 
> test it anymore (will test in C++20), or...?

My proposal is that we do build all tests in C++17 mode on Linux. We don't 
necessarily have to run them, though. That will exercise the Unix code paths 
in C++17 mode and all headers.will be tested in all platforms too.

> (Indeed testing is especially tricky. Do we run the full autotest suite 
> on those platforms that won't get C++20 by default? Should we still keep 
> C++17 coverage around on at least one platform, say, Linux?)

Yes if they run tests now. I know QNX and INTEGRITY do, but I am unsure 
whether VxWorks testing is enabled yet.

> Right now that includes, for instance, libstdc++, which still marks 
> C++20 and later as experimental, and can break API/ABI at will.

Indeed, which means we need to know what of it, if anything, we can use in our 
ABI. I have one item I want and I've emailed Ville asking if that one is ABI-
stone already.

> So, what happens to us if libstdc++ breaks (for instance) ABI in some 
> std::format utility?

Bad things. But that's no different from std::filesystem breakage if we hadn't 
been careful.

> What about the qt-configure-module script? Is it going to inherit 
> qtbase's settings?

I'd prefer not to, but Alexandru convinced me it's a useful thing to have in 
the change review above. It'll be an overridable CMake setting, so all modules 
inherit qtbase's setting as their default.

> Same question as above: given the C++20 code would still need some sort 
> of protection (feature macros, QT_CONFIG, whatever) because it needs to 
> build on the C++17 platforms, what's the harm at keeping C++17 "working" 
> everywhere?

Extra effort and CI time. If we're not going to allow users to use that, why 
should we spend valuable CI cycles in it? Especially for platforms we don't 
have enough of, like Apple ones.

> Effectively, I don't see much difference from the current situation, 
> where we "pretend" that we require C++17 but in reality we just check 
> that we can pass `-std=c++17` to the compiler. Any usage in Qt code of 
> individual language/library features still requires protection, because 
> they're not universally implemented.

Indeed, except that it will be -std=c++20.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Platform & System Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20241014/ab2376ff/attachment.bin>