Test case relies on transitive include and fails to compile if this
include chain is broken e.g. by disabling features.
Pick-to: 6.9 6.8
Task-number: QTBUG-136101
Change-Id: Id34c9f8ec86468aaf4dda116be8d46591ebd9185
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Once the platform window has been created it has had its chance to
set a default position and size, which is reflected back to the
QWindow. Destroying and recreating the window after that should
keep the position and size, even when those have been changed by
the end user via the system's window manager.
We were effectively doing this for size already, as initialGeomery
only applied a default size if the size was 0x0, but we were failing
to preserve the position. We now handle both cases explicitly.
[ChangeLog][QtGui] A destroyed and recreated QWindow will now maintain
its position and size, instead of allowing the platform window another
chance at setting a default position and size. Users of QWindow and
its consumers that reuses a single window for many "logical" windows
need to explicitly position and size the window for each "use".
Change-Id: Ib9a395295e6dfdc6db908e2c96be60046f462c30
Reviewed-by: Liang Qi <liang.qi@qt.io>
Use constexpr and const where we can.
Use Qt-defined string literals in a few more places.
Include GenericTime in a displayName() test, and make overt that we
are simply discarding the returns, with no further testing.
Pick-to: 6.9 6.8
Change-Id: Id120fdfe66267b01ff019fe13ac80f37390c106f
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We should prevent using the invalid plugin class names at CMake
configure stage already, so users receive the early error.
Fixes: QTBUG-135860
Change-Id: I259539f6cce70a035ccf458a62d9e5a02f238ef8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Place the calls to QTextDocument::toMarkdown() behind the same feature
flag as toMarkDown() function itself.
Pick-to: 6.9 6.8
Task-number: QTBUG-136101
Change-Id: I7468f6172cab613695504d7c50075169b46c4bc9
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Put both declaration and definition of tst_qimage::mirrored() behind
the same deprecation flags.
Pick-to: 6.9
Task-number: QTBUG-136101
Change-Id: Ib54ee21f7944f1e2b7f9fe35aea9fd8d9e908f95
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Amends commit d064c26d2c1fb1f78013031a83b661ef6f74ce21, which introduced
qt_encodeFromUser(). As far as I can tell and test, only the space
character was an exception, due to this code in qt_urlRecode():
if (!(encoding & QUrl::EncodeSpaces))
actionTable[0] = DecodeCharacter; // decode
That meant that encoded spaces was an opt-in, not an opt-out, but is not
the default in the defaultActionTable. This was missed in the new
function.
Fixes: QTBUG-135949
Change-Id: Ic8d2adac5c32f858748bfffd5654aac3c7a2f782
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
QMap/QHash::asKeyValueRange() returns a QKeyValueRange, which is a
range, but in some cases it doesn't satisfy viewable_range:
https://eel.is/c++draft/range.refinements#6
This causes reasonable code to fail to compile:
map.asKeyValueRange() | std::views::transform(...)
The reason for this is that, when called on a lvalue map,
asKeyValueRange() returns QKeyValueRange<Map<...> &>. This isn't a
viewable range: it's not a view itself, it's not a lvalue reference to
range, and it's not movable.
The last bit is actually a mistake, because QKeyValueRange<Map<...> &>
contains a reference, and thus it's not assignable. Fix it by making it
contain a pointer instead.
In principle this has ABI implications because we're making the type POD
(from non-POD), and this would allow usage of the tail padding on
Itanium. I am 100% sure that no-one is inheriting from QKeyValueRange.
We can also go a step further and decide to make QKeyValueRange a range
*view*, because it is -- it satisfies all the semantic concepts.
To elaborate, there are two different QKeyValueRange implementations,
one for lvalue maps (stores a pointer to the map) and one for rvalue
maps (moves the map into the range). Conceptually, they map to ref_view
and owning_view in the standard library.
For now I'm only making the QKeyValueRange<&> specialization for lvalue
maps a view. The other one in principle may satisfy the range view
requirements (as the containers are COW, so copy is actually O(1)) but
this is more questionable. A possibility would be to make it move-only,
but that's an API break.
To make QKeyValueRange<&> a view I'm inheriting from view_base, which an
empty class and thus doesn't affect ABI. (I'm not inheriting from
view_interface in order to avoid changing the API between the two cases
above.)
This work unveiled two problems in the implementation of QKeyValueRange.
The first was that the the deduction guides were actually unused for the
const-lvalue argument. This is because user-defined deduction guides
are added on top of the ones implictly generated by the compiler. The
primary template constructor was used to synthesize a deduction guide
that deduced a non-reference qualified T; the result was that a const
lvalue map would yield a mutable range over a copy of the map (!).
Fix this by getting rid of the deduction guides and explictly specifying
the template arguments of QKeyValueRange.
This fix in turn adds a problem for const rvalue maps (unlikely). The
idea in this case would be to move the map into the QKeyValueRange: the
range stores a map object, initialized by moving the source map.
For a const map source, the stored map should be const as well. But that
makes the range not movable (this is the point of things like
movable-box in the std), and therefore not a view. Since this is a
fringe case, I'm dropping the const for the inner stored map, so one can
effectively realize a mutating iteration over a const rvalue source map.
Task-number: QTBUG-105465
Change-Id: I70161029799376fd369e0332461a8a50e6062892
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QAbstractSlider::sliderChange() is not a signal, but a protected
function, carrying an enum (also protected) to inform subclasses about
changes in the base class.
A user reported (QTBUG-135597) that in 5.15 the function was not
called for SliderOrientationChange. A prior test addition confirmed
that this bug is in all active branches.
Add the missing call in setOrientation().
This _should_ replace the update() call, because the default
sliderChange() implementation already calls it (and setPageStep(),
e.g., relies on this behavior), but since SliderOrientationChange was
not emitted since Qt 5.0, I minimize regression risks and keep the
update() call, just in case a user wrote code where they forgot to
call Base::sliderChange() for SliderOrientationChange (and this never
showed because we never "emitted" that, up to now). The duplicate
update() calls will be merged by Qt's event loop, so are harmless.
A dev-only follow-up change will remove the update().
[ChangeLog][QtWidgets][QAbstractSlider] Fixed the missing "emission"
of protected sliderChange(SliderOrientationChange).
Amends the start of the public history.
Pick-to: 6.9 6.8 6.5 5.15
Fixes: QTBUG-135597
Change-Id: I4545d47d315a98a9a51134901a00fa369f720754
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We fixed the first line of defense in
03d1e81516be9af37fa08900f9a2d88d34abc4df, but that commit didn't rule
out ndelta == INT_MIN, in which case -ndelta overflows a few lines
below.
Coverity pointed this out.
Add a check that exposes this problem to ubsan, and avoid the overflow
by using qMulOverflow<-1>()¹ and not scrolling when it overflows, but
emitting a qWarning().
¹ There's no qNegateOverflow()...
When state == QHeaderViewPrivate::ResizeSection, we assume that
everything happens on the actual screen, which has physical limits to
the setOffset() argument, and therefore these arithmetic operations
don't need to be protected.
I fully expect that this will just be a rat's tail, one we can only
hope to control by using Peppe's safe integers everywhere, at which
point we've probably blown our executable code size out of any
proportions. So leave it at this, for the time being.
Amends 03d1e81516be9af37fa08900f9a2d88d34abc4df.
Coverity-Id: 479557
Pick-to: 6.9 6.8 6.5
Change-Id: I2e31fc9be21e7d59563b67f3cd26c29dcea61b55
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This fixes an annoying warning with MSVC where it did already compile
iterator <=> iterator
by way of the deprecated operator*(). GCC and Clang did not compile the
above, though they do compile the other ordering operators.
Fixes: QTBUG-120924
Change-Id: Ie13bf48bc506e7dd719efffdeae55f0735148976
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Rym Bouabid <rym.bouabid@qt.io>
The rest of the framework uses cleanup callbacks in a way that implies
that manually triggering the callbacks will lead to problems:
components such as QQuickWidget register cleanup callbacks to get
notified about the destruction of the QRhi. These callbacks should
not be invoked at arbitrary times.
There is no usage of this function anywhere in Qt. Remove it.
Slightly extend the autotest by exercising the keyed registration
functions as well.
Change-Id: I88f1a1e9bc5a642b8e8b6238fe198f123bd55978
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Blacklist tst_QFileDialog::completer on vxworks as it is preventing the
integration of other patches by failing too often.
Task-number: QTBUG-135963
Change-Id: Ie127801fc02d7c74ae0de4602ee0ea4b9e5c14c2
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This is required to make sure we resume the wasm instance
when a promise resolves. As a bonus QWasmSuspendResumeControl
already implements the JS -> C++ callback mapping, and
we can removed the fixed-4 ThunkPool which the current
implementation is using.
The implementation is straightforward, where the only
snag is that cleanup must be done in the finally callback.
Implement Promise::all by calling JS Promise.all(). This
function returns a new Promise, which we can adopt.
Make two changes to the test:
- remove throwInThen(): We no longer support propagating
JS exceptions from the then() handler to the catch function.
(catching a rejected promise still works). As far as
I can see this functionality is not used in qtbase.
- In finallyWithThen(), change shared_ptr<bool> to plain
pointer. This works around a (mysterious) issue where we
were not getting the correct value when reading from the
shared_ptr.
Change-Id: I8fb11b66ecba74f80708bd39eeeac59bb62f3786
Reviewed-by: Lorn Potter <lorn.potter@qt.io>
Even when it doesn't have a transient parent Qt knows about.
The surface might get a parent assigned externally through XDG Foreign.
Change-Id: I21dbfd00aa0ff78e26ce4c111fe260f18b9dc905
Reviewed-by: David Redondo <qt@david-redondo.de>
Reviewed-by: David Edmundson <davidedmundson@kde.org>
The test fails almost daily.
Task-number: QTBUG-119205
Pick-to: 6.9 6.8
Change-Id: Ice5d14701cc72cd6b0a0fb73bf85b5edddd019f6
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Blacklist tst_QFileDialog::clearnLineEdit() on vsworks as it is
preventing the integration of other patches by failing too often.
Task-number: QTBUG-135966
Pick-to: 6.9 6.8 6.5
Change-Id: I9a2b9596a9d4783bcc7307c31c5faf8353f49257
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Tell me this isn't confusing:
Got keys from plugin meta data ("QMYSQL3", "QMYSQL", "QMARIADB")
QSqlDatabase: driver not loaded
QSqlDatabase: available drivers: QSQLITE QMARIADB QMYSQL QMYSQL3
This also merges the two messages into a single line, which is nicer for
rich logging environments.
Pick-to: 6.8 6.9
Change-Id: Ieb80c6571213dddc518bfffdb6c86632df8f932c
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Amends 353ce5344fbde5a6cecbdd2c131e1cf0f4b7f383 after which QMenu::popup
returned early and without showing the menu if none of the actions had a
valid geometry in the menu.
This broke use cases where QMenu was used as a regular container widget
with child widgets (possibly in a layout). To fix this, take the result
of QWidget::childrenRect() into account, and only return early if that
rect is also empty.
Task-number: QTBUG-129108
Fixes: QTBUG-135933
Pick-to: 6.9 6.8
Change-Id: I05977044411df236146bb81dc08a30c176dfb6cb
Reviewed-by: David Faure <david.faure@kdab.com>
Two consecutive clicks on different windows should not be recognized as
a double-click event. Add window tracking to ensure double-clicks are
only detected when they occur within the same window.
Changes:
- Add static QWindow tracking for last pressed window
- Add window equality check in double-click detection logic
- Update window tracking after each mouse press event
- Add test auto test case
Fixes: QTBUG-134721
Change-Id: I0ca8460a447ca27b04f3d545176d478c90f6b830
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Avoid the duplicated data tags in removeAt() tests by adding the
orientation to the tag.
Pick-to: 6.9 6.8 6.5
Fixes: QTBUG-135294
Change-Id: If31d719e4a9b1c90e591cedc149848bbb9c99657
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
So far, we have been destroying pending posted events during thread
shutdown only as part of ~QThreadData. QThreadData is reference counted,
and ~QThreadPrivate releases the reference count.
However, any QObject living in a thread also holds a reference to the
QThreadData. If any of those objects are only destroyed when a posted
event is processed, then we have a cyclic reference problem.
This might be a problem with DeferredDelete events that are posted after
a QThread has exited its event loop. It does manifest as a problem with
QSingleShotTimer, which is temporarily owned by a posted event object.
As long as that event object is in the queue, the reference count of
QThreadData never drops to zero as the QSST instance holds a reference.
So the event never gets destroyed, and we end up leaking both.
To fix this, explicitly clear all pending posted events during QThread
destruction as well, not only during QThreadData destruction. Once the
QThread is destroyed, nothing will process those events. We still clear
the posted events during QThreadData destruction, as QThreadData might
get destroyed when other objects release their reference count on it.
This fixes a somewhat contrived problem in our test scenario, and the
change is not without risk, so not cherry-picking this to any stable
branch.
Change-Id: I488c1d3137ce83f1c34596e1041c22759825be18
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QSingleShotTimer instances are usually destroyed when they receive their
QTimerEvent, and otherwise are children of the creating thread's event
dispatcher so that they do get destroyed even if they never fired.
However, if the receiver object lives in a different thread than the
thread that started the timer, then we move the QSST instance to
that thread to make sure that it starts in the right thread. We then
reparented the QSST instance to nullptr (it can't continue to be a
child of the creating thread's event dispatcher), and connected to
QApp::aboutToQuit as a fall-back in case the timer never fires.
This has two problems: if the timer never fires (e.g. because the
receiver's thread stopped before the timeout), then we created a
soft leak (until aboutToQuit). And since the QSST instance was
moved to the receiver's thread, the connection to aboutToQuit()
is always queued, and also never got processed if the thread was
stopped before (especially since we connected to deleteLater(),
which would require another event processing cycle). So in
practice, we ended up with a hard leak.
To fix this, we have to reparent the QSST instance to the event
dispatcher of the receiver's thread. We can do that reliably
once the receiver thread processes events. Simplify the code to
replace a meta-call with a posted event to ourselves, receiving
which starts the timer (or immediately fires timeout if it has
taken long enough to get there). To avoid memory leaks in the
unlikely case that this posted event never gets delivered (e.g.
because the thread is shutting down already), give that event
ownership of the QSST instance until the timer is started.
This turns out to be leaking anyway on most platforms, which
requires further investigation.
To be able to reparent safely away from a parent in a different
thread, clear the sendChildEvents flag first.
Amends 87535e4e4337596066258e361143cb9906e89512.
Fixes: QTBUG-135636
Pick-to: 6.9 6.8
Change-Id: I8188160d54cfb63cb1765c5de8a6c0728dabb7e5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QVector instead of QList is currently still treated specially, being
considered normalized even if a signature piped through
normalizeSignature() would have changed.
We'd like to get rid of this special treatment, so add some tests for
invokeMethod() + Q_ARG, which we should continue to support.
Pick-to: 6.9 6.8 6.5
Task-number: QTBUG-135572
Change-Id: Ie09c80d2a8603a268859f395797196013efd8c0f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
tst_QSizeGrip::hideAndShowOnWindowStateChange is flaky on Ubuntu where
the widget is not set to fullscreen when it should. Wait for the the
widget to be exposed when shown the first time.
Fix flakiness on Ubuntu 24.04
Pick-to: 6.9 6.8 6.5
Change-Id: I9f5ea9ebb58c7505f841e5420dd2c15e5f0f2799
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Credit to OSS-Fuzz, this fixes issue 406541912. When rendering the svg
image from that report, an integer overflow happend while calculating a
QRect which is empty anyway. To avoid that, return an empty, default
constructed QRect instead of calculating further.
Picking back to 6.5 which is the oldest maintained version which
contains this function.
Pick-to: 6.9 6.8 6.5
Change-Id: I1a0d1310c55f7be613a6292f36481ac7c7e5b56f
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
These were using an offset of 123456 seconds = UTC+34:17:36, which is
outside our supported range. This wasn't actually causing a problem,
as it wasn't being checked, but we should stay within 16 hours of UTC.
In the process, modernize the use of strings involved in its tests and
change an initial value to something further from what shall overwrite
it, rather than a neutral value.
Pick-to: 6.9 6.8
Change-Id: Ife4e082f1f00665d3203641508f5d30b34aaae75
Reviewed-by: Magdalena Stojek <magdalena.stojek@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Disable tst_qdrag test itself, and put proper feature
guards in tst_event test.
Fixes: QTBUG-135806
Pick-to: 6.9 6.8
Change-Id: I80e41538488ba1df230551a97f18c8266c01bdb5
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
MSVC is pedantic that read() (a POSIX function) is not an ISO C function
so insists that we use the underscored version. As if Microsoft followed
that rule for their own APIs...
Amends e6a6757c1485d09a4b7a124d67260f06d8022fef.
Pick-to: 6.9 6.8
Change-Id: If51fd8564a3c415e1f7efffd7fde18a830c97e3b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Just comparing the constData() of two QBAs fails to check the sizes
match, and only compares up to the first '\0' byte; but QCOMPARE()
will also check size and checks all bytes. It's also perfectly capable
of comparing a QBAV to a C string literal (by turning the latter into
a QBAV), so save some allocations by doing that. Some tests were
overtly comparing both size() and constData(), but of course the
latter still only compared up to the first '\0' byte, still. So also
replace such pairs with a straight QGA comparison.
One test genuinely used a constData() comparison because it was
testing streaming of the constData(), so hadn't streamed size info and
thus wasn't reading it back again. Record that this is why that one
remains testing constData(), to save future readers wondering.
At the same time, test a QBuffer's (read-only) .data() in preference
to its (mutable) .buffer(), so it's clear (because we use the latter)
when we actually need mutating access to the raw data. (One test does,
with .buffer().clear(), indeed do that.)
Change-Id: I2b565469456bde9c003894abc8128ec5bc38a370
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qDebug() why no target has been found for a gesture.
Correct wrong function names in debug output.
Use __FUNCTION__ macro instead of spelling function name out.
Adapt QTest::ignoreMessage() calls in tst_gestures.cpp to also use the
correct function name.
Task-number: QTBUG-129754
Change-Id: Ifabf512215934ee984bcb8c9d0c2463342d77c07
Reviewed-by: David Faure <david.faure@kdab.com>
If the interface has a method with a specified return value, the
generated adapter will contain a code like:
bool out;
QMetaObject::invokeMethod(parent(), "Func", Q_RETURN_ARG(bool, out));
return out;
In this case Q_RETURN_ARG macro makes sure that the variable `out` is
properly initialized before being returned from a function, but only
if invokeMethod() call is executed successfully.
Update the generator to zero-initialize (or value-initialize) the
return variable, so that it returns some reasonable value even if
invokeMethod() fails.
Extend the unit-tests to make sure that the generated adapters always
initialize the return variables.
Coverity-Id: 479703
Pick-to: 6.9 6.8 6.5
Change-Id: I4d15ccc6844b5ca454ab9f0cf72fd8e3f0c1b704
Reviewed-by: Matthias Rauter <matthias.rauter@qt.io>
tst_QApplication::applicationPalettePolish() is blacklisted but does
not seem to fail anymore.
Unblacklisting the function.
Fixes: QTQAINFRA-6906
Pick-to: 6.9 6.8
Change-Id: I14b8c4e8e1e94c3ff077f7d91ee8f97c031d5b6d
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
I am using version 1943 and some section in the test that have been
marked as not working up until version 1942 are not working with 1943
either. I adjusted the respective sections to also exclude 1943.
Change-Id: I9f0ed1c1dba919d98772d45216f16857983978cd
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The creation of the ExternalRefCountData was published with
testAndSetOrdered() but the loadRelaxed() would only load the pointer
value, not the effects of the constructor.
Pick-to: 6.9 6.8 6.5
Fixes: QTBUG-135640
Change-Id: I3acbc51e763e8a291be3f7036e0d9cd3965a2ce8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
[ChangeLog][CMake] qt6_import_plugins doesn't have any effect anymore on
plugin deployment with the CMake deployment API on Linux.
[ChangeLog][CMake] qt6_deploy_runtime_dependencies now supports the
following plugin selection flags on Linux: INCLUDE_PLUGINS,
INCLUDE_PLUGIN_TYPES, EXCLUDE_PLUGINS, EXCLUDE_PLUGIN_TYPES.
Before this patch, we were deploying the plugins of every Qt module we
discovered when walking the dependencies of the target to be deployed.
That doesn't work if the target links against a shared library that
privately links against another Qt module, i.e. QtMultimedia like in the
bug report.
We need to take into account the Qt modules that are discovered when
retrieving the runtime dependencies at deployment time and deploy their
plugins.
Also, we now run file(GET_RUNTIME_DEPENDENCIES) and plugin discovery in
multiple passes. Every pass might discover new Qt plugins whose runtime
dependencies must be resolved. We stop if a pass did not discover new
plugins or after a certain number of passes.
Plugin discovery works like this:
- identify the Qt modules within resolved libraries,
- read the plugin types for the module from the corresponding,
module JSON file in Qt's installation,
- glob the files in Qt's plugins directory,
- select the files according to the plugin types from the Qt modules
and the INCLUDE.../EXCLUDE... arguments passed by the user.
We also read the default QPA platforms from modules/Gui.json and deploy
those.
Fixes: QTBUG-117731
Change-Id: I62ec96ab6de8327941c4c5a0ba83fd89f1733768
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Large graphical Qt applications heavily rely on heap allocations.
Jemalloc is a general-purpose malloc(3) implementation designed to
reduce heap fragmentation and improve scalability. It also provides
extensive tuning options.
Add a -jemalloc configure option, disabled by default. When enabled, Qt
and user code link to jemalloc, overriding the system's default
malloc().
Add cooperation with jemalloc for some Qt key classes: QArrayData (used
by QByteArray, QString and QList<T>), QBindingStoragePrivate,
QDataBuffer (used by the Qt Quick renderer), QDistanceFieldData,
QImageData, QObjectPrivate::TaggedSignalVector, QVarLengthArray.
This cooperation relies on two jemalloc-specific optimizations:
1. Efficient allocation via fittedMalloc():
Determine the actual allocation size using nallocx(), then adjust the
container’s capacity to match. This minimizes future reallocations.
Note: we round allocSize to a multiple of sizeof(T) to ensure that
we can later recompute the exact allocation size during deallocation.
2. Optimized deallocation via sizedFree():
Use sdallocx(), which is faster than free when the allocation size
is known, as it avoids internal size lookups.
Adapt the QVarLengthArray auto tests on capacity.
Non-standard functions docs are at https://jemalloc.net/jemalloc.3.html
[ChangeLog][QtCore] Added optional support for the jemalloc allocator,
and optimized memory allocations and deallocations in core Qt classes to
cooperate with it.
Change-Id: I6166e64e66876dee22662d3f3ea3e42a6647cfeb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QPointer is used to track whether a QObject is still alive, and so
it's unsurprising that checking whether the pointer is null is
sometimes done in situations where the QObject is already in the
process of being destroyed and therefore already demoted from T, the
QPointer template argument, to some base class.
Because of the way we made QPointer SCARY¹, calling data() will cast
from QObject* to T*, which is UB if the T was already demoted.
It's hard to fix this in the general case, but the various ways to
spell isNull() should all be equivalent to isNull() (which does not
cause UB, because it doesn't cast).
This patch fixes the relational operators against nullptr and adds an
explicit operator bool() so that if (p) and if(!p) no longer have to
go through (implicit) operator T*(). This does not appear to cause
disambiguities, so it's SC.
Don't document the operator, it's an implementation detail (and not
documenting it lets us pick it back). A follow-up will add the
documentation for 6.10+.
Add tests, even for stuff that's currently still UB (but marked by an
early return). A follow-up patch will try to make as many of these
other operations non-UB as possible, too.
¹ Originally 3f7741fbe7ab4140f8f971c0cf88bb04e7feea6b, then changed in
cc7239da8d1ab95e68e12a64df3ca3051419cb34 and
351c738fc4586bf354c9363fb78e190bdfca4617.
Amends the commits mentioned in the footnote.
[ChangeLog][QtCore][QPointer] For `QPointer<Derived> p`, `!p` and
comparing `p` to nullptr no longer perform invalid downcasts when the
object held in `p` is in the process of being destroyed and has
already been demoted from Derived to one of its base classes. Before,
these expressions invoked data(), which casts from QObject* to
Derived*, a cast which is invalid.
Pick-to: 6.9 6.8 6.5 5.15
Task-number: QTBUG-135626
Change-Id: I1b59062345e1b6933958c7e030d9253d69e7591c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When we insert a new row where the row type is an associative container,
the resulting row holds no data, and the QVariant we get from data is
invalid. So far we have QEXPECT_FAIL'ed the test that checks if the data
from a new row is valid. This is misleading; there is a valid map in the
row, which is what we want to test.
Instead, connect to the rowsInserted signal to populate the new row(s)
with (empty, but valid) data.
Change-Id: If89e30c2944581bd0059f908e2dfb956c655f34f
Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
The tree tests are passing now, presumably because we instantiate
the model explicitly in 8edabea2a76192788d30afc22e2ebcb560195401.
Change-Id: I08749311034b34ec958b163c1b19105d847309e9
Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
Events of type QEvent::NonClientAreaMouseButtonDblClick have to be
QMouseEvent, not just QEvent, as this test function did.
Says UBSan:
qdockwidget.cpp:1715:36: runtime error: downcast of address 0x7ffea5257d10 which does not point to an object of type 'QMouseEvent'
0x7ffea5257d10: note: object is of type 'QEvent'
3d 7f 00 00 c0 2b dc f4 3d 7f 00 00 b0 00 00 00 01 00 00 00 49 c1 02 3b a1 90 45 7c 20 17 03 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QEvent'
#0 0x7f3e1bcb0633 in QDockWidget::event(QEvent*) qdockwidget.cpp:1715
#1 0x7f3e1a262351 in QApplicationPrivate::notify_helper(QObject*, QEvent*) qapplication.cpp:3309
#2 0x7f3e1a2e374a in QApplication::notify(QObject*, QEvent*) qapplication.cpp:3259
#3 0x7f3df1e0ca4a in QCoreApplication::notifyInternal2(QObject*, QEvent*) qcoreapplication.cpp:1111
#4 0x7f3df1e0f453 in QCoreApplication::sendEvent(QObject*, QEvent*) qcoreapplication.cpp:1551
#5 0x5599b850aeee in tst_QDockWidget::titleBarDoubleClick() tst_qdockwidget.cpp:869
Fix by creating a minimal QMouseEvent instead. This is a hot-fix to
get rid of the UB. I can get away with passing senseless parameters to
the QMouseEvent, because the test worked (except for the UB) for even
a QEvent. A proper fix should use a proper QMouseEvent. Created
QTBUG-135410 to track the issue.
Amends the start of the public history, but not picking back. The
eventual fix for QTBUG-135410 should first revert this hot-fix, and
then pick the proper fix to all then-active branches.
Task-number: QTBUG-135410
Change-Id: I188fb5b7d7bdab0432a4877c1948dc0c384a658a
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
In Android's manual URI content test, there is a test case for moving a
file to another directory. While the function works and the file is
moved correctly, the URI is no longer usable after this operation. The
file must be reopened with a new URI.
This commit updates fileOperations test case to use the new URL after
moving file to another directory
Pick-to: 6.9 6.8
Fixes: QTBUG-134881
Change-Id: I114d76d6851815e7ee3d94ddc28d677d7c1ccea9
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We want tst_qfloat16 to be built in C++20 mode, even if Qt itself is
not built in C++20 mode, which means we can't use QT_FEATURE_cxx20 as
check in tst_qfloat16's CMakeLists.txt.
In addition, even if the compiler supports C++20, the standard library
may not support all features we need. Specifically, due to the
deployment target of macOS being 12 we can't rely on std::to_chars
being available, as is only available since macOS 13.4.
This patch introduces a separate QT_FEATURE_cxx20_format, and
adjusts the tst_qfloat16's CMakeLists.txt to use this feature.
Note that we intentionally do not add QT_FEATURE_cxx20 as a
hard condition to the new check, because it might be disabled
during the Qt configuration, but we still want the test to be
built in C++20 mode.
Note also, that we cannot use the QT_CONFIG(cxx20_format)
check in the qtformat_impl.h header, because the std::format
support is header-only, and user project might be compiled
for a different minimal macOS version, so we do not want to
rely on the Qt-specific config.
Pick-to: 6.9 6.8
Change-Id: Ibc43d243dbb24fcb922647fe2d90f61491144eb7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QAbstractSlider::sliderChange() is not a signal, but a protected
function, carrying an enum (also protected) to inform subclasses about
changes in the base class.
A user reported (QTBUG-135597) that in 5.15 the function was not
called for SliderOrientationChange.
Add a test that verfies that the function is a) called for all other
enum values and b) add XFAILs for the (still) missing
SliderOrientationChange.
Amends the start of the public history.
Pick-to: 6.9 6.8 6.5 5.15
Task-number: QTBUG-135597
Change-Id: I959077f030976937dd279897748025afa06e74dd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Allow both model types to have a policy, and unify the policy API
to always pass the row we operate on by reference (as it must never
be nullptr).
Add test coverage for passing models and rows as pointers, wrapped
references, shared pointers, and unique pointers.
Change-Id: I4797dc4c26fb1676e851df62dae4f8a382cec6fc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
