Re: [Development] Let's drop MSVC 2019 for dev (6.8)
On Tuesday, 6 February 2024 06:57:34 CET Jani Heikkinen via Development wrote: > > How about instead we drop at an LTS+2 release? The next one is actually > > 6.7. > We can't switch this in 6.7 at this point anymore; we don't have packages > for MSVC2022 at the moment and doing this (adding new packages + removing > ones) change this late of process is too risky > Could you please switch packaging to msvc2022 in dev then, so we don\t have this discussion and excuse yet again in 6 months? Br Allan -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Let's drop MSVC 2019 for dev (6.8)
> > How about instead we drop at an LTS+2 release? The next one is actually 6.7. > We can't switch this in 6.7 at this point anymore; we don't have packages for MSVC2022 at the moment and doing this (adding new packages + removing ones) change this late of process is too risky br, Jani -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's our policy on changing the result of qHash(T, 0) between major releases?
On Monday, 5 February 2024 01:36:39 PST Marc Mutz via Development wrote: > I've always understood it such that we as Qt must preserve the property > that the hash for equal elements is equal within _one_ run of _one_ > process. This means you can use the hash in I/O in any way. That's why > we have qt_hash, which you _can_ (and do) use in I/O (but is private > API, AFAIK). I never thought that a hash seed of zero would change that, > but of course users may have come to depend on this (Hyrum's Law), so a > [ChangeLog] would be in order. In commit e3f05981cbeb0b7721f960ef88effa77be2af5ce, I added this comment to qHashBits: // mix in the length as a secondary seed. For seed == 0, seed2 must be // size, to match what we used to do prior to Qt 6.2. Which is why I am asking now, because making this change would go against that comment. But there was no discussion in the change about whether this was correct or not. It seems I just write it like that. However, that was qHashBits(). The change I'm talking about is qHash(QLatin1StringView), specifically so it won't call qHashBits(). -- 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] Let's drop MSVC 2019 for dev (6.8)
On Monday, 5 February 2024 01:39:47 PST Marc Mutz via Development wrote: > I think we don't drop supported compilers, except in LTS+1 releases (6.9 > being the next). I would advise you drop it before the LTS, so you don't have to keep supporting it for however long your LTS cycle is. How about instead we drop at an LTS+2 release? The next one is actually 6.7. -- 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] Monthly CI maintenance break - February (Mon, Feb 5th 2024)
This is DONE From: Development on behalf of CI Maintenance Break via Development Sent: Monday, February 5, 2024 6:03 AM To: development@qt-project.org Subject: Re: [Development] Monthly CI maintenance break - February (Mon, Feb 5th 2024) This starts NOW From: CI Maintenance Break Sent: Monday, January 29, 2024 8:33 AM To: development@qt-project.org Subject: Monthly CI maintenance break - February (Mon, Feb 5th 2024) Hi, We’ll have our scheduled maintenance break on next Monday (5th of February). We’ll begin our work at 6:00 UTC and you can prepare for 6 hours of CI not working. -- 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
From what I see, the open questions from the thread in May are still: - (paraphrasing Ville) which C++ 20 features are worth breaking (primarily embedded) users who want new Qt version but don’t yet have the compilers that can give them these facilities? https://lists.qt-project.org/pipermail/development/2023-May/043887.html And the perspective here needs to be the users of Qt. In Qt, we can often work around missing facilities, if there is a real benefit in doing so. But as long as users can use a more recent C++ language standard for their code without being hobbled by Qt, the list of C++20 features that really would make a difference for Qt users seems to negligible. From what I see, we are years away from doing anything useful with modules and co-routines, as the two biggest items that users of Qt would be interested in and ask about. Have we done any work on any of those, beyond Ville’s work on senders & receivers? Concepts would be very useful, also for Qt users, because a library of concepts could be useful for users when they create their own APIs; and because it would allow us to comprehensibly document the requirements for our own templates (today we often hide the std::enable_if’ery from documentation, and don’t always provide equivalent information about the requirements to the types used in our templates). We can perhaps start with that as a documentation feature (qdoc can use libclang with whatever C++ standard it wants). - which C++ standard do the oldest versions of gcc and clang we support default to (the gcc devs at least strongly advising against explicitly raising the language version from the default) https://lists.qt-project.org/pipermail/development/2023-May/043915.html https://gcc.gnu.org/projects/cxx-status.html still documents C++20 as experimental, and C++17 as the default. Volker On 5 Feb 2024, at 10:57, Alex Blasche via Development wrote: Hi, For Qt 6.8 we continue to work on Phase 1 item https://bugreports.qt.io/browse/QTBUG-109360. In other words we will not mandate C++20 compilers in Qt 6.8 yet. An LTS release is not the right for such a breaking change anyway. The possible releases for such a drastic change are 6.9 or 6.12 (releases immediately following an LTS release). Note that I am not cofirming those releases but merely point out which type of releases could be potential options. Considering the track record we have when getting Phase 1 items into the release and considering existing customer concerns I have a hard time believing that 6.9 is a serious option. This is my personal opinion. -- Alex From: Development on behalf of Thiago Macieira Sent: Saturday, 3 February 2024 18:13 To: development@qt-project.org Subject: 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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- 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
Hi, For Qt 6.8 we continue to work on Phase 1 item https://bugreports.qt.io/browse/QTBUG-109360. In other words we will not mandate C++20 compilers in Qt 6.8 yet. An LTS release is not the right for such a breaking change anyway. The possible releases for such a drastic change are 6.9 or 6.12 (releases immediately following an LTS release). Note that I am not cofirming those releases but merely point out which type of releases could be potential options. Considering the track record we have when getting Phase 1 items into the release and considering existing customer concerns I have a hard time believing that 6.9 is a serious option. This is my personal opinion. -- Alex From: Development on behalf of Thiago Macieira Sent: Saturday, 3 February 2024 18:13 To: development@qt-project.org Subject: 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 -- 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 03.02.24 18:13, Thiago Macieira wrote: > 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. We don't drop supported compilers except in LTS+1 releases. That means 6.9 at the earliest. In the last round, these were the objections: a. QNX and Integrity don't support it, yet b. We'd like to avoid forcing users to switch their projects to C++20, which is the rationale for separating (2) and (3) above. I think (a) is a blocker, unless we allow different platforms to have different minimum C++ version requirements. That won't help with whatever you're thinking about when you ask to require C++20, because it means we'll need to maintain C++17-compatibility in the vast majority of the code-base. I have some sympathy for (b), and I could live with the required #ifsef'ery for the time being, because it would be something that's required for (public) headers only. Jani, Vladimir: do we have line-of-sight for C++20 support in QNX, Integrity, VxWorks and WebAssembly? Thanks, Marc -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Let's drop MSVC 2019 for dev (6.8)
On Saturday, 3 February 2024 18:08:25 CET Thiago Macieira wrote: > 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. I was trying to drop support for it in qtwebengine in 6.7, but the problem was it was still used for qt packaging. But if we could at least switch packing to vs2022, it would mean we could drop it in QWE. Best regards Allan -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Let's drop MSVC 2019 for dev (6.8)
I think we don't drop supported compilers, except in LTS+1 releases (6.9 being the next). On 03.02.24 18:08, Thiago Macieira wrote: > 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. > > -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's our policy on changing the result of qHash(T, 0) between major releases?
Hi, I've always understood it such that we as Qt must preserve the property that the hash for equal elements is equal within _one_ run of _one_ process. This means you can use the hash in I/O in any way. That's why we have qt_hash, which you _can_ (and do) use in I/O (but is private API, AFAIK). I never thought that a hash seed of zero would change that, but of course users may have come to depend on this (Hyrum's Law), so a [ChangeLog] would be in order. From that follows that you can change the hash algorithm, provided the hash function is out-of-line exported, but you can't if it's inline (or, theoretically, non-exported, because some user may have copied the implementation into his application or wrote a conflicting one; which is why I'd suggest to =delete non-Qt-provided qHash functions: to prevent users from writing their own). HTH, Marc On 03.02.24 22:08, Thiago Macieira wrote: > 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 > > -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
