Re: [Development] Let's drop MSVC 2019 for dev (6.8)
Thiago Macieira wrote in news:2865734.Ex9A2HvPv6@tjmaciei-mobl5: > * because our builds are labelled "msvc2019" Does the label reflect the compiler used? (I know 2019 and 2022 are binary compatible.) I haven't bothered to build the most recent 5.15.x open source version, but back at 5.15.10, qtwebengine builds would get compile errors with VC2022. It was just a few #includes needed in a few routines, but painful given how many hours the build would require. All source code I've needed to work on recently is now on Qt6 and 2022, so I guess I personally don't care if you drop 2019. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] What's our policy on changing the result of qHash(T, 0) between major releases?
Requirement: the qHash function in question is and has always been out-of- line. We obviously can't change the hashing function of inline code, because it may have been inlined. When the seed is non-zero, we make no guarantees on what the result will be. The result is allowed to change between Qt versions and between machines, even for the same seed. Strictly speaking, you're not supposed to pass replay a seed, because some hash functions have a hidden seed you can't get or set. But what about a zero seed? It's what we call a "deterministic hashing". We have changed the algorithms on .0 releases (in both 5.0 and 6.0 for QString). The reason I'm asking is that right now qHash(QLatin1StringView(str)) == qHash(QByteArrayView(str)) but it would be far more useful to have qHash(QLatin1StringView(str)) == qHash(QString(str)) I've made the change for the non-zero seeds, but one couldn't rely on the above unless it applied for every seed.f -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On Tuesday, 2 May 2023 17:39:01 PST Thiago Macieira wrote: > I don't have access to QNX and INTEGRITY toolchain information, so I'd like > to request that they simply match the feature list above, with minimal > workarounds. What's the current state for those, for supporting Qt 6.8 or 6.9? We have VxWorks coming in and I'd like it to meet a higher minimum bar than "legacy". That is, I'd like VxWorks to require a C++20-compliant compiler before being enabled in our CI, but that's only fair if we have a line-of- sight to bringing everyone to C++20. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] About the timeline and phases to support C++20 with and in Qt
On Wednesday, 21 December 2022 09:51:52 PST Vladimir Minenko via Development wrote: > We got four user stories on Qt Bug Reports: > > 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360 > 2. C++20 is required for the development of Qt itself - > https://bugreports.qt.io/browse/QTBUG-109361 > 3. C++20 is mandatory for users of Qt - > https://bugreports.qt.io/browse/QTBUG-109362 Those tasks haven't got any updates recently. What's the status? I'd like to ask that we go to #3 for 6.8 or 6.9. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Let's drop MSVC 2019 for dev (6.8)
The compiler is pretty buggy and has several, unfixed conformance issues with C++. One year ago I asked on the interest mailing list about using a non-latest MSVC: https://lists.qt-project.org/pipermail/interest/2023-January/038859.html The reasons reported for not going to the next were: * regression in a newer version that MS hadn't fixed * cost: they may have bought version X but not Y (yet) * cost: re-certifying the entire tool environment * because the associated tools (IDE) have other problems (UX) * inertia * because our builds are labelled "msvc2019" My conclusion then was that we could drop the older one, but our policy should be to support an X-1 version of MSVC for as long as practicable, a minimum of a few years. Well, in April this year, MSVC 2019 will be 5 years old, though fortunately it's still getting updates. Considering MSVC 2022 will be 3.5 at that time, I think it's time to drop. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
