[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 617242bba272518b57f7c201d63af299abcb877b to 610137137d19dcc6c941c995e137611e5fe2723c
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 f0070dbdf6b0eb32288e3b6c260920e0610abdc2 by Qt Cherry-pick Bot (on behalf of David Faure) on 30/07/2026 at 09:27..
QHostInfo: destroy the result emitter in its own thread

QHostInfoRunnable holds a QHostInfoResult that belongs to the receiver's
thread, but QThreadPool deletes the runnable in one of its own threads,
so that QObject was destroyed from the wrong thread. ThreadSanitizer
reports it as a race on the emitter's vptr, against a receiver being
destroyed at the same time: it fires in tst_qobject's
threadSignalEmissionCrash, where ~QHostInfoResult races with ~QTcpSocket.

Hold it by pointer, and hand it back to its own thread via deleteLater()
when we are not already there. That only works while the thread still has
an event dispatcher to run the deferred delete, so check for one first and
destroy the emitter right away when there is none. This is the situation
at application exit: ~QCoreApplication() clears the main thread's event
dispatcher and only then emits destroyed(), which is what makes the thread
pool finish its runnables.

The emitter keeps its QThreadData alive, but not the QThread, which its
own thread may be destroying while we look at it, so read the dispatcher
and the thread from the QThreadData instead of dereferencing the QThread.

The autotest covers the case of a receiver thread without event dispatcher.

Pick-to: 6.11 6.8
Change-Id: I4490b357c8e011857a005b037b1110f9a044995b
Reviewed-by: Thiago Macieira <[email protected]>
(cherry picked from commit f0d88ae526f7bdcfb436f5a42dc2e409e7aa7215)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/f0070dbdf6b0eb32288e3b6c260920e0610abdc2

Git commit 5e94bcb60a1c0224aae558d9cc736f8f9b0c3386 by Qt Cherry-pick Bot (on behalf of David Faure) on 30/07/2026 at 09:27..
QObject: add QObjectPrivate::deleteInOwnThread() helper

Factor out of QHostInfoRunnable the logic to destroy a QObject that
lives in another thread: hand it back via deleteLater() when that thread
can still run the deferred delete, otherwise destroy it right away. The
thread and the event dispatcher are read from the object's QThreadData,
which outlives it, rather than from the QThread, which the owning thread
may be destroying concurrently.

Other code that deletes a worker from a thread pool can reuse it.

Change-Id: I4ff0a2b2d3534f99348cce9c4aaa15c4715d9cc2
Reviewed-by: Thiago Macieira <[email protected]>
(cherry picked from commit b0ddb565e46fc6309f15e6f726322c2b87494b7c)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/5e94bcb60a1c0224aae558d9cc736f8f9b0c3386

Git commit 8e1f4d8e045bdf2ccafbe8e1f4ff669b2869c4e6 by Qt Cherry-pick Bot (on behalf of Marc Mutz) on 30/07/2026 at 09:30..
QLocalTime: remove unneeded narrowing conversion

The old code first assigned epoch.remainder (a qint64 variable) to an
int variable, just to widen it again to qint64 for the call to
secondsAndMillisOverflow(). In particular, it Q_ASSERTed the range
_after_ narrowing, so potentially misses actual out-of-range cases.

Use auto to avoid the narrowing.

Amends b931688a1e52b9e9bdf3144d392e7ee29e8c3ead (6.4), AFACT.

Pick-to: 6.11 6.8 6.5
Change-Id: I582a0b557723b0f8d98868d6b26180d9c5407589
Reviewed-by: Thiago Macieira <[email protected]>
(cherry picked from commit 42fbb3b5c3d46423a4e956501cbfce0fb5b641b1)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/8e1f4d8e045bdf2ccafbe8e1f4ff669b2869c4e6

Git commit 684d2c9a2a1825a03f7487fde2aa8f13c5d1d86d by Qt Cherry-pick Bot (on behalf of Marc Mutz) on 30/07/2026 at 09:30..
QLocalTime: fix UB (signed overflow) in utcToLocal()'s time_t range check

The check that detects when utcMillis/1000 doesn't fit in time_t
reconstructed utcMillis by multiplying epochSeconds back up by
MSECS_PER_SEC and adding the remainder. For utcMillis values near
std::numeric_limits<qint64>::min(), the floor-division quotient,
multiplied by 1000 alone (before the remainder is added back), falls
just outside the qint64 range, causing signed integer overflow UB,
even though the final reconstructed value would have been in-range.

Says ubsan:

  qlocaltime.cpp:538:30: runtime error: signed integer overflow: -9223372036854776 * 1000 cannot be represented in type 'long long int'
    #0 0x7f9e049c01c0 in QLocalTime::utcToLocal(long long) qlocaltime.cpp:538
    #1 0x7f9e04966811 in QDateTimePrivate::expressUtcAsLocal(long long) qdatetime.cpp:2857
    #2 0x7f9e04982071 in QDateTime::setMSecsSinceEpoch(long long) qdatetime.cpp:4596
    #3 0x7f9e04985a3a in QDateTime::fromMSecsSinceEpoch(long long, QTimeZone const&) qdatetime.cpp:5741
    #4 0x7f9e04985c46 in QDateTime::toTimeZone(QTimeZone const&) const qdatetime.cpp:5286
    #5 0x7f9e0498636e in QDateTime::toLocalTime() const qdatetime.cpp:5238
    #6 0x557d92ee1678 in tst_QDateTime::setMSecsSinceEpoch() tst_qdatetime.cpp:839

Replace the round-trip-by-multiplication with a direct check that
narrowing qint64 quotient to time_t was lossless, which is all the
check actually needs to verify and avoids reconstructing utcMillis via
arithmetic that can transiently overflow.

Amends 35412acd88cad2213be966a950f3112342a299ae (6.2), which added the
multiplication.

Pick-to: 6.11 6.8 6.5
Change-Id: I553bf06b264635bd4f29d45bd45a1d3eec267248
Reviewed-by: Edward Welbourne <[email protected]>
Reviewed-by: Thiago Macieira <[email protected]>
(cherry picked from commit 2ec73e2c46b9921204cd4031c6898df1b48d65c8)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/684d2c9a2a1825a03f7487fde2aa8f13c5d1d86d

Git commit 213de9a2a644c8c2762403b0c1153608b5e9dc8b by Qt Cherry-pick Bot (on behalf of Laszlo Agocs) on 30/07/2026 at 09:34..
rhi: Handle theoretical image size overflows better

Calculate with 64 bit integers, where applicable, checking
if the result fits into the target (signed or unsigned) 32-bit
value. Theoretical for well-formed content since we do not
support > 4 GB (sometimes 2 GB) content anyway. Relevant
for malformed input, however.

Change-Id: I5a04979177e2d69a5fada99ee3066fad5d8bfba5
Reviewed-by: Andy Nichols <[email protected]>
Reviewed-by: Aurélien Brooke <[email protected]>
(cherry picked from commit 75b63ca7a139c63d3adfc556f8b619ac9bfeed41)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/213de9a2a644c8c2762403b0c1153608b5e9dc8b

Git commit 0b082de0f59d717832391110a9f13be58909ec1d by Qt Cherry-pick Bot (on behalf of Laszlo Agocs) on 30/07/2026 at 09:34..
rhi: Fix out-of-bounds read when loading a corrupt pipeline cache blob

The OpenGL and D3D11 backends serialize their own list of entries into
the pipeline cache blob and walk it again in setPipelineCacheData(),
trusting the entry count and the per-entry length prefixes while
validating only the total size. A truncated or crafted blob therefore
read past the end of the data, with the over-read bytes ending up in the
cache, and with OpenGL also handed to glProgramBinary() later on.

Add a bounds-checked reader and use it in both backends, ignoring the
blob on the first inconsistency, just like for a version mismatch.

Also evaluate the blob size check in 64-bit so that
dataOffset + header.dataSize does not overflow on 32 bit archs. That
change is relevant for the Vulkan and Metal backends as well.

Add some autotests.

Change-Id: I49a23e76a3b5a1b0c361e690c92e762d74acef6c
Reviewed-by: Andy Nichols <[email protected]>
(cherry picked from commit 755c15466ab9fda2c26ce1a7834db4cfc86e3142)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/0b082de0f59d717832391110a9f13be58909ec1d

Git commit 831cf4910647de0008a2694127aece72432887cd by Qt Cherry-pick Bot (on behalf of Marc Mutz) on 30/07/2026 at 09:35..
tst_QHashFunctions: fix -Wunused-result

Stow it away in a std::ignore.

Amends ee4d239ee5b13b8dad925a51ff1db0a3728a4675 (picked to 6.5).

Pick-to: 6.11 6.8 6.5
Change-Id: Ieb0b5d50f14d5fac5cf933bd53fa53c95516b66d
Reviewed-by: Thiago Macieira <[email protected]>
(cherry picked from commit 5c88d364eac59f52dd89b47556bdc14df2189bdd)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/831cf4910647de0008a2694127aece72432887cd

Git commit 1fedf755972b99f457d2dbfefc50eccb3c011567 by Qt Cherry-pick Bot (on behalf of SanthoshKumar Selvaraj) on 30/07/2026 at 09:38..
ohos: Rename convertToOhosAppKitWantInfo to convertToOhosExtrasWantInfo

The module rename from QtOhosAppKit to QtHarmonyExtras missed this
helper function, leaving "AppKit" reference in the renamed module.

Amends patch 9ffa885ca65783e1e4b6b34f39bcae45665d033c.

Task-number: QTBUG-148587
Change-Id: Ic7d90f3431c7a7edcb1ab6df3251932ec29b3cd8
Reviewed-by: Tor Arne Vestbø <[email protected]>
(cherry picked from commit 74001befc56be623681de16a3e09c5f121ab7386)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/1fedf755972b99f457d2dbfefc50eccb3c011567

Git commit 67625b3285991443f04e968e430fef2d4add5294 by Qt Cherry-pick Bot (on behalf of Wladimir Leuschner) on 30/07/2026 at 13:53..
QWindows11Style: Honor custom text color in palette for TabBarTabLabel

Custom text color set in a palette was not honored in the
QWindows11Style for the CE_TabBarTabLabel, this patch checks, if a
custom color was set in the palette and uses the custom color instead of
the WinUI3 colors.

Fixes: QTBUG-148548
Pick-to: 6.11
Change-Id: Ifacf17217eb4f6b8ad04b59d112069cfd8148659
Reviewed-by: Oliver Wolff <[email protected]>
(cherry picked from commit 6701459a70e1b38dcab064bcced92d47a6dc6da8)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/67625b3285991443f04e968e430fef2d4add5294

Git commit d9ca700c09cf12f636ba377ae49caa05f9b14d02 by Qt Cherry-pick Bot (on behalf of Laszlo Agocs) on 30/07/2026 at 13:53..
rhi: gl: Add env.var. to force makeCurrent all the time

Certain integrations with external renderers got away with broken
behavior in Qt 5: they could in many cases change the GLX/EGL/etc.
context behind Qt's (and QOpenGLContext's) back, leaving
QOpenGLContext::currentContext() return an untrue result from that point
on.

This worked because in the simpler OpenGL-only world Qt Quick could just
do a makeCurrent when starting to render the next frame, issue some GL
calls, and it did not matter what happened afterwards, i.e. if the
(QOpenGL)context tracking got clobbered between Qt's rendering for the
current and the next frame.

QRhi on the other hand has an API that can be called at any time and
does not expose the legacy concept of thread-local contexts. In its
OpenGL backend, the many QRhi APIs translate to GL calls requiring the
context being current, but at the same time calling that at a high
frequency has a risk of performance degradation, depending on the
platform (think unnecessary flushes, depending on the underlying
drivers). In the vast majority of cases ensureContext() will be a no-op
since the correct context will be found to be already current on the
rendering thread due the checks this function performs.

Add a way via an env.var. (QT_GL_BROKEN_CONTEXT_TRACKING) to force
disabling this and doing makeCurrent() calls all the time, enabling some
Qt 5 projects to function as expected with Qt 6, at the expense of
potential performance degradation.

Task-number: QTBUG-147397
Task-number: QTBUG-147770
Change-Id: Icff47932fef8e1adf3eedc5437a88907b37099a5
Reviewed-by: Andy Nichols <[email protected]>
(cherry picked from commit 4d4638d02dbb4361028cd9d3168fd81d408f6c2c)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/d9ca700c09cf12f636ba377ae49caa05f9b14d02

Git commit 610137137d19dcc6c941c995e137611e5fe2723c by Qt Cherry-pick Bot (on behalf of Laszlo Agocs) on 30/07/2026 at 13:53..
rhi: gl: Disable vert.attr.locs always

...in endFrame(), not only on WebGL. Is turns out
even QPainter's OpenGL paint engine gets confused if
some QRhi-based OpenGL rendering leaves vertex attribute
locations enabled.

Fixes: QTBUG-147817
Pick-to: 6.11 6.8
Change-Id: Iaf34896aa63ba451ba527b7f61c8a2fdb3652b04
Reviewed-by: Andy Nichols <[email protected]>
(cherry picked from commit a56f92130b87bd7446a205f5fa33bd4851de4e22)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/610137137d19dcc6c941c995e137611e5fe2723c