[Development] Heads-up: what's new in '6.6' doc needs your updates

[Jani Heikkinen via Development]

Hi all,
https://code.qt.io/cgit/qt/qtdoc.git/tree/doc/src/whatsnew/whatsnew66.qdoc 
seems to be quite unfinished ☹ It would be good to get some more content there 
for Qt 6.6 Beta1 (which is planned to happen during this week). So please do at 
least most important updates now; finalizing and polishing can then happen 
later in beta phase.

br,
Jani

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] C++20 ctor-level [[nodiscard]] (was: Re: C++20 @ Qt)

[Marc Mutz via Development]

Hi,

TL;DR:
- we should add Q_DISCARD_CTOR to all ctors of classes with class-level 
[[nodiscard]], esp. RAII objects
- class-level [[nodiscard]] seems to be abused atm to get ctor-level 
[[nodiscard]] semantics in C++!7
- do we want to mark (almost) all ctors as [[nodiscard]], in the future?

Long form:

Ivan implemented Q_NODISCARD_CTOR for 6.6 and I've started to roll use 
of it our over the QtBase. I have some questions.

First, some terms:

I call this a class-level [[nodicard]]:

class [[nodiscard]] QSignalBlocker {  };

This is a C++17 feature and we can (and do) use it unconditionally.

I call this a ctor-level [[nodiscard]]:

class QSignalBlocker {
public:
[[nodiscard]]
explicit QSignalBlocker(QObject *o) ;

};

This is a C++20 feature (technically, it's a clarification, potentially 
retroactively applied to C++!7, but that still means we can't rely on 
it), which is why we need a macro.

I won't lecture about what the two so, you can read up on that on 
cppreference.com:
- https://en.cppreference.com/w/cpp/language/attributes/nodiscard
- Paper: wg21.link/p1771

The obvious first scenario is to cause warnings for code such as

// Listing 1
QMutexLocker(&mutex);

Or any other RAII class. Clang warns about this with a class-level 
[[nodiscard]]. GCC does not.

So the first rule should be to make all ctors [[nodiscard]] in classes 
that are class-level [[nodiscard]].

So far so good.

Enter QScopedPointer. It currently has a class-level [[nodiscard]], but 
does that actually make sense? C++!7 allows us to return QScopedPointer 
from a function (guaranteed copy elision), so users can write functions 
that return QScopedPointer. But it's not like use of that return value 
is required to be required.

So I've come to think that this use of class-level [[nodiscard]] is wrong.

It's the only way to get the desired warning for Listing 1 in C++17 
(absent P1771), on some compilers, but the semantics are wrong. Even for 
pure RAII types: I might return a QMutexLocker from a function, but that 
shouldn't mean that function's return value is [[nodiscard]]. It might 
be perfectly ok to discard it. We don't know, yet we enforce that policy 
for everyone by making QMutexLocker class-level [[nodiscard]].

In fact, what we actually want is ctor-level [[nodiscard]] in these 
cases. For the time being, given we support C++17, I'm ok with having 
class-level [[nodiscard]] on pure RAII classes (ie. not on smart 
pointers), but come C++20, we should remove these in favour of 
ctor-level [[nodiscard]]s.

Here comes the can of worms: If you accept that Listing 1 is worth 
warning about, what about

 // Listing 2
 QSize(12, 32);

 // Listing 3
 QString("Hello, useless");

 // Listing 4
 QSlider(0, 100, this);

Does this mean that, like for most const member functions that have 
since gotten [[nodiscard]] because their only side-effect is to produce 
a return value, we should mark _all_ ctors [[nodiscard]], because their 
only side-effect is to produce an object?

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] Nominating Tatiana Borisova as approver

[Alex Blasche via Development]

Congratulations to Tatiana, approver rights have been granted.

--
Alex

> -Original Message-
> From: Development  On Behalf Of
> Alexey Edelev via Development
> Sent: Tuesday, 23 May 2023 15:40
> To: Qt development mailing list 
> Subject: [Development] Nominating Tatiana Borisova as approver
> 
> Hello everyone,
> 
> 
> I would like to nominate Tatiana Borisova for approver rights in the Qt 
> project.
> 
> Tatiana has been contributing to the Qt Project as a TQtC employee since 2021,
> where most of her work went towards to our INTEGRITY support.
> 
> She recently joined the Qt Core team,
> and has been mainly working on QtGrpc among other contributions to qtbase,
> qtdeclarative, and other modules.
> 
> You can see her merged changes here:
> https://codereview.qt-
> project.org/q/owner:tatiana.borisova%2540qt.io+is:merged
> 
> and her reviews here:
> https://codereview.qt-project.org/q/reviewer:tatiana.borisova%2540qt.io
> 
> 
> 
> 
> 
> Alexey Edelev
> 
> Software Engineer
> 
> 
> 
> Qt Group
> Erich-Thilo-Str. 10 12489
> Berlin, Germany
> 
> alexey.ede...@qt.io
> 
> www.qt.io 
> 
> 
> 
> 
> 
> 
>  
>   
> 
> 
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Konrad Kujawa as approver

[Alex Blasche via Development]

Congratulations to Konrad. Approver rights have been granted.

--
Alex

> -Original Message-
> From: Development  On Behalf Of
> Alexey Edelev via Development
> Sent: Wednesday, 24 May 2023 12:31
> To: Qt development mailing list 
> Subject: [Development] Nominating Konrad Kujawa as approver
> 
> Hello everyone,
> 
> I would like to nominate Konrad Kujawa for approver rights in the Qt project.
> 
> 
> Konrad is a member of the Qt Core team, and has been mainly working on QtGrpc
> among other contributions to qtbase, qthttpserver, qtdeclarative and other 
> repos.
> 
> 
> You can see his merged changes here:
> 
> https://codereview.qt-project.org/q/owner:konrad.kujawa%2540qt.io+is:merged
> 
> 
> and his reviews here:
> 
> https://codereview.qt-project.org/q/reviewer:konrad.kujawa%2540qt.io
> 
> 
> 
> 
> 
> Alexey Edelev
> 
> Software Engineer
> 
> 
> 
> Qt Group
> Erich-Thilo-Str. 10 12489
> Berlin, Germany
> 
> alexey.ede...@qt.io
> 
> www.qt.io 
> 
> 
> 
> 
> 
> 
>  
>   
> 
> 
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] HEADS-UP: Branching from '6.5' to '6.5.2' done

[Jani Heikkinen via Development]

Hi!

We have branched '6.5.2' from '6.5' now. So from now on all changes targeted to 
Qt 6.5.2 release must have 'Pick-to: 6.5.2' and '6.5' is for Qt 6.5.3 release. 
As usual staging in '6.5.2' is restricted to release team only and we will 
monitor incoming changes automatically.

Target is to release Qt 6.5.2 Wed 28th June so the content for Qt 6.5.2 release 
will be frozen latest Thu 22nd June (but preferably already earlier)

br,
Jani Heikkinen
Release Manager
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Meeting minutes from Qt Release Team meeting 13.06.2023

[Jani Heikkinen via Development]

Qt 6.5 status:

- Qt 6.5.2 preparations are ongoing

   * Branching from '6.5' to '6.5.2' will happen Wed 14th June

   * The plan is to release Qt 6.5.2 Wed 28th June -> Qt 6.5.2 content will be 
frozen Thu 22nd June



Qt 6.6 status:
- Qt 6.6.0 Beta1 preparations are ongoing
   * Beta1 content is frozen
   * Target is to release Qt 6.6.0 Beta1 later this week
- Qt 6.6 API change review ongoing, see 
https://bugreports.qt.io/browse/QTBUG-114214

Next meeting Tue 20th June 16:00 CET

br,
Jani Heikkinen
Release Manager

irc log below:
[17:00:13] <+jaheikki3> ablasche: akseli: carewolf: frkleint: lars_:mapaaso: 
The-Compiler: thiago: vohi: ping
[17:01:35]  jaheikki3: pong
[17:02:03] <+jaheikki3> time to start qt release team meeting
[17:02:09] <+jaheikki3> On agenda today:
[17:02:12] <+jaheikki3> Qt 6.5 status
[17:02:15] <+jaheikki3> Qt 6.6 status
[17:02:21] <+jaheikki3> Any additional item to the agenda?
[17:04:06] <+jaheikki3> Ok, lets start from Qt 6.5 status
[17:04:51] <+jaheikki3> Qt 6.5.2 preparations ongoing
[17:05:11] <+jaheikki3> Branching from '6.5' to '6.5.2' will happen wed 14th 
June
[17:06:12] <+jaheikki3> the plan is to release Qt 6.5.2 Wed 28th June so 
release content will be frozen thu 22nd June
[17:06:32] <+jaheikki3> That's pretty much all about Qt 6.5 status at this 
time. Any comments or questions?
[17:06:57]  I'm a bit worried about 
https://bugreports.qt.io/browse/QTBUG-114334 - it seems like a rather bad 
regression in Qt 6.5.1 to me (any Qt application crashes when 
connecting/disconnecting an input device and then using the touchscreen or a 
touchpad). I was able to exactly pinpoint the bug (see my latest comment 
there), but I'm unable to fix it myself (maybe with some help), but haven't 
heard back
[17:07:00]  so far.
[17:07:22]  (Linux/X11 only, but still meh)
[17:08:24] <+jaheikki3> The-Compiler: Ok, thanks for pointing this one. I'll 
check if Shawn could fix the issue
[17:09:48] <+jaheikki3> Ok, then Qt 6.6 status
[17:11:24] <+jaheikki3> Qt 6.6.0 Beta1 preparations ongoing
[17:11:41] <+jaheikki3> Beta1 content is frozen and package creation ongoing
[17:12:03] <+jaheikki3> Target is to release beta1 later this week
[17:12:34] <+jaheikki3> Qt 6.6 API change review ongoing, see 
https://bugreports.qt.io/browse/QTBUG-114214
[17:13:10] <+jaheikki3> That's actually all about Qt 6.6 status at this time. 
Any comments or questions?
[17:14:38] <+jaheikki3> It was all at this time so let's end this meeting now & 
have new one tue 20th June at this same time
[17:14:47] <+jaheikki3> Thanks for your participation, bye!
[17:14:49]  thanks
[17:15:14]  bye

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development