[Development] QMetaMethod in Qt 6

[Fabian Kosmale]

The task:
Currently, when using QMetaMethod::parameterType, we end up doing a costly string comparison.
In order to get rid of the property cache in QML, we need faster way to obtain the metatype of
method parameters and return types. This also has some benefits outside of QML, as it should speed
up non-pointer-to-member function based connects, as well as QMetaMethod::invoke.

The first solution:
Thanks to Olivier's work, we already have a way to create the QMetaType [1] for properties at compile
time. The straightforward solution was to extend this work to also cover the QMetaMethod use case,
which is what the patch at https://codereview.qt-project.org/c/qt/qtbase/+/294774 does.

The catch:
Unfortunately, in order to create the necessary information, we use templates. And those templates
require the type for which we create the QMetaType to be complete (and if the type is T& or T*, T
must be complete). While this mostly works for properties (as those often are backed by a member),
for methods those types are often only forward declared. Getting qtbase to work with this was
possible, but required larger changes (https://codereview.qt-project.org/c/qt/qtbase/+/297108, in
addition to the fixes already in the initial patch). In many cases, that meant using Q_MOC_INCLUDE
to tell the moc to include the necessary header.[2]
More annoyingly, if a type is forward declared
in a header and only implemented in a cpp file, the only way to get this to work is to include the
moc file in the same cpp file. While doing this inside of Qt is possible, this is not something we
can subject our users to.

The proposed solution:
In order to not break all the existing code, I would propose the following: We generate the QMetaTypes
at compile time if possible. If the type is however incomplete, we store QMetaType::Unknown, and, at
runtime, fall back to the slower string check to get the actual metatype. This is implemented in
https://codereview.qt-project.org/c/qt/qtbase/+/298231. For classes exported to QML, we would then
either generate a warning or an error if they lack complete types. We might also want a build system
option to enforce having complete types.

I would appreciate any suggestions, questions or complaints about the proposed plan.

[1] Strictly speaking, the QMetaTypeInterface, which QMetaType then wraps.
[2] Using a regular include works too, most of the time. It can however negatively affect compile times
    and breaks completely in the case of circular dependencies.




--
Fabian Kosmale
Software Engineer
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosmale at qt.io
+49 1638686070
http://qt.io





Geschäftsführer: Mika Pälsi,


Juha Varelius, Mika Harjuaho


Sitz der Gesellschaft: Berlin,


Registergericht: Amtsgericht


Charlottenburg, HRB 144331 B

--