After removing the QTreeWidgetItems from the QTreeWidget, they have no
parent anymore, and so no-one deletes them and they're leaked.
Add a vector<unique_ptr> to hold such items until the end of the
function. This is the minimally-invasive fix. If we were to delete the
items right after removeChild(), we might be changing the test, and if
we deleted them only at the end of the function, we'd still be leaking
them on a failed QCOMPARE().
Amends 1d799e9108.
This doesn't completely fix tst_QAbstractItemView; it still suffers
from the QScroller leak, QTBUG-135055.
Pick-to: 6.8 6.5
Task-number: QTBUG-135055
Change-Id: I2d3c661d5331ae33bb945f850fccdaa934f7a2dd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit 9ea9818eeb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QObject parents own their children, but not the other way around. So
the parent-less QWidget *parent created on the heap was leaked.
To fix, create it on the stack instead, but for that to work, it must
be declared _before_ its eventual child, otherwise the parent would
delete the child as a QObject child, followed by the compiler deleting
the child as an automatic variable = double-delete.
Amends ab536c3c71.
Pick-to: 6.8 6.5 5.15
Change-Id: Ibccf229fc056665e3b854e1a94e1f4b5bf7a89e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit 3c7719f2c2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QLineEdit::setCompleter() doesn't reparent the completer under the
line edit, so this test function leaked the object (and with it,
"22260 byte(s) leaked in 214 allocation(s)"; seriously, what does a
QCompleter do with 20+KiB of memory!?).
Fix by giving the completer the line edit as parent.
Amends 24859d7dea.
Pick-to: 6.8
Change-Id: Ic14a32c982dd4c75ae527188e53a7f20af714038
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit bdd2cefcf3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QActions can be added to many widgets at the same time, so addAction()
doesn't reparent them.
Having no (QObject) parents, the QAction objects in this test were
consequently leaked.
Fix by giving them parents.
Passing `this` would have worked, but has the drawback that if you run
the test twice (by naming it twice on the command line), actions with
identical shortcuts would accumulate and potentially change the
result. Therefore, add an automatic QObject to act as their
parent. This is the minimally-invasive fix.
Amends 198225983d.
Pick-to: 6.8 6.5
Change-Id: I59881b10076ba790502483242f620aeed3e99575
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit ad0d6be778)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QActions and QMenus can be added to several widgets, so addAction()
and addMenu() don't transfer ownership of their argument.
Having no (QObject) parents, the QMenu and QAction objects in this
test were consequently leaked.
Fix by giving them parents.
Amends 493a85a9e4.
Pick-to: 6.8 6.5
Change-Id: I2c48a55de26c5ed487d2e42e50e0b2fbb6ddf98c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit 850d352111)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
C:/qt/qtbase/src/3rdparty/D3D12MemoryAllocator/D3D12MemAlloc.cpp:144:32: error: unknown warning group '-Wnonnull-compare', ignored [-Werror,-Wunknown-warning-option]
144 | #pragma GCC diagnostic ignored "-Wnonnull-compare"
| ^
C:/qt/qtbase/src/3rdparty/D3D12MemoryAllocator/D3D12MemAlloc.cpp:9902:9: error: 'this' pointer cannot be null in well-defined C++ code; comparison may be assumed to always evaluate to false [-Werror,-Wtautological-undefined-compare]
9902 | if (this == NULL)
| ^~~~ ~~~~
C:/qt/qtbase/src/3rdparty/D3D12MemoryAllocator/D3D12MemAlloc.cpp:10053:9: error: 'this' pointer cannot be null in well-defined C++ code; comparison may be assumed to always evaluate to false [-Werror,-Wtautological-undefined-compare]
10053 | if (this == NULL)
| ^~~~ ~~~~
C:/qt/qtbase/src/3rdparty/D3D12MemoryAllocator/D3D12MemAlloc.cpp:10118:9: error: 'this' pointer cannot be null in well-defined C++ code; comparison may be assumed to always evaluate to false [-Werror,-Wtautological-undefined-compare]
10118 | if (this == NULL)
| ^~~~ ~~~~
4 errors generated.
This amends 84fb0de413 .
See also
* https://clang.llvm.org/docs/DiagnosticsReference.html
* https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Pick-to: 6.8
Change-Id: I2c8d27ade8a123bc4ff2fa5082e161c042335c6c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
(cherry picked from commit 34be5083bd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
With current CI Android emulation this test seems to pass.
Does not seem to be flaky either.
Fixes: QTQAINFRA-6336
Pick-to: 6.8
Change-Id: I863b2744a63b5f90fcc42570945f3f761a3da021
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 9d507910db)
The function is located in public CMake commands and should be '_'
prefixed.
Amends a905d26f14
Pick-to: 6.8
Change-Id: I2817105de4e60d9e5d9a65479af2d11ac6406dae
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit be5845e8ca)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This regex pattern instructs QDoc to not include the matching warning in
its warning count. The warning has changed to a report, however, which
won't count towards the warning count in any case, so the regexp isn't
needed anymore.
Task-number: QTBUG-131459
Task-number: QTBUG-134219
Pick-to: 6.8
Change-Id: Ic461c63b62bd25fb2d1f3b485c46db55e52e20cf
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
(cherry picked from commit a8dab8590a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The namespace contains traits to check for presence and noexceptness
of compareThreeWay() overloads. One of those overloads, the (raw) ptr
one, is deprecated, and therefore throws a warning when one of these
traits hits it. But this is beside the point, because it's not
actionable by the user.
Fix by wrapping the whole namespace in QT_WARNING_DISABLE_DEPRECATED.
This fixes one of the two remaining -Wdeprecated warnings in
tst_qcompare (which the test tries its best to defend against, by
using QT_WARNING_DISABLE_DEPRECATED around the lines, too, but it
didn't help in this case), namely this one:
qcomparehelpers.h: In instantiation of ‘constexpr bool QtOrderingPrivate::CompareThreeWayTester::compareThreeWayNoexcept() [with LT = int*; RT = int*; typename std::enable_if<hasCompareThreeWay_v<LT, RT>, bool>::type <anonymous> = true]’:
qcompare.h:689:91: required from ‘auto qCompareThreeWay(const LT&, const RT&) [with LT = int*; RT = int*; typename std::enable_if<disjunction_v<QtOrderingPrivate::CompareThreeWayTester::HasCompareThreeWay<LT, RT, void>, QtOrderingPrivate::CompareThreeWayTester::HasCompareThreeWay<RT, LT, void> >, bool>::type <anonymous> = true]’
tst_qcompare.cpp:847:5: required from here
qcomparehelpers.h:1229:34: warning: ‘constexpr Qt::strong_ordering Qt::compareThreeWay(const LeftType*, const RightType*) [with LeftType = int; RightType = int; typename std::enable_if<disjunction_v<std::is_same<T, U>, std::is_base_of<Container, T>, std::is_base_of<U, T> >, bool>::type <anonymous> = true]’ is deprecated: Wrap the pointers into Qt::totally_ordered_wrapper and use the respective overload instead. [-Wdeprecated-declarations]
1229 | { return noexcept(compareThreeWay(std::declval<LT>(), std::declval<RT>())); }
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
qcomparehelpers.h:999:31: note: declared here
999 | constexpr Qt::strong_ordering compareThreeWay(const LeftType *lhs, const RightType *rhs) noexcept
| ^~~~~~~~~~~~~~~
The last warning actually pertains to the body of qCompareThreeWay()
calling Qt::compareThreeWay() on pointers. Even though we try to
suppress that one, too, for testing purposes, it's not clear how it
can be fixed without hiding it for all users of qCompareThreeWay(), so
this is left for another day.
Amends 3d231e27a8.
Pick-to: 6.8
Change-Id: Id434629435ea8ea89d03e46096866283ab792b54
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 75e10a0656)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In Qt 5 we would ask FreeType for height metrics. FreeType
always returns rounded metrics, so for e.g. DejaVu Sans at
pixel size 21 it would return ascender=20 and descender=5,
which is actually incorrect, since the actual ascender is
19.49. The descender is rounded correctly. This is likely
due to the use of fixed point math internally.
In Qt, we would account for this error by setting the
leading to -1, so that the rounded height still becomes
24. (This is also technically incorrect, since the line gap
of the font is 0.)
In Qt 6, we got the same fixed point rounding error (so
ascender becomes 20 instead of 19), but we didn't account
for the error, so we would end up with lines that were 25
high instead of 24.
To reduce the chance of getting this error, we do the full
metrics calculation in floating point numbers instead. For
the case in question, we will then get arounded ascender of
19 and descender of 5, giving us a height of 24.
Fixed point numbers are still used for storing the results,
so while it's less likely, we could still end up with the
same error. Therefore, we also apply the same trick as in
Qt 5 when this occurs: Adapting the leading of the font to
account for the rounding error if it occurs.
[ChangeLog][QtGui][Text] Fixed an issue where the line
distance for hinted fonts would be off by one for specific
sizes of some fonts.
Fixes: QTBUG-134602
Pick-to: 6.8
Change-Id: I09f1806199b7b2b02a932bb65fe4da055bd60f51
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
(cherry picked from commit 3728032e03)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The former is deprecated.
Change-Id: I94de7a6c6bbea61cd75820389e8039cb92c7ee6a
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 600388ff2a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
XdgDesktopPortal requires a base platform theme, which is created in
its c'tor. If XdgDesktopPortal was shipped as a plugin of its own,
it would find itself as a plugin, create itself as its own base theme
and thus end up in an infinite loop.
Factor out the key check from main.cpp as a static bool in
QXdgDesktopPortalTheme.
Ignore XdgDesktop keys when scanning for plugins suitable as a base
theme.
Fixes: QTBUG-134703
Pick-to: 6.8 6.5
Change-Id: I4aab1e77a48251581369f371e4c9af308ef0a02b
Reviewed-by: Liang Qi <liang.qi@qt.io>
(cherry picked from commit 3404a1491e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use std::as_const() for a QStringList in a ranged for-loop.
Use auto * for a pointer.
Pick-to: 6.8 6.5
Fixes: QTBUG-134702
Change-Id: Ia092933fe959afdd6b6e0a9743e3603c29b291d8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
(cherry picked from commit 22e05d74b2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The feature is required to check if gl_sampleID etc are available in the
fragment shaders.
Task-number: QTBUG-134999
Change-Id: Id26c75780011a7553d332ae22e69aab632891998
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 86e3573671)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The function can be called from ~QDialog(), in which case a cast of
q_ptr to QFileDialog is UB.
Says UBSan:
qfiledialog_p.h:78:5: runtime error: downcast of address 0x7ffe7a8ad5a0 which does not point to an object of type 'QFileDialog'
0x7ffe7a8ad5a0: note: object is of type 'QDialog'
fe 7f 00 00 30 44 d8 fb d2 7f 00 00 80 b4 00 00 90 61 00 00 08 46 d8 fb d2 7f 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QDialog'
#0 0x7fd2f96d7587 in QFileDialogPrivate::q_func() qfiledialog_p.h:78
#1 0x7fd2f96d7587 in QFileDialogPrivate::setVisible(bool) qfiledialog.cpp:860
#2 0x7fd2f95465f5 in QDialog::setVisible(bool) qdialog.cpp:757
#3 0x7fd2f6d88768 in QWidget::hide() qwidget.cpp:8179
#4 0x7fd2f9545e09 in QDialog::~QDialog() qdialog.cpp:398
Fix by casting to QFileDialog only on show() (in createWidgets()), not
hide(), and otherwise cast at most to QDialog* (QWidget* would
actually have sufficed).
Add a code comment.
Amends e0bb9e81ab (I think; it might
have been present in a different form before that).
Pick-to: 6.8 6.5
Change-Id: I4e206f7c36c03e8cb8a36001beae283628960073
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit a6743bd3c7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The handleDragEnterEvent() function is not only called for
QEvent::DragEnter, but also, in handleDragMoveEvent(), for
QEvent::DragMove, in which case the fully-derived event passed as an
argument is a QDragMoveEvent, and not its subclass QDragEnterEvent.
Code in Qt seems to assume that it's ok to cast an object down to a
more-derived class than the most-derived dynamic type, as long as no
extra state is being added between the two, but C++ does not chare
that view.
Says UBSan:
qwidgetwindow.cpp:1000:38: runtime error: downcast of address 0x7ffe7b34c6e0 which does not point to an object of type 'QDragEnterEvent'
0x7ffe7b34c6e0: note: object is of type 'QDragMoveEvent'
00 00 00 00 e0 62 70 42 aa 7f 00 00 3d 00 00 00 00 00 00 00 00 00 00 00 00 c0 58 40 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QDragMoveEvent'
Furtunately, handleDragEnterEvent() doesn't actually need its argument
to be a QDragEnterEvent; QDragMoveEvent suffices, so we can just
change the argument type back to QDragMoveEvent and remove the cast in
handleDragMoveEvent().
Add a bit of \internal docs to describe the discrepancy between the
function's name and argument type.
Amends f8944a7f07.
Picking all the way, because this is risk-less: Either the code compiles
and then it works as before (minus the UB), or it doesn't compile.
Pick-to: 6.8 6.5 5.15
Change-Id: I5be53b023d389902b43e9a896d074edea1c4ff2d
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit e89c0a7fb5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
WorkerThread needs an explicit constructor, otherwise
WorkerThread *workerThread = new WorkerThread(this);
will fail. While at it, at some infrastructure code so that the
.cpp file actually compiles.
Change-Id: I35835b1be3da2a1f75222594197f6013b41a7b4a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 68a1655817)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use the original functionality as the fall back solution for
the introduced by CMake 'file(CONFIGURE' command.
Pick-to: 6.8
Change-Id: I2be7e3bf80a577cdf8292c9f47bb127fa71615b6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit ec5f4fe580)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The logic is generic, make it accessible from the function.
Pick-to: 6.8
Change-Id: Ib361399722dba689891d301e20b3f713450e676f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit cda51bcd9c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Return the androiddeployqt TARGET, which can be used in custom commands
or if the target doesn't exist, fall back to old approach and use
the full path to the host androiddeployqt. If both are not found,
encourage users to reinstall Qt or report the bug.
Pick-to: 6.8
Change-Id: I9f487b0f0af8703a9387b9c0cf8baae47859658e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 2c86eaee49)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The genex will be generic, so make it accessible from function.
Pick-to: 6.8
Change-Id: I83246890e2d81f3cdbbd8fe2b93d59968623a889
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 9819e9c2e0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Swap the argument order so the "output" is the first argument.
Pick-to: 6.8 6.5
Change-Id: I1325af97f1d6540c6897b51f1b5736b4534f6412
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit b434e0be79)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Adjust the function name according to our naming convention for
private function locating in public cmake scripts.
Pick-to: 6.8 6.5
Change-Id: I3a108cdb43bd4b3d8cf29ac4c42c7c20c541afc8
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 2adf941060)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Since the deployment config type detecting is generic, move it a
separate function.
Pick-to: 6.8
Change-Id: If925b6e14ba0d64a003e7f9ae2a5d701b7886920
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit f10f609db9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The test function didn't delete the heap-allocated QGraphicsScene,
because, a comment indicated, there was some "corruption in scene
destruction".
Fix the memleak by creating the scene object on the stack. A local
asan+ubsan build is clean, and so is a valgrind run, so whatever it
was, it seems fixed by now.
Amends the start of the public history.
Picking back to verify that it's been, indeed, fixed in all active
branches.
Pick-to: 6.8 6.5 5.15
Change-Id: Ic7f96c7195d58ccbff45b17f76fb2babd1c1b648
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit 4293381545)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The test function created QGraphicScene objects on the heap, but never
deleted them. They were added to a View, yes, but a view doesn't own
the scene it renders, so this didn't help.
Fix by creating the scenes on the stack instead.
Amends the start of the public history.
Pick-to: 6.8 6.5 5.15
Change-Id: I939e028dbfd68b216ef67c3773f085ba98817b05
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit d8b79dc1c9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The test had it the wrong way around: it deleted the QWidget it had
added to the QGraphicsScene, which thus becomes the widget's owner,
but left the scene itself undeleted, leaking it and all the items (but
not the widget ;-)).
Create the scene on the stack, so it's deleted by the compiler, and
release() the widget into the scene.addWidget() call. Since
QScopedPointer::take() is deprecated, port to std::unique_ptr.
Amends the start of the public history.
Pick-to: 6.8 6.5 5.15
Change-Id: Idbf821a35a7db802a68923fc09b185ddc3181245
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit fdcf54062c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A QGraphicsScene owns the items added to it, but if we later
removeItem() one again, then we're also responsible for freeing the
item. The test functions didn't do that, so we leaked the item.
In order to not change the rest of the functions by deleting the item
earlier than it had been before, install a qScopeGuard() to delete it,
right after we removed it from the scene again.
Amends the start of the public history.
Pick-to: 6.8 6.5 5.15
Change-Id: I8ab50626a0b5d52825bb329233ab8efe6c1291dc
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 3651769d52)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A view doesn't own the scene it renders, because scenes can be in
multiple views. So if the test function doesn't delete `anotherScene`,
no-one else does, either.
To fix, allocate it on the stack (like `scene`), and not on the heap.
Amends the start of the public history.
Pick-to: 6.8 6.5 5.15
Change-Id: I2f0bfc5dfafd68a347553335f5ac5f2d081d56ad
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 0617d177ac)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The items were not added to any scene, so nothing ever deleted them.
Hold them in unique_ptr, taking care to delete the parent, if any,
last, even though it was created after its child.
Amends the start of the public history.
Pick-to: 6.8 6.5 5.15
Change-Id: I9980530efb3386e15b81232e526a1d8d3bb3c36d
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit 284283c5b2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The result of QTest::createTouchScreen() needs to be deleted by the
caller, and this test didn't do that.
To fix, put the object into a unique_ptr.
Amends 982b70d37d, though the code it
replaced seems to have had the same problem.
Pick-to: 6.8 6.5 5.15
Change-Id: I361a0b37b717ac543b003fb48a4a6934b6d79a03
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit e9a7c4a224)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The function can be called from ~QDialog(), in which case a cast of
q_ptr to QFontDialog is UB.
Says UBSan:
qfontdialog_p.h:43:5: runtime error: downcast of address 0x604000026b90 which does not point to an object of type 'QFontDialog'
0x604000026b90: note: object is of type 'QDialog'
00 00 00 00 30 a4 26 31 45 7f 00 00 80 b9 00 00 90 61 00 00 08 a6 26 31 45 7f 00 00 00 00 be be
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QDialog'
#0 0x7f452ecad24d in QFontDialogPrivate::q_func() qfontdialog_p.h:43
#1 0x7f452ecad24d in QFontDialogPrivate::setVisible(bool) qfontdialog.cpp:959
#2 0x7f452ea2b5f5 in QDialog::setVisible(bool) qdialog.cpp:757
#3 0x7f452c26d768 in QWidget::hide() qwidget.cpp:8179
#4 0x7f452ea2ae09 in QDialog::~QDialog() qdialog.cpp:398
Fix by casting at most to QDialog* (QWidget* would actually have
sufficed).
Add a code comment.
Amends e0bb9e81ab (I think; it might
have been present in a different form before that).
Pick-to: 6.8 6.5
Change-Id: Ic1a63ff02b1a1435499a6980772b1b75236f31f7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 41480dbd4a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The function can be called from ~QDialog(), in which case a cast of
q_ptr to QColorDialog is UB.
Says UBSan:
qcolordialog.cpp:72:5: runtime error: downcast of address 0x7ffd37909750 which does not point to an object of type 'QColorDialog'
0x7ffd37909750: note: object is of type 'QDialog'
fd 7f 00 00 30 34 6e 35 4a 7f 00 00 80 b9 00 00 90 61 00 00 08 36 6e 35 4a 7f 00 00 00 00 f2 a6
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QDialog'
#0 0x7f4a32e8738a in QColorDialogPrivate::q_func() qcolordialog.cpp:72
#1 0x7f4a32e8738a in QColorDialogPrivate::setVisible(bool) qcolordialog.cpp:2154
#2 0x7f4a32ea5675 in QDialog::setVisible(bool) qdialog.cpp:757
#3 0x7f4a306e7768 in QWidget::hide() qwidget.cpp:8179
#4 0x7f4a32ea4e89 in QDialog::~QDialog() qdialog.cpp:398
Fix by casting to Qcolordialog only on show() (in initWidgets()), not
hide(), and otherwise cast at most to QDialog* (QWidget* would
actually have sufficed).
Add a code comment.
Amends e0bb9e81ab (I think; it might
have been present in a different form before that).
Pick-to: 6.8 6.5
Change-Id: I006406b6cf1012fc3c7a910abcfe14bc119a2b29
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 0be1ca029c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The result of QTest::createTouchScreen() needs to be deleted by the
caller, and this test didn't do that.
To fix, put the object into a unique_ptr.
Amends 982b70d37d, though the code it
replaced seems to have had the same problem.
Picking all the way back, since this code hasn't changed in ages, and
so conflicts are unlikely. Also, there appears to be a remaining leak
in QScroller::grabGesture(), and we don't know, yet, how far we'd pick
that one, but verifying it will likely be helped by the test not
otherwise leaking. Filed QTBUG-135055 to track the issue.
Pick-to: 6.8 6.5 5.15
Task-number: QTBUG-135055
Change-Id: I6ab3402671f768c6a33b682d456145f18629e6cb
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit 49a87936ef)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The function can be called from ~QDialog(), in which case a cast of
q_ptr to QMessageBox is UB.
Says UBSan:
qmessagebox.cpp:182:5: runtime error: downcast of address 0x7ffdccfbda00 which does not point to an object of type 'QMessageBox'
0x7ffdccfbda00: note: object is of type 'QDialog'
88 7f 00 00 30 94 4a 73 88 7f 00 00 80 8c 00 00 90 61 00 00 08 96 4a 73 88 7f 00 00 00 00 fb cc
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QDialog'
#0 0x7f8870f9a8a3 in QMessageBoxPrivate::q_func() qmessagebox.cpp:182
#1 0x7f8870f9a8a3 in QMessageBoxPrivate::setVisible(bool) qmessagebox.cpp:1660
#2 0x7f8870c6b3b5 in QDialog::setVisible(bool) qdialog.cpp:757
#3 0x7f886e4ad4b8 in QWidget::hide() qwidget.cpp:8179
#4 0x7f8870c6abc9 in QDialog::~QDialog() qdialog.cpp:398
Fix by casting to QMessageBox only on show(), not hide(), and
otherwise cast at most to QDialog* (QWidget* actually suffices).
Add a code comment.
Amends e0bb9e81ab (I think; it might
have been present in a different form before that).
Pick-to: 6.8 6.5
Change-Id: Ia163483c1998924a0d9c9fd589311af24a93d1fe
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 8b4900bfff)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Update the macro so that where the supported ndk version is referenced
in docs are updated in all places used.
Pick-to: 6.8 6.5
Task-number: QTQAINFRA-6479
Change-Id: I93164f2ec48c71ab99ee2ccba02f6adb0ac4dd89
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
On Windows the "interface" is defined as "struct".
Pick-to: 6.8
Task-number: QTBUG-122980
Change-Id: I1a80c9e40d59449bb3c3773679a95405ea39d630
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 23a4b586f7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
So it's easier to find in the IDE, as otherwise everything is
"main.cpp".
Change-Id: I8d4663c84603113376a1fffd2f78f87635f3310f
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit 037f6be428)
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QComboBox destroys the container of the view in its own destructor,
before the QWidget destructor is entered. The container is a toplevel
widget, so destroying that will destroy a platform window, triggering an
accessibility update cycle that calls back into Qt. As the QComboBox has
not yet reached the QWidget destructor, it still considers itself as
visible and focused. The accessibility query will therefore operate on
it, as the focused object. Probing the state accesses the view.
The view however is already partially destroyed, as the container's
destruction has already passed the QWidget destructor deleting all its
children. As a result, we are returning a pointer to a QAbstractItemView
that's already in the QWidget destructor, resulting in a crash.
Options for fixing this would be resetting the view pointer in
~QComboBoxPrivateContainer to nullptr and to test for that in client
code. Doing that triggered crashes in tests, as QComboBox::view() so far
has never returned a nullptr no matter the state of the combobox.
So instead, close the container explicitly before destroying it. This
way, any update cycle resulting in reentrancy (such as accessibility of
backingstore flushing when the container closes) will be completed
before objects are destroyed.
This amends fde358dd90, which added the
explicit destruction of the container, for similar reasons.
This seems to be a combobox-specific problem due to the combination of
explicit destruction of (toplevel) child widgets, resulting event
processing, and exposing of internal widget states through public API
as part of the widget's accessible state.
Pick-to: 6.8 6.5
Fixes: QTBUG-132310
Change-Id: I74df5b71906ce8153b12ddc35b897a44e7752907
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 74e5a51bab)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Older CMakes error out with
CMake Error at cmake/QtSyncQtHelpers.cmake:156 (list):
list sub-command REMOVE_ITEM requires two or more arguments.
if the last expanded variable is empty.
Fix by doing an explicit non-emptiness check.
Amends e7834e90f3
Pick-to: 6.8
Task-number: QTBUG-134672
Task-number: QTBUG-128730
Change-Id: I3c355a02519c2c450235770b2ff8c92416615a9f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 9ff4b5341f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
`git-review` is a command line tool for interacting with Gerrit.
Some IDEs offer support for this tool, either natively or through
plugins. The tool relies on a configuration file, .gitreview. Adding
this configuration file to our repositories simplifies initial setup
for contributors that use the tool directly or through their IDE of
choice.
The configuration file adds a remote called 'gerrit'. This is the
default for the tool, and also the name set for
codereview.qt-project.org by Qt's `init-repository` script. Thus,
the configuration should work seamlessly alongside other repository
helpers.
Task-number: QTBUG-132604
Pick-to: 6.8
Change-Id: Ic14f4ac93dae34701e2a35b1802ab2d7b740985e
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
(cherry picked from commit bf15cf1cfa)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Coverity complained that the default ctor didn't initialize its two
members. This is true, and it even remains true if the user of the
type explicitly asks for value-initialization (ChangeSignal s = {}) as
opposed to default-construction (ChangeSignal s;).
Remove the default ctor as the minimally-possible fix. It was only
needed because of a call to QFlatMap::value(1-arg), which,
incidentally, constitutes a double-lookup, because it is following a
contains() call. Replacing that combo with find() and it.value()
avoids the double-lookup and removes the need for the type to be
default-constructible.
Amends 0328e4297e.
Coverity picked this up as a new issue following
53fb13456f, so there probably is another
CID for this for the same code in the old location, but my Coverity
search-foo is insufficient to find the corresponding CID, without
undue effort, so I didn't try.
Manual conflict resolution for 6.9:
- tracked contents from qdbuslistener* back into qgenericunixthemes.cpp,
whence 53fb13456f moved them.
Coverity-Id: 478089
Pick-to: 6.8 6.5
Change-Id: I912bf2af343b98fe62faf2d4bf8a6d1f385593e8
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit d624454586)
Since the label of a progressbar is drawn right of the bar, it does not
make sense to draw a label for vertical bars. This is consistent with
windows and windowsvista style.
Pick-to: 6.8
Fixes: QTBUG-132459
Change-Id: I6610a1ef1b4074a6301aac12928c1dfe99ffd457
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
(cherry picked from commit a37606310e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Marc Mutz
Liang Qi
Rami Potinkara
Mårten Nordheim
Alexey Edelev
Thiago Macieira
Paul Wicking
Giuseppe D'Angelo
Eskil Abrahamsen Blomfeldt
Axel Spoerl
Antti Määttä
Kai Köhne
Nicholas Bennett
Nodir Temirkhodjaev
Volker Hilsheimer
Alexandru Croitor
Christian Ehrlicher