[Development] Meeting minutes from Qt Release Team meeting 07.11.2023
Qt 6.6 status: * Qt 6.6.1 release preparations are ongoing * Branching from '6.6' to '6.6.1' will happen Tue 14th of November * Target is to release Qt 6.6.1 Thu 23rd of November Qt 6.7 status: * Platform and module freeze -milestone will be in effect 24th of November * No new modules known for Qt 6.7. If there will be any please inform Jani immediately. * Possible exceptions can be taken in after FF & Beta1; It is really important to stop provisioning changes at platform and module freeze. * Qt 6.7 Feature Freeze will be in effect 8th of December so only a month time to implement new features for Qt 6.7. Next meeting Tue 21st of November 16:00 CET br, Jani Heikkinen Release Manager irc log below: [16:59:35] <+jaheikki3> ablasche: akseli: carewolf: lars_: mapaaso: The-Compiler: thiago. vohi: ping [16:59:44] jaheikki3: pong [17:00:10] jaheikki3: pong [17:00:52] <+jaheikki3> Time to start qt release team meeting [17:00:58] <+jaheikki3> on agenda today: [17:01:03] <+jaheikki3> Qt 6.6 status [17:01:10] <+jaheikki3> Qt 6.7 status [17:01:18] <+jaheikki3> Any additional item to the agenda? [17:02:40] <+jaheikki3> Let's start from Qt 6.6 status [17:02:58] <+jaheikki3> Which is actually pretty much the same as last time: [17:03:15] <+jaheikki3> Qt 6.6.1 release preparations are ongoing [17:03:34] <+jaheikki3> Branching from '6.6' to '6.6.1' will happen Fri 10th of November [17:04:03] <+jaheikki3> And the target is to release Qt 6.6.1 23rd of November [17:05:10] <+jaheikki3> That's actually all about qt 6.6 status at this time. Any comments or questions? [17:06:01] given that it's bug fixing sprint in the company, maybe branching after that is over makes more sense? [17:06:26] ie. wait for Tuesday 14th [17:06:46] <+jaheikki3> That's actually true, I'll postpone the branching then a bit [17:06:59] +1 [17:07:14] <+jaheikki3> So branching will happen Tue 14th [17:07:25] <+jaheikki3> Thanks for noticing this! [17:07:53] <+jaheikki3> Ok, then Qt 6.7 status [17:08:34] <+jaheikki3> Some challenges to get dependency update done in 'dev'; last successful round 20th October [17:09:10] <+jaheikki3> But known issues should be fixed and new round will be started when latest fix integrates in qtbase [17:09:26] <+jaheikki3> Platform and module freeze -milestone will be in effect 24th of November [17:09:38] <+jaheikki3> No new modules informed so far [17:10:05] <+jaheikki3> So if there will be any please inform me immediately [17:10:44] <+jaheikki3> Qt 6.7 Feature Freeze will be in effect 8th of December so only a month left to implement new features for Qt 6.7 [17:10:56] ok [17:11:12] <+jaheikki3> That's all about Qt 6.7 status at this time. Any comments or questions? [17:11:16] -*- thiago needs to finish one feature for QMetaObject::listInvoke [17:11:20] thanks for reminding [17:11:22] we might have some provisioning changes coming in as a consequence of trying to link dynamically against FFmpeg; are those subject to the platform/modules deadline? [17:11:52] (in which case I might just as well ask for exception right away ;)) [17:12:08] <+jaheikki3> vohi: yes, those are. It is really important to stop provisioning changes at platform/module freeze [17:13:11] agree, those take along time and often have a lot of fallout; but also important that we stop linking statically against FFmpeg, that library has a huge attack surface [17:13:17] <+jaheikki3> vohi: if we need an exception for those that's OK for me but as usual those exceptions should be taken in only after the FF; after beta1 is out [17:14:20] <+jaheikki3> (those platform etc provisioning changes has been biggest reason for FF/beta1 delays in previous releases and it has been much easier after we took that milestone in the use) [17:16:45] <+jaheikki3> It was all at this time so let's end this meeting now. I can't participate Tue 14th so let's have new meeting Tue 21st at this same time [17:17:01] <+jaheikki3> Thanks for your participation, bye! [17:17:04] bye [17:19:30] thanks! -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 7 November 2023 13:34:04 PST Marc Mutz via Development wrote:
> > Yes. Remember that "one binary" is the process as loaded into memory,
> > including all the libraries. Depending on compilation modes, inline
> > functions may be merged from multiple independent libraries at runtime.
>
> Sorry, but [citation needed]. This goes against _everything_ I know and,
> more importantly, everything we've been doing the last decades, incl.
> your own https://codereview.qt-project.org/c/qt/qtbase/+/389682
Any debug build that isn't using -fvisibility-inlines-hidden. Or release
builds for any inline function that didn't get inlined.
Changing of int to qsizetype or qint64 "works" so long as the data actually
fits the int, which for QVersionNumber is 100% of the cases (I'm not even going
to say it's "indistinguishable from 100%" because *no one* uses 2.1 billion
version segments). This problem also only applies to QVersionNumber::size()
and QVersionNumber::SegmentStorage::size(), because only those two would have
the same mangling. All the other functions changed by that commit are new
overloads.
Trying to do the same for QTimer[1] is similar, ignoring the Q_PROPERTY /
QProperty issues. Because it's exported, we'd need to add a new overload, but
that just moves the problem one step further. Imagine:
auto intervalFor(QTimer ) { return t.interval(); }
If recompiled, this code would start returning qint64 instead of int, but
would have the same mangling under the IA-64 ABI, which is bad but mostly
acceptable because it is data-compatible for any timer of less than 24.85 days
(which is ALL of them today).
This above is inline so it goes back to the original problem of non-inlined
inline functions. In the case of our comparison types, someone may see that it
returns auto and decides to write an out-of-line version as:
class MYLIB_EXPORT Foo
{
static decltype(Qt::compareThreeWay(0, 0)) compareThreeWay(Foo, Foo);
};
We'd have to document for them not to do this.
This has also just made me realise a different problem: with MSVC, the mangling
of the function would change. And it's easy to get that problem just by
exporting one's class, because it always exports inline functions and calls
that out-of-line copy imported inline function for anything non-trivial:
class MYLIB_EXPORT Foo
{
int x;
public:
auto compare(Foo a, Foo b) { return Qt::compareThreeWay(a.x, b.x); }
};
So if this user's library is recompiled with a different setting, the ABI
changes. If the user's user's code mismatches the library, it will fail to
link.
Therefore, "Almost Never Auto" applies and especially so for return types
(when used for deducing a type, not for syntactic brevity).
[1] https://codereview.qt-project.org/c/qt/qtbase/+/491119
--
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] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 07.11.23 20:12, Thiago Macieira wrote: > On Tuesday, 7 November 2023 06:28:51 PST Ivan Solovev via Development wrote: [...] >> The main reason to use `auto` is that it will allow us to avoid unnecessary >> `std::*_ordering -> Q*Ordering -> std::*_ordering` conversions in the C++20 >> case, which will hopefully be the common case going forward. >> >> The main argument agains it is the possible ODR violation when mixing C++17 >> and C++20 in one binary. >> >> So, my question is - shoud we support mixing C++17 and C++20 in one binary? > > Yes. Remember that "one binary" is the process as loaded into memory, > including all the libraries. Depending on compilation modes, inline functions > may be merged from multiple independent libraries at runtime. Sorry, but [citation needed]. This goes against _everything_ I know and, more importantly, everything we've been doing the last decades, incl. your own https://codereview.qt-project.org/c/qt/qtbase/+/389682 > So don't violate ODR. > > At worst, you can make them overload each other by having different > parameters. > So the Qt functions can switch between the two return type families. But you > can't overload operators, so operators must return one family only. -- 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] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 7 November 2023 09:07:10 PST Marc Mutz via Development wrote: > To be clear: This is not about Qt compiled with C++17 used in projects > compiled with C++20. This is about one .cpp file being compiled with > C++17 and another .cpp file from, broadly speaking, the same cmake > target, in C++20 (static builds are different; there, the whole > application incl. all "statically-linked libraries", is one executable). No, it's not. See my reply. Your answer still applies, just that it gets bigger so: > 1. Ban mixing different C++ versions in the same executable (= cmake > target). > > This is probably the safest. If we allowed this instead, we'd need to > review all of our APIs to see whether we have a similar issue already. You must remove "cmake target" portion. This applies to the executable as loaded into memory. -- 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] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 7 November 2023 06:28:51 PST Ivan Solovev via Development wrote: > Hi, > > I'd like to discuss one more topic regarding the C++20 comparison. > > Can we allow an `auto` return type in helper functions and the three-way > comparison implementation for the built-in types? Answering the question as asked: yes. So long it always resolves to the same thing. > The idea is that these methods can return `Q*Ordering` types in C++17 mode, > and `std::*_ordering` types in C++20 mode. No. They must return the same thing. Choose one and stick to it until Qt 7. > The main reason to use `auto` is that it will allow us to avoid unnecessary > `std::*_ordering -> Q*Ordering -> std::*_ordering` conversions in the C++20 > case, which will hopefully be the common case going forward. > > The main argument agains it is the possible ODR violation when mixing C++17 > and C++20 in one binary. > > So, my question is - shoud we support mixing C++17 and C++20 in one binary? Yes. Remember that "one binary" is the process as loaded into memory, including all the libraries. Depending on compilation modes, inline functions may be merged from multiple independent libraries at runtime. So don't violate ODR. At worst, you can make them overload each other by having different parameters. So the Qt functions can switch between the two return type families. But you can't overload operators, so operators must return one family only. -- 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] Replacement for QFont::ForceIntegerMetrics in Qt 6?
Hi, thanks, QFont::PreferFullHinting seems to do the trick. I actually had that set for testing and thought QTextOption::setDesignMetrics(false) was the fix (after reading a bit of QFontEngineFT) but it was the hinting all along :-) Thanks! Cheers Kai Uwe Am 06.11.23 um 12:04 schrieb Eskil Abrahamsen Blomfeldt: Hi! ForceIntegerMetrics was originally added to get CoreText to look at little bit better with WebKit, since WebKit did not support subpixel positioning at the time and CoreText did not support font hinting. I removed it in Qt 6 because it's honestly not a typographically sensible thing to do, and the original use case had become irrelevant For your case, where you want to make sure your font aligns to the pixel grid, you could try enabling hinting on it with font.setHintingPreference(QFont::PreferFullHinting). Font hinting will slightly alter the glyphs so that they actually align to the pixel grid instead of introducing kerning errors (which is what ForceIntegerMetrics did). I'm not sure if this is what you mean by "disabling design metrics"? If so, what exactly was the issue with it? I principle, I think this is the most correct solution to the problem, so maybe there's some way of getting it to work. If that does not work, then another option is to manually get the QGlyphRuns from the QTextLayout and align the glyphs yourself before drawing them. That should get you the same layout as with ForceIntegerMetrics, both good and bad, without much extra work. (Of course, ideally the rendering code should not assume integer advances for the characters, since this is not really a reasonable expectation for unhinted, scalable fonts, but I can see how it's not tempting to rewrite it just for this port.) Eskil Abrahamsen Blomfeldt Senior Manager, Graphics -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 07.11.23 15:28, Ivan Solovev via Development wrote:
>
> So, my question is - shoud we support mixing C++17 and C++20 in one binary?
To be clear: This is not about Qt compiled with C++17 used in projects
compiled with C++20. This is about one .cpp file being compiled with
C++17 and another .cpp file from, broadly speaking, the same cmake
target, in C++20 (static builds are different; there, the whole
application incl. all "statically-linked libraries", is one executable).
What will happen is that the first TU is using a Q*Ordering return type
and the second TU is using the std::*_order return type. The linker will
them de-duplicate these per-TU inline function bodies and pick one of
them. Lets say, for the sake of argument, the C++17 one. Since the two
sets of ordering types are not binary compatible, and equivalent states
have different numerical values, the result of the call to the function
in the C++20 TU will be misinterpreted when it comes from the C++17
function. Of course, the whole thing is UB, so we may not even get so
far as a possible misinterpretation.
There are several ways to solve this:
1. Ban mixing different C++ versions in the same executable (= cmake
target).
This is probably the safest. If we allowed this instead, we'd need to
review all of our APIs to see whether we have a similar issue already.
2. always use only the Q*Ordering types.
Esp. since the numerical values of std::*_ordering and Q*Ordering don't
match, this will inject value-mapping code in future-proof idiomatic
C++20 code like
switch (lhs <=> rhs) {
case std::strong_order::less: ~~~;
~~~;
}
I would very much like to avoid that overhead.
3. make the Q*Ordering types binary compatible with the std ones.
If they're binary compatible, then while technically UB (ODR violation)
the situation would be very much like any other change to inline API.
There are two issues here: First, different std libs have different
values for the different states, so we'd need to #ifdef our own enum to
what the currently-used stdlib is using. Second, QPartialOrdering was
released independent of the C++20 comparison work, in Qt 6.0. So we
would need to dissociate the C++20 comparison stuff from it and rename
the existing 6.7 Q*Ordering types to, say, Qt:*_ordering, to start with
a clean slate.
My opinion:
- 1 is simplest, but we don't control how users compile our APIs, so
someone may still trigger this
- 3 is cleanest, therefore preferred: the complexity is on us, but the
resulting code is as efficient as can be, regardless of C++17 or C++20.
This is how it should be in C++.
- I don't like 2. It has it all backwards.
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] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
Hi, I'd like to discuss one more topic regarding the C++20 comparison. Can we allow an `auto` return type in helper functions and the three-way comparison implementation for the built-in types? The idea is that these methods can return `Q*Ordering` types in C++17 mode, and `std::*_ordering` types in C++20 mode. The question was raised and discussed here: https://codereview.qt-project.org/c/qt/qtbase/+/478199/comment/bbab752c_520dc684/ Now we have two controversial opinions. The main reason to use `auto` is that it will allow us to avoid unnecessary `std::*_ordering -> Q*Ordering -> std::*_ordering` conversions in the C++20 case, which will hopefully be the common case going forward. The main argument agains it is the possible ODR violation when mixing C++17 and C++20 in one binary. So, my question is - shoud we support mixing C++17 and C++20 in one binary? Before continuing with the patches, I'd like to hear more opinions. Thanks, Ivan From: Ivan Solovev Sent: Wednesday, October 4, 2023 11:15 AM To: development@qt-project.org Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt) So, let me give another update. The chaing ending in https://codereview.qt-project.org/c/qt/qtbase/+/508464 passed a full pre-check in the CI. It implements the macros in terms of helper functions ``comparesEqual()`` and ``compareThreeWay()``. The macros are documented as internal for now. It also provides ``qCompareThreeWay()`` as a public API for three-way comparison. The chain also contains examples of applying the new macros to some of the Qt classes: QTime, QDate, QDateTime, QTimeZone, and qfloat16. I think, Marc also started migrating more Qt classes to the new macros. We also have a draft of a QUIP which describes how to apply the new macros to the Qt classes: https://codereview.qt-project.org/c/meta/quips/+/490932 -- Ivan Solovev Senior Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 12489 Berlin, Germany ivan.solo...@qt.io www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From: Edward Welbourne Sent: Tuesday, September 26, 2023 4:31 PM To: development@qt-project.org ; Ivan Solovev Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt) Thiago wrote: >> See my other email: the (1) is not discoverable, teachable, or >> particularly understandable by average C++ developers. It is not a >> good corner of C++. Ivan Solovev (21 September 2023 11:10) replied: > As you correctly pointed out, most of the developers will just use > public operator==(), and, come C++20, operator<=>(). > > But I'd say that if someone wants to implement three-way comparison > for their classes in C++17, then a bit better understanding of the > language features is a reasonable expectation. You're not thinking of all the different users of code. The author of a class using Qt, that opts to use our mechanism for comparisons, can indeed be expected to understand the fancy new language features, around which that mechanism is built. However, the client of that code, who just wants to compare two things, is a separate player in the game; you're also expecting them to have that level of sophistication. That's more of a stretch: they're just trying to coax their template into coping with one of its parameters being this class that someone using Qt has exposed to them in a library they're using. They may not even be using Qt themselves, merely publishing a helper template that someone else is trying to use in conjunction with some classes written using Qt. We don't want them to throw up their hands and tell the users of their template they don't support use of Qt classes with their templates because "Qt does things weirdly" (as far as they're concerned). Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating QtGRPC & Qt Protobuf maintainers
Alex Blasche (6 November 2023 15:55) wrote: > Qt GRPC and Qt Protobuf were added to Qt a while ago. However until > now they have been in Tech Preview mode. As we investigate the > remaining issues which might prevent us from leaving TP, we need to > address the open issue of maintainer-ship. > > I'd like to nominate Tatiana Borisova as maintainer for Qt Protobuf > and Alexey Edelev as maintainer for Qt GRPC. In fact, both have been > working on this code base even before they officially became part of > Qt. I am glad they agreed to continue this work going forward in the > context of Qt Development. +1 - makes sense to me. Full disclosure: one's in the same team as me, the other sporadically rescues me from CMake woes. I've also been reviewing large swathes of these modules. But that just means I've seen their work enough to form an opinion ;^> Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
