[qt/qt/qtbase]: Summary of bulk changes made

Git repository change summary for qt/qt/qtbase
Pushed by mirror-service into branch '6.12'.
Changed from 8066bb14aff0a99e6e0e730b138d6c739eac45fd to 9b7f8c8356d8a2f2e8105712533e4cc516fba990
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit 24b1a06237a5b168d70378d5dcfe5f83bee1dd38 by Qt Cherry-pick Bot (on behalf of Zbigniew Chyla) on 20/07/2026 at 22:10..
ohos: prefer QNapi Object::eval() over call()

Object::eval() and Object::call() are almost functionally identical:
both resolve a JS member function from an expression and invoke it, and
both support nested calls inside that expression. For example, the
eval() expression

    "@ohos.abilityAccessCtrl.createAtManager().checkAccessToken(*)"

is equivalent to the call() method name

    "@ohos.abilityAccessCtrl.createAtManager().checkAccessToken"

The only difference is that call() spells the outermost invocation
without trailing brackets and takes its arguments from a separate
parameter, whereas eval() expresses that call in the expression itself.

Keeping two overlapping APIs adds no value and only invites inconsistent
call styles across the code. Standardize on eval(), the more flexible
and more widely used of the two. A bracket-less invocation, should it
ever be needed, remains available through the underlying Napi::* APIs.

Convert the call() uses that remain in qtbase. We plan to remove the
call() member once uses in other modules are gone as well.

Task-number: QTBUG-148367
Change-Id: I0131bb9e955111a4acf342742095877cadc7a078
Reviewed-by: Dawid Śliwa <[email protected]>
Reviewed-by: SanthoshKumar Selvaraj <[email protected]>
(cherry picked from commit 158c43050596d7e48f192449d155628c64fcc070)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/24b1a06237a5b168d70378d5dcfe5f83bee1dd38

Git commit 6cbdcca3d110efe3a909e31b8c115b9b14c37aac by Qt Cherry-pick Bot (on behalf of Thiago Macieira) on 20/07/2026 at 22:10..
QObject: restore registering some types during connect()

Amends commit b0f495735c30e400c9749c8b9f9823dbb56dfbd9, which introduced
this regression. That was intended to fix a problem with *what* we
registered, not *whether* we registered. However, by removing the
   { Defined = 1 }
from the QMetaTypeId2 expansion, that caused this old Qt 5.0 code to
fail to register the types. It was fine in Qt 5.x because types required
Q_DECLARE_METATYPE.

In Qt 6, types don't need to be declared (except for a few corner cases
that we haven't yet properly fixed), but this code was requiring them to
be so. This commit updates it to query qmetatype.h, using the same
qTryMetaTypeInterfaceForType() that moc-generated code does.

Task-number: QTBUG-147588
Fixes: QTBUG-132826
Change-Id: I11e523a3c42ba0b81f35fffd048c20fb2f924f3e
Reviewed-by: Fabian Kosmale <[email protected]>
(cherry picked from commit 3bb40a9706d51ef0582e44827dc47bc6232211b6)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/6cbdcca3d110efe3a909e31b8c115b9b14c37aac

Git commit 9b7f8c8356d8a2f2e8105712533e4cc516fba990 by Qt Cherry-pick Bot (on behalf of Ulf Hermann) on 20/07/2026 at 22:10..
Add QPropertyBindingPrivate::bindingFunctionVTable() accessor

Expose the binding function vtable so that code creating a binding from
a named functor can recover that functor from a type-erased
QUntypedPropertyBinding by matching the vtable against the functor type.

We need this in order to identify translation bindings by compilation
unit when dynamically updating objects during QML preview.

Task-number: QTBUG-146122
Change-Id: I5de612bbf04404f297f6ab5da5235ca2bdc81f8a
Reviewed-by: Fabian Kosmale <[email protected]>
(cherry picked from commit d94973f5b8b73a876cbab9234aa0f9f20afeb05d)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/9b7f8c8356d8a2f2e8105712533e4cc516fba990