When a QWidget was reparented, we would take care to reparent its
backing QWidgetWindow as well, into the nearest QWindow of the
new QWidget parent.
However we would only do this for the reparented widget itself,
and not any of its child widgets. In the case where the widget
has native children with their own QWindows, the widget itself
may not (yet) be native, e.g. if it hasn't been shown yet, or
if the user has set Qt::WA_DontCreateNativeAncestors.
In these scenarios, we would be left with dangling QWindows,
still hanging off their original QWindow parents, which
would eventually lead to crashes.
We now reparent both the QWindow of the reparented widget (as
long as it's not about to be destroyed), and any QQWindow
children we can reach. For each child hierarchy we can stop
once we reach a QWindow, as the QWindow children of that
window will follow along once we reparent the QWindow.
QWindowContainer widgets don't usually have their own
windowHandle(), but still manage a QWindow inside their
parent widget hierarchy. These will not be reparented
during QWidgetPrivate::setParent_sys(), but instead
do their own reparenting later in QWidget::setParent
via QWindowContainer::parentWasChanged(). The only
exception to this is when the top level is about to
be destroyed, in which case we let the window container
know during QWidgetPrivate::setParent_sys().
Finally, although there should not be any leftover
QWindows in the reparented widget once we have done
the QWidgetWindow and QWindowContainer reparenting,
we still do a pass over any remaining QWindows and
reparent those too, since the original code included
this as a possibility.
We could make further improvements in this areas, such
as moving the QWindowContainer::parentWasChanged() call,
but the goal was to keep this change as minimal as possible
so we can back-port it.
Fixes: QTBUG-122747
Change-Id: I4d1217fce4c3c48cf5f7bfbe9d561ab408ceebb2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit c956eb8eddb1b3608d7e3d332fbe55df5ec41578)
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 8ee25c66d934850eba4167246cdab2310704c45d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Amends commit 41f84f3ddb780ec751e3fc706dd242fc4a99de7a - QDate and
QDateTime declare fromString() methods only when feature datestring is
enabled. So their inline implementations should also be conditioned on
that feature.
Change-Id: I84fc877001d3fc97c6ca149864e4ad5a2dbabe87
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 1618ff825c2198705fedde9c284a0c52bcce5b89)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 28911a81d4bc109c740919c3c952ef9096946d4d)
Contrary to OpenSSL the new ciphers support in Schannel
would disallow all ciphers when the list was empty.
The pre-existing behavior was to use the default list.
Amends f7792d2b6d3d1e5dd47a8f6429b817b793bcfb9b
Change-Id: I0e79013ac86261c4afa4affb28cb1838177c12de
Reviewed-by: Tobias Koenig <tobias.koenig@kdab.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 2d521002ca024b71525036a0a6f5d02bb09b3ed7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 58991ca2ae2b92a96760fb781360caebc6c6fdc8)
This change introduced a regression for the case where the string is
just a little bit too large.
This reverts commit 79ac8b110ae998ad2545238536cb254197540b57.
Task-number: QTBUG-123339
Change-Id: I7b629450d88421201919d82a433d973f76328509
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
This reverts commit a05abede682db4ab20a7c1d9eb45a487e91d6a78.
Reason for revert: Causes QTBUG-123325
Change-Id: I251b67798af3d768db6f2836b52ded558c0c8211
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Commit 90bc0ad41f9937f9cba801b3166635f6f55e0678 ("QProcess/Unix: add
failChildProcessModifier()") added this line that set childStartedPipe
so that the failChildProcess() callback had something to write to. But
we left it set on exit from QProcessPrivate::startDetached(), which
caused the QProcess destructor to try and close it.
Noticed when debugging the issue for QTBUG-123083.
Task-number: QTBUG-123083
Change-Id: I6818d78a57394e37857bfffd17bbc41c8400270f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 0f56502fb6f062c6d2308198c93412c34525125b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit a2d67a2671f8b2ab96d4b458d80972c2bd83b3db)
Some libs don't necessarily have the lib prefix in their names,
3rd party libs and Qt for Python might have that, so no need to
always add that prefix to loaded libs is the lib name already
contains a .so suffix.
Fixes: QTBUG-123286
Change-Id: Ib65215d9b4410c5c9e00aa0642f48ab45c92fe03
Reviewed-by: Shyamnath Premnadh <Shyamnath.Premnadh@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
(cherry picked from commit 4bb4d015f7e855015f8dc32d658518d5ec3556bd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 2ba01c7ace47c7b8f4b9e1baf8e4b5e2eeb87703)
Before the qWaitFor() port from int to QDeadlineTimer, the
implementation constructed a QDeadlineTimer internally, passing int
timeout and Qt::PreciseTimer. The int overload that was retained for
source-compatibility, however, constructs the QDeadlineTimer without
the PreciseTimer flag, which is a behavior change.
Restore the Qt 6.6 behavior and pass Qt::PreciseTimer.
Amends fa296ee1dcf4c16fb6f242cf08949485e499fec3.
Change-Id: Ib8e5b912c74b70d32a77195edb0d2a30cd7c241d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 73c52ba2687c2035a40141f2a5236399f8331f4b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit d9da7c9362363e32d732370d5f340119d6fe9dd5)
Amends 269187bfa272f9456aad6a6233100d846915f175 which added the sleep
but just loading the main library.
This commit moves the delay before any library is being loaded. Also log
the fact the thread is sleeping and advertise how to use the env
QT_ANDROID_DEBUGGER_MAIN_THREAD_SLEEP_MS variable.
Fixes: QTCREATORBUG-30425
Change-Id: Ic1370e0b9fcce8c6074f768e5d94e5aa4a0a7824
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 0804109d686e0a99ab0de0f1c70e3422183c6e98)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 1fb2c58ef381101f2219af7f874f4007b163e90d)
According to QUIP-18 [1], all tools file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
[1]: https://contribute.qt-project.org/quips/18
Task-number: QTBUG-121787
Change-Id: Icd5d5be2e04819617e68ff142924de1773bebbad
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
(cherry picked from commit 7b6289a0358274ec3c37cabd5b7d7212508a4e8a)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit d289d35183fc900f6c5b34813d9c9b9a03caae27)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
According to QUIP-18 [1], all build system files
should be BSD-3-Clause.
The files in this patch are part of the build system.
[1]: https://contribute.qt-project.org/quips/18
Task-number: QTBUG-121787
Change-Id: Ibc6a60a9b009fab0c953e8e3269533c121e4511e
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
(cherry picked from commit bf1e76408e07ac175ee467c5095e88209d9a6ba8)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit d6414a02e95b589639b45925bc9363e65ee8a683)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This helps with the jdb debugging settling, and the native debugger
can hit breakpoints at the beginning of main() function or in case
of unittests at initTestCase() function.
By default in debug mode the delay is 1000ms. This value can be changed
with the environment variable: QT_ANDROID_DEBUGGER_MAIN_THREAD_SLEEP_MS
Fixes: QTCREATORBUG-30425
Change-Id: Ica0c6080c55468579a28eecf8f45cff68d99c3a8
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 269187bfa272f9456aad6a6233100d846915f175)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 76c6b71db41962005854fac57b09ca0907e2ed96)
By just moving the handling of the child process' desired target
directory below the initialization of either the signal mask and PThread
cancel state, without that "return".
Commit 52ed6af5277100ed5b9a4f4231b94013ce539a2c ("QProcess/Unix: merge
some code from startProcess() and startDetached()") introduced
QChildProcess and merged the functionality of PThreadCancelGuard into
it. But it added that "return;" to the code path failing to opendirfd()
the target directory, meaning that the QChildProcess constructor could
exit without calling disableThreadCancellations(), but the destructor
would still run restoreThreadCancellations() every time the opening
failed. And we have tests for that: setNonExistentWorkingDirectory and
detachedSetNonExistentWorkingDirectory.
For the cancel state, the uninitialized variable we ended up passing to
pthread_setcancelstate() was probably harmless, because the cancellation
state is almost always active and the variable would have been non-zero.
And we don't test pthread cancellation, so we would never notice the
problem.
But commit bd32c7d7055b436b8c33486a5b5ce1c29db77fd4 ("QProcess/Unix:
block all Unix signals between vfork() and exec()") introduced a block
of the Unix signals with the same uninitialized variable problem. Unlike
the PThread cancellation state, the original signal mask would usually
be empty, so the "restoration" would actually mask signals we wanted.
And one such important signal is SIGCHLD, used by QProcess/forkfd when
*not* using vfork semantics. This meant that tests that had a child
process modifier (meaning, they wouldn't use vfork semantics) would end
up timing out because we'd never get the SIGCHLD that told us the child
had exited.
Fixes: QTBUG-123083
Change-Id: I1362eb554b97dc012d02eab2dbca90b06728460e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 418dcf88f827effb2981dcd1699b395e2aeaac2f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 2b13207c2e408a6552b2486a1c90ad1d29e4c4b9)
Reduce the spacing between menu bar items and change
font size to 10pt.
Fixes: QTBUG-120639
Change-Id: Ic16e74f4a2426be6d6ef40904919d92785d96ce5
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit f75e554c6af7ea00bb5e6aa62a2af26350b67d98)
If the Android View is resized, the QWindow instantiated by it
should be resized accordingly.
Task-number: QTBUG-122626
Change-Id: I7bfbca149f927718d1e28cdabfa8759afbd06039
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Qt window loading is initiated either when the QtView is attached
to its Android window, or when the Android QPA plugin has been loaded
and is ready, depending on the order. Since the window attachment
happens in the Android UI thread, and the Android QPA plugin callback
happens in Qt thread, add synchronized block to make sure the execution
stays ordered.
Fixes: QTBUG-122626
Change-Id: Id476032f02aa8990432a02f62b6bf6237a17e7ac
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
The variadic templates are supposed to be removed from the
overload set when any of the parameters is a literal string type,
as otherwise we get conflicts with the legacy overload taking
class names and signatures as const char *. The detection of
a literal string types was missing a few specializations, so that
we ended up with the wrong overload being called, and class
names getting interpreted as method names instead.
Add the missing specializations, and add more test coverage
for using the old overloads.
Task-number: QTBUG-122235
Change-Id: I5488f2009c8f62d74fac6754844f57cf64011414
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Lauri Pohjanheimo <lauri.pohjanheimo@qt.io>
(cherry picked from commit 10afa38aa44231b3617984fdbca66d9699e2825f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
On Windows the "interface" is defined as "struct".
Do not #undef it to fix a unity build.
Task-number: QTBUG-122980
Change-Id: I9379c996d8b67b16a8b825af0ff3469111533291
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 1e836fff18ceaea8331711708bdc3d8ea0cc051e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The existing widget machinery works through mouse positions. In order to
correctly update state when a drag moves outside of a window it needs
to see a move outside of the window. When the platform drag leaves the
window a move to the outside of the window is now faked to not keep the
layout in the hovered state of the last move event.
Fixes: QTBUG-122944
Pick-to: 6.6
Change-Id: I348f5281a200b78e6be4f11b3c25339d052783a5
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit d7fe948fdb79e919065875410dba14275a2a7478)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
To not rely on transitive includes.
Change-Id: I116483f94bba4a6edb0a78941da676b1a3e6e1bd
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit a83248dd9fe9831c72c1781f465b74b6214832a5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
qt_add_qml_plugin has code to set a sensible install rpath for user
project qml plugins.
If Qt was configured without rpath support, we should not add any
rpaths to qt qml plugins:
- qt-computed rpaths added by qt_apply_rpaths
- user-project rpaths added by qt_add_qml_plugin
This is done by setting QT_NO_QML_PLUGIN_RPATH to TRUE as part of
QtSetup, effectively applying the option to any qml plugin that is
built by internal qt api.
User projects will still be able to use the default rpaths added
by qt_add_qml_plugin, even if qt itself was configured with no rpath
support.
Fixes: QTBUG-122687
Change-Id: I8178b527553dd00436d0abb3b44061ea16edc121
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 375f3869308fd01c276b17581ef827583550dba3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The check and variable name were incorrect after a refactoring.
Amends ba9623860056cbb75e426e27905f9c29b687cefa
Pick-to: 6.6
Task-number: QTBUG-84884
Task-number: QTBUG-90820
Change-Id: I33b6b81695a6352c7869ef6186e00881b47bd6f3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit aacc31815d40c8f5dbdd998536fb1fcd5f632221)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
P2447 has been merged in C++26, backport the same functionality.
This makes QSpan<const T> a proper replacement for a const QList<T>&
parameter, because now both can be built via a braced-init-list.
// void f(const QList<int> &l); // old
void f(QSpan<const int>); // new
f({1, 2, 3}); // now OK
This is, technically speaking, SiC: in the presence of both `f`
overloads, the code above would have called the QList one. Now instead
the call is ambiguous.
We've been there already -- this is QString and QStringView all over
again, and the solution is the same: get rid of the owning container
overload. I'd rather have this construction *sooner* rather than *later*
in order to minimize the fallout.
And just like QString vs QStringView, there's nothing really doable to
prevent instant-dangling situations:
QStringView v = getString(); // dangles
QSpan<const int> s = {1, 2, 3}; // ditto
except for using QSpan (QStringView) as a *parameter type only*.
Note that QSpan with dynamic extent was already convertible from
std::initializer_list through its ranged constructor. However this fact
alone doesn't unlock the above syntax. QSpan with a static extent was
also convertible for the same reason. (This is non-standard:
std::span's range constructor for static extents is explicit, but QSpan
doesn't follow that design choice and makes the constructors implicit
instead.)
Found in API-review.
Change-Id: I160ab5b292b0c2568cd9a7ad1b4430085f475c29
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 7f7b5ff3a1b617a3a1add1b1b6ad0718f0dcf143)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This reverts commit 7d18ad49a37440835bb38bd77bc4e0991387ada0.
Reason for revert: This changes the constructor from being a template
to being a normal function, so changes overload resolution. The commit
message gave no indication on why this is safe. Since it's just a nice
to have, revert instead of running the risk of breaking code.
Change-Id: Icd506e7221bb50c99f276f6a43c15403ec0be7a9
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
(cherry picked from commit ff7e5987ecdd09f87cfcdb4c42039214627dcdb6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We don't need a message like:
"Cannot load library nosuchlib: (nosuchlib: cannot open shared object file: No such file or directory)"
Change-Id: I01ec3c774d9943adb903fffd17b76599cea47502
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
(cherry picked from commit a6a56814702612d8981f594a6158d70a7928cb99)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Specifically, don't use it for either of the x86-64 ABIs (LP64 and
ILP32). The generic case below should work for everyone.
Fixes: QTBUG-122720
Change-Id: I01ec3c774d9943adb903fffd17b75fc79095e089
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 24245d2a85cbcd503816027067aa72995e3ac2ac)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
...when not using atomic.
On the non-atmic path the fb is passed in to drmModeSetCrtc.
Here we need a new call to it if a new QWindow gets created
after the previous one is destroyed. Previously this was
not done, so it ended up with Device busy errors. Atomic
does not need this since there the flip commit always
contains framebufferPropertyId.
Change-Id: Ie68152cad50438807ef45adfba65e74c8f30c956
Fixes: QTBUG-122663
Pick-to: 6.6 6.5
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit 818f8de64a2b1a7371ecb4bdd527b05343190582)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The target wrappers for qmake and qtpaths do not work on Yocto
builds and only create confusion when they are available in target.
Add option to disable their generation.
Task-number: QTBUG-122420
Change-Id: Ibb829cc846ad6c470fe29e746ade42fccaa33a6f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 762c56d65bf2bf430621f6bed8f6d96ee333e718)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This reverts commit bc3b18764aabf95a50a65e090863c54b6ac57e3e.
Reason for revert: QDeferredDeleteEvent changed the size in 6.7. It is
more important to protect the casual user that relied on the mention of
the otherwise undocumented class in the QEvent::Type::DeferredDelete
documentation than to be convenient for one tool, developed by experts
who know how to replace their dynamic_cast with a type() check and a
static_cast and/or extract information from an unexported class.
In fact, not even the autotest-export is needed, as there are no
mentions of the class outside of comments outside QtCore.
Found in API-review.
[ChangeLog][QtCore][QDeferredDeleteEvent] Made this undocumented class
private and unexported. You will still be able to see the definition in
qcoreevent_p.h, but you won't be able to create objects of the class
anymore.
Manual conflict resolutions:
- squash the tst_qapplication.cpp part of dev-only
13074a967f18ed348ab744f7ff831965607a6421 to avoid the linker error.
Change-Id: I8a47c69d356a0bef260e7987bc4eab96430e8072
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit e06c67d448a6b4684d9787e9c18ec12f884b7063)
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We used to look through the event queue in QCoreApplication::postEvent,
and if we found an existing DeferredDelete event for the receiver we
would compress the two events into one.
This was changed in 99b89d30fa5484c5d1f3cbda828648c28af4fb7d, as the
logic was causing O(n^2) for deleteLater, by using one of the bits
in QObjectData to track whether the object had already been deleted.
But it kept the logic for tracking this in QCoreApplication::postEvent,
and QCoreApplication::compressEvent would still do the work of deleting
the additional QDeferredDeleteEvents.
To avoid the unnecessary heap allocation of the QDeferredDeleteEvents
we can move the debouncing/compression to QObject::deleteLater().
We use the same mutex as in QCoreApplication::postEvent to guard
concurrent access to deleteLaterCalled.
A note has been added about the (preexisting) issue that the mutex
is not sufficient to prevent data races, as the deleteLaterCalled
flag is part of a bit-field, and we're not guarding any of our
other accesses to other bits.
As QDeferredDeleteEvents is private API, we can rely on no-one else
posting it than QObject::deleteLater(), which should be the case now
that tst_QApplication::sendPostedEvents() was fixed.
The documentation has been clarified as well. It's safe to call
deleteLater() more than once, but that's not _because_ other
pending events for the object are cleared. The latter behavior
is normal ~QObject() behavior. The documentation was probably
written at a point we didn't do any event compression at all
for QDeferredDeleteEvents.
Task-number: QTBUG-120124
Task-number: QTBUG-119918
Change-Id: I2a733095b7cb066ba494b1335aa40200c749cb0c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 13074a967f18ed348ab744f7ff831965607a6421)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The QHttpHeaders comparison was dropped earlier, and the current code
no longer needs to compare both header entry 'name' and 'value'.
Change-Id: I57a3003f0fd1d8ff867c970d5ec8a994a167ae88
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit c0e4b73743b9e9e8c3e116f9db9fe37bfcd89bf5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
... from a performance point of view.
Task-number: QTBUG-122020
Change-Id: I8a1558a46e74d740e330ad483454267f9922a5d5
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 9e26a8c0826f0914581c3e6f8e7970aed231c8e1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This saves memory and can speed up performance with
well-known headers.
The change consists of:
- Change the internal type of 'name' to a std::variant
capable of holding either WellKnownHeader-enum, or a QBA.
- Accordingly, add an equality operator.
- When headers are added (append, insert, replace) then
use WellKnownHeader as storage type when possible;
either use the function parameter directly if a WellKnownHeader
overload was used, or check if the provided string can
be converted to a WellKnownHeader.
- Convert other functions to use a more performant
lookup/comparisons.
Fixes: QTBUG-122020
Change-Id: If2452f6edc497547246fb4ddbace384e39c26c5e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 0c05d2b43ec5ab29efc3db2718289a5600da754c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As a prequel to make subsequent diff on the followup
commit (std::variant/union) smaller
Task-number: QTBUG-122020
Change-Id: Iaa5dd794dc7a9e33c2c43e459bf5dbd19afb3ba1
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit d3860b1b73799244f240dac8d03176636e367567)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
