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

Git repository change summary for qt/qt/qtbase
Pushed by mirror-service into branch 'dev'.
Changed from a97ff4ed1df5861a02516a3162ed90291247c7af to 823afbe2fee824e048939d278e712b6b78fc9999
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 d94f2a394a52adf7f7cb25b3ea8606fb17872ae5 by Edward Welbourne on 18/08/2026 at 19:40..
tst_QDateTime: separate integral arithmetic from duration arithmetic

The duration arithmetic is more amenable to reducing repetition. The
prior split also misleadingly included std::chrono::seconds tests in
addSecs(), despite the duration going via a milliseconds API, thereby
causing UB on the seconds-specific tests, which were deliberately
outside the range of 64-bit milliseconds.

In the process, dropped a secsTo() check from addSecs(), that was
redundant with the same check in the secsTo() test, which reuses all
the addSecs() data.

Added a new QDTCOMPARE() macro to do the "compare as not just same
instant but also same representation of it" that was repeated here.

Amends 0a17a0da618a9dc8151aac4dff567326c0cb8a2a (6.4) and commit
41a7546789bf95b5b00e2e331896ea696b20b723 (6.4), which added tests
using std::chrono::duration values to the existing qint64-based
addSecs() and addMSecs tests (respectively).

Thanks to Marc Mutz for a proposed fix for the UB that made clear what
the problem was and also brought to my attention that these tests
needed some sorting out.

Pick-to: 6.12 6.11 6.8 6.5
Task-number: QTBUG-148616
Change-Id: Iff97745f401e675d58d46f2b42505becdeb5e8fa
Reviewed-by: Mate Barany <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/d94f2a394a52adf7f7cb25b3ea8606fb17872ae5

Git commit a4d71263b95e6d10a0a9fd76f05f52f25e8c8f1c by Edward Welbourne on 18/08/2026 at 19:40..
tst_QDateTime: make further use of the new QDTCOMPARE() macro

This makes it easier to see what's going on in some tests, notably
making clear that the toTimeSpec() test had some redundancy.

In the process, check more of the details that verify equal
representations, where some of the tests now using the macro checked
these details. These checks are somewhat redundant, but this may catch
any corner cases where they aren't *strictly* redundant. For example,
although QDT's compareThreeWay() does reduce, after some cheaper
prechecks, to a comparison of toMSecsSinceEpoch(), anything that
causes the prechecks to not correctly anticipate that comparison would
come to light here. Also eliminate some redundant comparisons, of form
B == C where A == B and A == C have already been checked.

Pick-to: 6.12 6.11 6.8 6.5
Change-Id: I2d56da5d01298c8b611c2a1d3374fc6d2bb451c5
Reviewed-by: Mate Barany <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/a4d71263b95e6d10a0a9fd76f05f52f25e8c8f1c

Git commit c3feb5d070306d401420a91e1e6902923567c709 by Edward Welbourne on 18/08/2026 at 19:40..
Clarify the status of QDT::YearRange's bounding years

Each is only partially represented by QDateTime.
Amends commit a4f5f25eb05f49474eaef665abdbcaad9203ba48 (5.14).

Pick-to: 6.12 6.11 6.8 6.5
Change-Id: Ia6f46bed4a6be5eb519f83324c2823b908828815
Reviewed-by: Ivan Solovev <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/c3feb5d070306d401420a91e1e6902923567c709

Git commit b3408815b00d7890f079db100e3d2727124070df by Edward Welbourne on 18/08/2026 at 19:45..
Tidy up tst_QLocale::toTimeFormat() and its _data()

Drop an unused LocaleInput, change the locale name (locally) to a
QL1SV and use the UTF-8 representation of the format string, since it
might contain characters not representable in Latin-1.

Pick-to: 6.12 6.11
Change-Id: I86f5578b27137a5a703000730af12aab62f02960
Reviewed-by: Ivan Solovev <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/b3408815b00d7890f079db100e3d2727124070df

Git commit 36334067f551c3075163ce271178730808791ed0 by Alexandru Croitor on 18/08/2026 at 19:45..
CMake: Rename QT_NO_XCODE_EMBED_FRAMEWORK to be more descriptive

The property is set on a dependency target to prevent embedding
that dependency into the consuming app bundle.

The property name is too similar to the QT_NO_XCODE_EMBED_FRAMEWORKS
property which is meant to be set on the app target.

Rename
 QT_NO_XCODE_EMBED_FRAMEWORK
to
 QT_NO_XCODE_EMBED_FRAMEWORK_IN_CONSUMERS
to make it clearer that the property should be set on dependency
targets that should not be added to the consuming app bundle.

Amends 4ca5d74a86c2d65b924cb084e8e4a954bab3a2e7

Pick-to: 6.12
Fixes: QTBUG-149145
Change-Id: I966e8dfbe93a368b1990eead3bc9384167861bdf
Reviewed-by: Tor Arne Vestbø <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/36334067f551c3075163ce271178730808791ed0

Git commit 6900f98d7053c58352253c63a59688e50214bef0 by Alexandru Croitor on 18/08/2026 at 19:45..
Doc: Document the Xcode embedding of shared library dependencies

Finalization of an iOS app target embeds the shared libraries the
app links against into the app bundle. The behavior and the properties
to opt out of it were not documented anywhere.

Describe the behavior and the conditions under which it happens in the
iOS section of qt_finalize_target(), and add property pages for
QT_NO_XCODE_EMBED_FRAMEWORKS and
QT_NO_XCODE_EMBED_FRAMEWORK_IN_CONSUMERS.

Relates to 4ca5d74a86c2d65b924cb084e8e4a954bab3a2e7

Pick-to: 6.12
Fixes: QTBUG-149144
Change-Id: I3031cd4e335cc86fbbf111f2ed01da336ea87c80
Reviewed-by: Tor Arne Vestbø <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/6900f98d7053c58352253c63a59688e50214bef0

Git commit 9d348fb40da0aad2ee1b5b6977489d860a29f022 by Thiago Macieira on 18/08/2026 at 20:18..
QLockFile: Document known limitations

Pick-to: 6.12 6.11 6.8
Change-Id: Iaea1259994f676a7a6c8fffd08195936fc9e6a69
Reviewed-by: David Faure <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/9d348fb40da0aad2ee1b5b6977489d860a29f022

Git commit c5b54550e49b4d9ccf065fa07ff679ce4401a440 by Thiago Macieira on 18/08/2026 at 20:18..
QLockFile/Doc: indicate what happens if you set the stale lock time to 0

It disables the time verification. We still verify the contents.

Pick-to: 6.12
Change-Id: I037d05f4b75012585b41fffdbd1cc15c1da74616
Reviewed-by: David Faure <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/c5b54550e49b4d9ccf065fa07ff679ce4401a440

Git commit 78b7b6ffc841d56fab45bc97fc07728f4f39cd5a by Thiago Macieira on 18/08/2026 at 20:18..
QLockFile/Unix: try harder to release locked files

On some systems, attempting to remove or rename a file with an active
lock fails with EBUSY (observed on Dell EMC Unity's NFSv4.2 server). We
must drop the locks first, which close() does, then unlink() the file.

The filesystem's behavior prevents most race conditions: for the
unlock/tryLock pairing, if we have not yet unlink()ed the file,
tryLock_sys() will fail due to the O_EXCL flag. If isApparentlyStale()
is false, then the new locker simply fails at locking and may
wait. However, if isApparentlyStale() is true, then we race with
removeStaleLock() in the new locker:

- if the new locker is in removeStaleLocker() and has opened the lock
  file but has not yet locked it, the original locker may unlink() this
  file, but then setNativeLocks() will fail and returns false, causing
  tryLock_sys() to wait then try again

- if the new locker is in removeStaleLocker() and has locked the lock
  file but not removed it, the original locker will fail at unlink(),
  which is ok: the lock ownership has transferred to the new locker,
  which will remove it in releaseLockFile() and recreate after looping

- if the new locker has finished removeStaleLock(), removing the file
  but not yet recreated it, the old locker's unlink() will fail with
  ENOENT

- if the new locker has removed the file and has created the new one but
  not yet locked it, the original locker may unlink() it, which will
  cause the new locker's attempt at setNativeLocks() to fail, print a
  warning, but proceed without a native lock. This is a problem.

- if the new locker has removed the file, created the new one, and
  locked it, unlink() will again fail with EBUSY, which is again ok

The second-to-last case is the only one in which there's a problem:
QLockFile will hold an open file descriptor to a deleted file, which
means it thinks it has locked, but from the point of view of any other
processes/threads, there is no lock.

removeStaleLock() now returns whether the lock file is actually gone;
if it cannot be removed (e.g. another user's stale lock in a sticky
directory), lock() falls back to sleeping between attempts.

Fixes: QTBUG-148845
Pick-to: 6.12 6.11 6.8
Change-Id: Id7a39975010bf525e016fffd5271da416614aace
Reviewed-by: David Faure <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/78b7b6ffc841d56fab45bc97fc07728f4f39cd5a

Git commit 3516d887b22d72ce2284ba28f45777da7a4f63ea by Thiago Macieira on 18/08/2026 at 20:18..
QLockFile/Unix: handle EINTR in tryLock_sys()

Both F_SETLK and flock() are documented to possibly fail with EINTR if
the operation has been interrupted by a signal. This has not been a
problem so far, because the inability to lock has been ignored (just
prints a warning). I'm going to change that, so begin handling EINTR.

Pick-to: 6.12 6.11 6.8
Change-Id: Id2a8aef2969c508324fdfffd187ccc59f84a1490
Reviewed-by: David Faure <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/3516d887b22d72ce2284ba28f45777da7a4f63ea

Git commit acc3ef5cc97cfa1c702fd1b6f9f59b10f198214b by Thiago Macieira on 18/08/2026 at 20:18..
QLockFile/Unix: remove unused #includes

Pick-to: 6.12 6.11 6.8
Change-Id: Ia8d5c5316cb5215a6c32fffd014eb683aa7d8268
Reviewed-by: David Faure <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/acc3ef5cc97cfa1c702fd1b6f9f59b10f198214b

Git commit 1535821ed5483fc9958ead423ca9740d280d3694 by Thiago Macieira on 18/08/2026 at 20:18..
QLockFile/Unix: use QUniqueFileDescriptorHandle in tryLock_sys()

Pick-to: 6.12 6.11 6.8
Change-Id: I32f3d22361eaa3a70c0efffd57ce060def4939c9
Reviewed-by: David Faure <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/1535821ed5483fc9958ead423ca9740d280d3694

Git commit 1d620ae0890db855e530d05ef398bffc80d5e61c by Thiago Macieira on 18/08/2026 at 20:18..
QLockFile/Unix: don't ignore setNativeLocks() legitimate failures

QLockFile cannot rely on the FS and OS supporting native locks or their
working reliably (see main class docs), so it just ignored the failure
to lock. This was probably on the incorrect assumption that the only
reason setNativeLocks() would fail would be when locking was not
supported.

That's wrong: there's a race condition between removeStaleLock() and
tryLock_sys(). It is possible for one thread/process to be trying to
acquire the lock in tryLock_sys() and another to be trying to remove it
as stale (either from the public removeStaleLockFile() or via
tryLock()), because creating the file and setNativeLocks()'ing it are
not atomic. That is, there is a time between tryLock_sys() creating the
file with O_EXCL and applying setNativeLocks() when the file is unlocked
and *empty*, which causes isApparentlyStale() to conclude it's a
corrupted lock and return true. This second thread/ process may then
succeed to setNativeLocks(), causing the first to fail, which it would
ignore and print a warning.

This commit fixes this one problem: we separate the ignorable "locking
doesn't work" conditions from the non-ignorable "locking works but
failed". The warning is now only printed for the unknown conditions,
matching Qt practice - the "not supported" case is likely going to be
seen by the end user, not the software developer, so I decided not to
keep it.

Note this is not a full fix: removeStaleLock() may race ahead and unlock
the file before tryLock_sys() gets to setNativeLocks(). See next commit.

Pick-to: 6.12 6.11 6.8
Task-number: QTBUG-149130
Change-Id: Iee9d536751044b8abc90fffd64e8232c1d8a796e
Reviewed-by: David Faure <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/1d620ae0890db855e530d05ef398bffc80d5e61c

Git commit 6c037a6c5ea1c30f7953d323d873c15bd46e1474 by Thiago Macieira on 18/08/2026 at 20:18..
QLockFile/Unix: fix lock creation & unlink() race condition

As noted in the previous commit, it is possible for one thread/process
to be trying to acquire the lock in tryLock_sys() and another to be
trying to remove it as stale (either from the public
removeStaleLockFile() or via tryLock()), because there is a time between
tryLock_sys() creating the file with O_EXCL and applying
setNativeLocks() when the file is unlocked and *empty*, which causes
isApparentlyStale() to conclude it's a corrupted lock and return true.
removeStaleLock() may then lock the file, unlink() it, then close/unlock
all before tryLock_sys() reaches setNativeLocks(). The result is a
QLockFile object thinking it succeeded at creating the lock file, but
the lock file does not exist on the file system.

We cannot check for st_nlink = 0: there's no POSIX guarantee that the
deleting a file will drop to that - for example, on some file systems,
it is possible that deleting a file is implemented by a clobbering
mechanism (overlayfs) or by renaming it temporarily (some NFS).

Instead, this implementation checks that the actual lock file is our
file. By this point, if the file is ours, it is properly written and is
locked, so it should not get stolen.

Pick-to: 6.12 6.11 6.8
Fixes: QTBUG-149130
Change-Id: I1a177dbd017b31d3b70efffdea1bc1476e6e8beb
Reviewed-by: David Faure <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/6c037a6c5ea1c30f7953d323d873c15bd46e1474

Git commit 51b40c0efedc17837ee29d39fd25751655fb87a8 by Seokha Ko on 18/08/2026 at 23:55..
harmonyos: Exclude "phone" from the test bundle's deviceTypes

An application whose module.json5 lists "phone" in deviceTypes is
treated as a phone app running on PC, so window.restore() is rejected
with WM_ERROR_INVALID_CALLING (1300004). This breaks programmatic
un-minimize (setWindowState() back from WindowMinimized) in the
window-state autotests.

Pass harmonyos-module-device-types ["tablet", "2in1"] in the test bundle
deployment settings so the tests run as a native 2-in-1 app.

Fixes: QTBUG-148467
Pick-to: 6.12
Change-Id: Ie8006278cf8526ca9495f33a7ed5c7ad457abde2
Reviewed-by: Joerg Bornemann <[email protected]>
Reviewed-by: Liang Qi <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/51b40c0efedc17837ee29d39fd25751655fb87a8

Git commit 823afbe2fee824e048939d278e712b6b78fc9999 by Seokha Ko on 18/08/2026 at 23:55..
ohos: Restore a minimized sub-window with showWindow()

On OHOS, Window.minimize() minimizes a main window (restorable from the
dock), but for a child window or global floating window it merely hides
the window, which cannot be restored from the dock and must be brought
back with Window.showWindow().

handleWindowStateChange() routed every un-minimize through
restoreMainWindow(), which returns early for non-main windows, so a
minimized child or floating window was never shown again. Call
showWindow() when Qt::WindowMinimized is cleared on a sub-window or
floating window.

See
https://developer.huawei.com/consumer/en/doc/harmonyos-references/arkts-apis-window-window#minimize11

Pick-to: 6.12
Change-Id: Id97e5e9cd63c665638bfb7f1741961d02999c884
Reviewed-by: Aleksander Wawrzyniak <[email protected]>
Reviewed-by: SanthoshKumar Selvaraj <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/823afbe2fee824e048939d278e712b6b78fc9999