Some of the parameters in the help information were indented by 3
characters instead of by 4.
Pick-to: 6.3
Change-Id: Id11cda79d61c4eab82ee09e33034db55730123c5
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
QPromise is now used in qfuture_impl.h, so we need to include it. Remove
qfuture.h include from qpromise.h, to avoid circular dependency.
As a drive-by, simplify a type-trait: is_convertible_v<T, S> is true
whenever is_same_v<T, S> is, so we don't need to instantiate both.
Fixes: QTBUG-100144
Pick-to: 6.3 6.2
Change-Id: Ic6df43d96d9d168cc44c2949e41c5e490f4c50ce
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
MSVC complains about illegal uses of void, even though the code should
be guarded by an if constexpr statement.
qproperty.h(85): error C2182: 'val': illegal use of type 'void'
qproperty.h(92): error C2182: 'abstract declarator': illegal use of type 'void'
Avoid the issue by using a dedicated dummy type instead of void.
Fixes: QTBUG-100072
Task-number: QTQAINFRA-4242
Pick-to: 6.3 6.2
Change-Id: Idc4886c26c3794e709eb762ba836139f720f8133
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Base class dtors should either be public and virtual or else protected
and non-virtual.
We don't want to model polymorphy, so protected and non-virtual it is.
Pick-to: 6.3
Change-Id: I3c545b01c3ec831ee8b4a0c522501222a69923e9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Unlike QString and QStringView, QByteArrayView and QByteArray don't
overload well.
Solve the overload issue the usual way: by making the QByteArray one a
Q_WEAK_OVERLOAD. This is trivial for QStaticByteArrayMatcher, which
isn't exported, but require QT_REMOVED_SINCE magic for
QByteArrayMatcher, which is.
The additional const char* overload has shielded us from the worst
fall-out so far, it seems, but it makes for a truly horrible overload
set:
matcher.indexIn(str, 3);
Q: Is the 3 here the length of the haystack or the value of the from
parameter?
A: It depends on decltype(str)!
If the (const char*, qsizetype, qsizetype=0) overload is the better
match, then 3 limits the haystack's length.
If, otoh, the (QByteArray(View), qsizetype) overload is the better
match, then it's the value of the from parameter.
As if this wasn't bad enough, QByteArray implcitly converts to const
char* by default!
A follow-up patch will therefore deprecate the (ptr, size) overloads,
so we de-inline the QByteArrayView ones to avoid having to touch the
implementation once more.
Found during 6.3 API review.
Pick-to: 6.3
Change-Id: I9640e0bdd298d651511adebcc85f314db9221d34
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Add a test (same techniques as for the 4+GiB check in
tst_qcryptographichash).
Takes ~1s to build the 4GiB test data here, and skips
when RAM is too low:
$ qtbase/tests/auto/corelib/text/qbytearraymatcher/tst_qbytearraymatcher haystacksWithMoreThan4GiBWork
[...]
QDEBUG : tst_QByteArrayMatcher::haystacksWithMoreThan4GiBWork() created dataset in 891 ms
[...]
$ (ulimit -v 2000000; qtbase/tests/auto/corelib/text/qbytearraymatcher/tst_qbytearraymatcher haystacksWithMoreThan4GiBWork)
********* Start testing of tst_QByteArrayMatcher *********
[...]
SKIP : tst_QByteArrayMatcher::haystacksWithMoreThan4GiBWork() Could not allocate 4GiB plus a couple hundred bytes of RAM.
Loc: [/home/marc/Qt/qt5/qtbase/tests/auto/corelib/text/qbytearraymatcher/tst_qbytearraymatcher.cpp(242)]
[...]
Found during 6.3 API review.
[ChangeLog][QtCore][QStaticByteArrayMatcher] Fixed searching in
strings with size > 2GiB (on 64-bit platforms).
Fixes: QTBUG-100118
Pick-to: 6.3
Change-Id: I1df420965673b5555fef2b75e785954cc50b654f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
On 32-bit machines, qsizetype is int, so we don't actually need to
QT_REMOVE_SINCE the QByteArrayList_join() helper, because it didn't
change.
Thanks to Thiago for showing me the QT_POINTER_SIZE trick in a similar
change to QVersionNumber.
Pick-to: 6.3
Change-Id: Iae6e315107e42da51fcb4e7325b6d40b9c3fe0bc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This reverts commit 77895514d5419b77535de093b544aee30686cd22, which
is in principle correct, but results in XPASS'ing tests in qtdeclarative
that we need to adapt first.
Originally reverted only for 6.3, but now also in dev given the amount of
tests that have a QEXPECT_FAIL for the offscreen platform in qtdeclarative.
Change-Id: Ic914655c737c3b279c14a66220775f3c7a6cdab8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 8498d1a14b5a8392ee6b50a87b82f9d85d13193e)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Null- vs. emptiness of the separator is not significant for join(), so
skip the isNull() check in the conversion ctor of QByteArrayView from
QByteArray by using the named conversion function that exists for this
purpose instead.
Pick-to: 6.3
Change-Id: I6ef07cc9bcc0bc8b87ecadc5cfaac9793cfb1b77
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
... instead of waiting for Qt 7.
Found in API review.
[ChangeLog][QtCore][Potentially Source-Incompatible Changes]
[QByteArrayList] The join() overload set has changed. Code such as
qOverload<>(&QByteArrayList::join) will have to be rewritten,
e.g. using lambdas. We advise against taking addresses of library
functions other than signals and slots.
Pick-to: 6.3
Change-Id: I67449df9adc2efea7f1163034caa135f31f39e7c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The Clang backend of MSVC declares nullptr_t in namespace std there,
then expects to find it under ::std::nullptr_t to define a ::nullptr_t.
That breaks with a namespaced build, of course.
Fix by moving the QT_BEGIN_NAMESPACE to just before the first typedef
that declares a Qt-owned name.
Done-with: Marc Mutz <marc.mutz@qt.io>
Pick-to: 5.15 6.2 6.3
Fixes: QTBUG-95309
Change-Id: I56f2709c4664a7d0de84918f43b6d53cb3710612
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This class is universally supported by all Qt6-capable compilers.
Pick-to: 6.3 6.2
Change-Id: Ib03ed8f73fe656e47f4d0f8f50c3a8ff95b6d8d4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The loop for 32 bytes is left unchanged, but the tail operation for 16
to 31 bytes is replaced with an overlapped load-and-scramble. This
should make the operation even faster.
Also updated the key creation back to something similar to what Go does.
This massively improves performance as well as the bit spread. Histogram
for the bits in the hash value for the testcase from QTBUG-91739:
|| Bit || Before || After ||
| 0 | 35.0300% | 50.4800% |
| 1 | 42.5250% | 50.2400% |
| 2 | 46.0100% | 50.0000% |
| 3 | 67.5150% | 49.9400% |
| 4 | 56.5150% | 50.0000% |
| 5 | 51.9950% | 50.0000% |
| 6 | 58.9800% | 50.1400% |
| 7 | 55.9550% | 50.0000% |
| 8 | 41.9850% | 49.9200% |
| 9 | 69.9700% | 49.6400% |
| 10 | 68.4950% | 50.0000% |
| 11 | 37.4950% | 50.3000% |
| 12 | 61.9950% | 49.8200% |
| 13 | 53.4900% | 50.0000% |
| 14 | 63.0200% | 49.9800% |
| 15 | 54.9700% | 50.1000% |
Task-number: QTBUG-91739
Pick-to: 6.2.3 6.2 6.3
Change-Id: Icad7c1bad46a449c8e8afffd16cb7fe7ffd3584f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
[ChangeLog][QtCore][QHash] Fixed a bug in the qHashBits() function,
which affected the hashing of QByteArray, QString (and their View
classes), QLatin1String and QBitArray, which caused the hash to not
include the final 32 bytes of the data source. As a result, QHash
containers where the initial string was the same had a serious
performance degradation on x86 CPUs with AES support.
Fixes: QTBUG-91739
Pick-to: 6.2.3 6.2 6.3
Change-Id: Icad7c1bad46a449c8e8afffd16cb74dd43440f6c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We don't need to test for actually crossing a page boundary. It suffices
to check if we're in the upper half or the lower half of the page. In
the upper half, we load ending at the end; in the lower half, we load
starting at the current position. This way, it can never crash.
Pick-to: 6.2.3 6.2 6.3
Change-Id: Icad7c1bad46a449c8e8afffd16cb743e622b3405
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Took me a few seconds to figure this out, and I'm the author of the
class, so leave a comment for my future self (and anyone else).
Pick-to: 6.3 6.2 5.15
Change-Id: I65a7aa6f8abf9d671f7d9ba45400f19e0f46728f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When int is 32-bit, 0x80000000L is int-min, and (consequently)
negating it makes no difference, so MSVC warns about this. Instead of
using an L suffix, wrap the constant in Q_INT64_C(). Do the same for
similar large constants in the same block.
Pick-to: 6.2 6.3
Change-Id: Ib371b932792f170ab7db2e472a4283df3a205af3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The Boyer-Moore tables can be calculated at compile-time, and the
needles are long enough to make skipping worthwhile, even for small
haystacks.
Pick-to: 6.3
Change-Id: I3237812490367ed0491eb8d1667c6da67f38c517
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The new overloads mean that when passing QByteArrayView or
QLatin1String objects, we don't expand them into .data() and
.size() anymore.
Pick-to: 6.3
Change-Id: I0c898e0463d0bf81ce1f7d57e10e64f23bd84587
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
When trying to build qt3d examples with qmake and MinGW in the CI,
compilation would fail with errors like
In file included from
C:/MINGW1120/mingw64/x86_64-w64-mingw32/include/windows.h:72,
from C:\Users\qt\work\qt\qt3d\examples\qt3d\simple-cpp\main.cpp:63
include/winuser.h:2965:72: error: 'POINTER_INPUT_TYPE' was not
declared in this scope
What happens is that calling qmake on examples.pro loads
qt3d/.qmake.conf, which then loads qt_build_config.prf which then
defines the following definitions:
mingw: DEFINES += WINVER=0x0601 _WIN32_WINNT=0x0601
This limits usage of Windows API up to Windows 7, with later APIs
being unavailable.
Most .qmake.conf files were removed in qt repos, but We didn't remove
the .qmake.conf file (fb656c036d) for
qt3d because it's supposed to be buildable with CMake + Qt 6 as
well as qmake + Qt 5.
Bump the defines to the same Windows 10 version we use everywhere else
when building with CMake.
Amends 6652bf2353
Relates to d57a7c4171
Relates to fb656c036d
Pick-to: 6.2 6.3
Task-number: COIN-762
Task-number: QTBUG-92271
Change-Id: I833dfb6b0832d90a76d05ea14cd3807cb0d67ca9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To tool generates calls to qt6_add_resources instead, and we don't want
to promote the usage of CMAKE_AUTORCC.
Task-number: QTBUG-87643
Change-Id: I58458416514949a6ffc9b93c7eb6d24bc2ed01ca
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The pyparsing module's debug action properties have been renamed.
Check the existence of the attributes before assigning.
Change-Id: I8fff652304a0af215c56f54b63d613a1f6a5207a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The animateClick method is a QAbstractButton member, and neither
QCommandLinkButton nor QPushButton override it. The method is tested in
the QAbstractButton test, and 3a9b7d1f18648d7236664d3adfc65c009b01e668
made that test more robust. The previous, flaky version of the test was
almost duplicated here. They add no additional code coverage, so remove
them.
Pick-to: 6.2 6.3
Change-Id: I1fa988c1eabd5054193acb1f5fa1c81d29b3878d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
There's no class inheriting from ResultStoreBase (and likely won't be),
so the destructor was marked to be made non-virtual in Qt 7. For the
same reason, the internal members don't need to be protected, and the
class shouldn't have "Base" in its name. Add a note about it.
Task-number: QTBUG-99883
Change-Id: I00d7a96d99d2c326d29bd421235a15d68b4d4e5c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It was missing #if-ery on feature regularexpression for one test that
depends on it. One of its comments had a long line. Added some
annotations to make clear what's going on in messier tests.
Change-Id: I06d8748a134591f93b36029713e52ffd826a24dc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
One might want to build qtbase in Release, but qtsvg or some test in
Debug mode. Before if qtbase was configured as Release, there was no
way to override that.
Now we try to detect whether a custom build type was specified to
qt-cmake / qt-configure-module / qt-cmake-standalone-test /
qt-internal-configure-tests
Note mixing won't work on Windows due to different C/C++ runtimes.
Also, now we don't force set a single build type when a multi config
generator is used as well as one opts out via the
QT_NO_FORCE_SET_CMAKE_BUILD_TYPE variable.
Pick-to: 6.2 6.3
Change-Id: I6dc4325087ff7f905ad677d87b0267e2f3e4693f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This will show the CMAKE_BUILD_TYPE that was computed for a configured
repo or standalone tests, after the logic in
QtBuildInternalsExtra.cmake is executed.
Pick-to: 6.2 6.3
Change-Id: Ib8ffa2c7806a4c16385a2fcd4500f8a0f6a9aa88
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qSwap() is our wrapper around
using std::swap;
swap(lhs, rhs);
it needn't and shouldn't be overloaded.
ADL swap() should be, though, so qSwap(), std::ranges::swap() and all
the other adl_swap()s out there all find the optimized version.
Qt 5.15 has it correct, Qt 6 wrong. Fix it.
Can't pick to 6.2 because, while backwards-source-compatible, because
the generic qSwap() template provides the name for both qualified and
unqualified calls, it's not forwards-source-compatible: A new user of
ADL swap
// compile error w/o `using std::swap`, pessimization otherwise:
swap(dp1, dp2);
would break or performance-regress when going back to an older
version.
Pick-to: 6.3
Change-Id: I725949a4aa9ae438a182b4b7552ff2dced767e2f
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
To make the Qt conan package consumption more seamless for consumers
who use e.g. conan-center packages we should try to make sure that
"the default conan build profiles" people are using should work
with Qt conan packages as well.
This means that we should support the use case that when consumers
are not explicitly defining Qt specific build options, e.g.
-o debug_and_release=True
And the consumer build profiles/settings may contain e.g.
[settings]
...
build_type=RelWithDebInfo
In qtbase conan recipe this should translate to correct
'Options' specific to Qt's configure(.bat).
This change introduces a fallback in case Qt specific
options are not being passed. It sets the Qt specific
options based on the settings.build_type.
Pick-to: 6.2 6.3
Task-number: QTBUG-99571
Change-Id: I961570a100fadc03b8c423dcf0064ccc4be7ae6e
Reviewed-by: Toni Saario <toni.saario@qt.io>
The recipes in conan-center use True/False option values for common
binary options, for example:
- shared
- release
Currently the binary option values for Qt recipes use 'yes'/'no' values
which makes the consumption of Qt conan packages suboptimal.
Example:
$ conan install .. -o qtbase:shared=yes -o shared=True
After the change one can use:
$ conan install .. -o shared=True
The shared=True is applied to all packages in the dependency tree
including Qt now.
Adjust how the booleaness is checked for Conan options which are
wrapped with PackageOptionValue.
Pick-to: 6.2 6.3
Task-number: QTBUG-99558
Change-Id: I52e16d76418ac3c3e9d653e77287ae89248675d7
Reviewed-by: Toni Saario <toni.saario@qt.io>
Create macros that wrap the magic developed in
7d63efc16f and apply it to all
Q_DECLARE_METATYPE invocations that show up in Clang -ftime-trace for
a PCH'ed QtGui build.
Effects on compile times:
Clang 10 -ftme-trace:
$ ClangBuildAnalyzer --analyze qtgui-before.trace | head -n6
Analyzing build trace from 'qtgui-before.trace'...
**** Time summary:
Compilation (523 times):
Parsing (frontend): 628.3 s
Codegen & opts (backend): 304.5 s
$ ClangBuildAnalyzer --analyze qtgui-after.trace | head -n6
Analyzing build trace from 'qtgui-after.trace'...
**** Time summary:
Compilation (523 times):
Parsing (frontend): 546.0 s
Codegen & opts (backend): 304.4 s
GCC 11 time (bash builtin):
before:
$ time for ((i=0; i < 3; ++i)) do touch src/gui/painting/qpolygon.h ; ninja libQt6Gui.so; done
real 4m13,539s
user 49m24,416s
sys 3m18,177s
after:
$ time for ((i=0; i < 3; ++i)) do touch src/gui/painting/qpolygon.h ; ninja libQt6Gui.so; done
real 3m55,697s
user 45m19,941s
sys 3m7,370s
Task-number: QTBUG-97601
Pick-to: 6.3
Change-Id: Ia8e37a58937568a7ed21cfeb4b27274deca4d53b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
I can't test on Windows, so skipped the platform-specific code.
Pick-to: 6.3 6.2
Change-Id: Id13d4abc447ddd5d17fb67b670b83207877456f6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since by default QStyleOptionProgressBar is initialized with initialize
QStyle::State_Horizontal, the example shouldn't overwrite the state, and
instead OR other states into it. Otherwise, the progressbar will be laid
out vertically.
Pick-to: 6.2 6.3
Fixes: QTBUG-100067
Change-Id: Ibebda48a297af4a621719673033f8199b8bc7984
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
After QFuture continuations became non-copyable (see earlier commits),
we have to always use ContinuationWrapper to save the continuations
inside std::function, since it requires the callable to be copyable.
Optimize the wrapper, by storing the callable directly (instead of using
a ref-counted QSharedPointer) and introducing a fake copy-constructor
that makes sure that it's never called.
Pick-to: 6.3 6.2
Change-Id: I0ed5f90ad62ede3b5c6d6e56ef58eb6377122920
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is required to ensure that the continuation attached to a
QFuture returned by QtFuture::when* methods is cleaned in the destructor
of the associated QPromise, so that it doesn't keep any ref-counted
copies to the shared data, thus preventing it from being deleted.
Task-number: QTBUG-99534
Pick-to: 6.3
Change-Id: If4e2929b2e638d6b48c95f0aef9dc886066cedbe
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Continuations were using QFutureInterface to create and return the
associated future to the user. Attaching a continuation to the returned
future could cause memory leaks (described in an earlier commit). Use a
QPromise when saving the continuation, to make sure that the attached
continuation is cleaned in the destructor of the associated QPromise, so
that it doesn't keep any ref-counted copies to the shared data, thus
preventing it from being deleted.
Task-number: QTBUG-99534
Pick-to: 6.3 6.2
Change-Id: I52d5501292095d41d1e060b7dd140c8e5d01335c
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Capturing a QFuture in the continuations attached to it results in
memory leaks. QFuture's ref-counted data can only be deleted when the
last copy referencing the data gets deleted. The saved continuation
that keeps a copy of the future (as in case of the lambda capture) will
prevent the data from being deleted. So we need to manually clean the
continuation after it is run. But this doesn't solve the problem if the
continuation isn't run. In that case, clean the continuation in the
destructor of the associated QPromise.
To avoid similar leaks, internally we should always create futures via
QPromise, instead of the ref-counted QFutureInterface, so that the
continuation is always cleaned in the destructor. Currently QFuture
continuations and QtFuture::when* methods use QFutureInterface directly,
which will be fixed by the follow-up commits.
Fixes: QTBUG-99534
Pick-to: 6.3 6.2
Change-Id: Ic13e7dffd8cb25bd6b87e5416fe4d1a97af74c9b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Avoid some unnecessary comparisons and add more tests.
Task-number: QTBUG-99799
Change-Id: I3aee9f0b62461d38dadbe8e969444e1cd1f94e68
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Drive-by update one more for to ranged-for and make sure we don't create
the global statics on destruction.
Change-Id: I5e52dc5b093c43a3b678fffd16b5ff674dfd17ae
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Better code style. I need to optimize QCborValueRef::toString() to avoid
a round-trip through QCborValue.
Change-Id: I5e52dc5b093c43a3b678fffd16b5f1f99851cf5f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This showed up on a benchmark when the number of files in the directory
was way too big.
Change-Id: I5e52dc5b093c43a3b678fffd16b5ef9a938abc63
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This works around mismatch in threads starting and restarting QThreads,
and is safe since we don't need to establish a binding, and objectName
access in QThreadPool is locked behind a mutex.
Pick-to: 6.3 6.2
Fixes: QTBUG-96718
Change-Id: Id3f75e4f8344796ca658899645219fe3373ddd6d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Unnecessary. We can't read a directory's entries if it doesn't exist or
isn't a directory.
Change-Id: I5e52dc5b093c43a3b678fffd16b5edce70eb651e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
