When running a test under increased verbosity levels, QTestLib would
print "failure location" for every QTest function (QVERIFY, QCOMPARE,
...), even if there's no failure at all.
Keep the code centralized, but split the formatting of failures and
non-failures (other messages).
Task-number: QTBUG-96844
Change-Id: I3c508653176b68579dc0eb0cffcc153a52da2e2c
Pick-to: 5.15 6.2 6.3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
While investigating an assertion failure I noticed that the existing
tests didn't even exercise these methods for local time or zone time.
Of course, we can't robustly test these time-specs, due to vagueries
of offset details and zone availability, but we can at least verify
that they return date-times on the specified date. Add a test-case for
the start of 1900, on which the assertions were first seen; it is the
earliest moment representable with tm_year >= 0, after all.
One of these tests fails on 6.2 but the fix for that (as opposed to
the the assertion) requires 6.3's improvements to the handling of
time_t's fuller range - too risky a change to pick back to 6.2.
Pick-to: 6.3
Task-number: QTBUG-99747
Change-Id: I98f5d7850a701972b2d8ea2ce203a2b3e7071354
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qt_internal_undefine_global_definition disables an internal global
definition that is defined by the qt_internal_add_global_definition
function for a specific target.
Remove the ability to set the custom "undefine" flag for the
definitions since it's hard to control it using the introduced
function.
Pick-to: 6.2 6.3
Task-number: QTBUG-100334
Change-Id: Ic1637d97aa51bbdd06c5b191c57a941aa208d4dc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Not MSVC, but pretends to be.
Pick-to: 6.3 6.2
Change-Id: I5c201dd917e79a22d6ef15715bf1d3a7010d123e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In 63eea5e5c69434871eaef9d9dc7184d7e54d7276, the
Qt::ItemNeverHasChildren flag was introduced. QFileSystemModel
was modified to use this flag for items which are not directories,
but only if the QFileSystemModel is not read-only and
the directory is writable.
This patch modifies QFileSystemModel to use the ItemNeverHasChildren
flags also if the model is read-only and if the item
is read-only.
Amends 63eea5e5c69434871eaef9d9dc7184d7e54d7276
Change-Id: Ie7f7d58ecf7baade93f9f03d120da84d3c005d42
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
Amends e3b2b12a91, which made the
style sheet calculate the font-dependent text size, but didn't
add the space needed for the close button or a tab icon.
QTabBar's layout code already adds the space needed for icons
and margins to the size; so instead of overwriting that size,
subtract the size needed by the normal font, and then add the
size needed for the font form the style rule, considering both
vertical and horizontal tab bars.
Fix the test case to style only one tab rather than the entire
tab bar, otherwise the font is applied to the entire tab bar,
and not just to a specific tab, which is the style sheet style
code in question.
Pick-to: 6.2 6.3
Task-number: QTBUG-6905
Change-Id: Ieed0ba146a32e81229419adecaf41f467cfd5959
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Task-number: QTBUG-100362
Change-Id: Ib09aec5ea03867163d476a2c92562bc949fc1b1a
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The code was trying to avoid a detach in the case no element needed to
be removed, by first running find_if() on const_iterators, and then,
after converting its result to (mutable) iterators, start the
remove_if() algorithm where find_if() left off.
But this applies the predicate to the element found by find_if() (if
any) _twice_: first just before we exit the first find_if() and then
just as we enter remove_if(), which will start by running find_if()
again, with the result of the initial find_if as 'first'.
Apart from being needlessly inefficient, this violates the
specification of Uniform Erasure, which defines sequential erase_if()
as being equivalent to remove_if() + container erase(), with the
former being specified to apply the predicate exactly once per
element.
Fix by writing the remove_if() part by hand.
Instead of doing the dance with the loop invariant documentation
twice, simply implement erase() via erase_if() (complicated a bit by
the weird passing of predicates by lvalue reference instead of by
value, as would be idiomatic). This exposes users to:
[ChangeLog][QtCore][Potentially Source-Incompatible Changes] A fix in
the implementation of the erase-like algorithms of sequential Qt
container may re-enable signed/unsigned comparison warnings previously
suppressed by having occurred in std library code. To fix, cast the
value to look for such that it has the same signedness as the
container's elements.
... but the issue would be the same had we inlined std::remove()
instead of passing a lambda to sequential_erase_if(), so it's nothing
we can, nor should, work around.
[ChangeLog][QtCore][Containers] Fixed a bug in the implementation of
most sequential Qt container's erase-like algorithms (member
removeAll()/removeIf() and free erase()/erase_if()) where the equality
operator or the predicate, respectively, was applied to the first
matching element twice. Each element is now tested exactly once.
Pick-to: 6.3 6.2
Change-Id: Ib6d24b01b40866c125406f1cd6042d4cd083ea0d
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Some calling code did this beforehand, other didn't. Now, the function
itself checks for an existing handler before doing anything else.
Change-Id: I8fc43fb8788c9dfe825b15ffa2fa69ee43915cd6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
.. but this will only be supported on Vulkan, OpenGL 3.2+, and Open GL
ES 3.2+ for the time being.
The situation is:
- Vulkan is working. qsb accepts .geom files already, and QShader has
existing geometry shader support.
- OpenGL 3.2 and OpenGL ES 3.2 are working.
- D3D11 is not working. D3D11 supports geometry shaders, but SPIRV-
Cross does not support translating geometry shaders to HLSL.
- Metal is not working. Metal does not directly support geometry
shaders.
Change-Id: Ieb7c44c58b8be5f2e2197bf5133cf6847e6c132d
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Support for Polygon Mode (Triangle Fill Mode in Metal, Fill Mode in D3D)
in the RHI graphics pipeline.
Options are Fill and Line
Status:
OpenGL - ok
Vulkan - ok
Metal - ok
D3D11 - ok
OpenGL ES - does not support glPolygonMode.
Change-Id: I20b7ef416624700c3dc8d1cbe6474f4ca3889db8
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Restore the 'QT_NO_JAVA_STYLE_ITERATORS' and
'QT_NO_NARROWING_CONVERSIONS_IN_CONNECT' definitions for Qt
targets.
Add the function that adds global definitions for Qt targets according
to the provided scope and the target property-based switch to disable
the definition for a specific target.
Pick-to: 6.2 6.3
Task-number: QTBUG-100295
Change-Id: I28697e81f9aabc45c48d79aae1e5caea141e04e1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If the signal passed to QtFuture::connect() takes multiple arguments,
we need to wrap the arguments in a std::tuple when reporting the result.
To detect this case we were checking if the result type of a QFuture
returned by QtFuture::connect() is a std::tuple, but this was not
correct: the result type could be a std::tuple also if the passed
signal takes a single std::tuple argument. Instead, check if the signal
takes more than one argument.
As a drive-by modified the tst_QFuture::signalConnect to use const
values for tuples used in multiple test-cases, to avoid repetition.
Fixes: QTBUG-100071
Pick-to: 6.2 6.3
Change-Id: I1ce39cf87028f36ef94a9d1a4423b0c51473afd4
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The test was already blacklisted for Windows 10 and Windows 7. Now it
is flaky on Windows 11 as well.
Blacklist it for all windows platforms.
Task-number: QTBUG-98478
Pick-to: 6.2 6.3 5.15
Change-Id: I870fb6ce80cfe244a76d08bf40677fdb6becab97
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
The IGNORE directive was likely removed as an oversight
in the linked change.
This fixes the test to pass when bumping the Qt version.
Amends 9836dbd6ee
Change-Id: I497325d6d8b8b67cce7b0840bfb9bfa70d85fe73
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
From the API review.
Pick-to: 6.3
Change-Id: Ic05737db79327e7811fcd974a70914b837e06601
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The test also fails on Windows 11
Pick-to: 6.2 6.3
Task-number: QTBUG-98475
Change-Id: Iab079587d743500d222f2272d1145424e079b4a3
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
Update Catch2 header to latest released version. Needed
to build correctly with glibc 2.34.
Two patches applied on top of the upstream release. Previously
used Qt specific change extracted to a separate patch file.
Fixes: QTBUG-95842
Pick-to: 6.3 6.2
Change-Id: I67e442bbe756ff00c96a45eabf593f7aecddd628
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Add a level of indirection via void_t such that
struct is_transparent {};
works, and not just
using is_transparent = <unspecified>;
Pick-to: 6.3
Change-Id: I3ca2af6a07e6989dc95abc10fb2d0078a5269e5b
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The test has been XPASS'ing recently on Android.
Reverts 67e209f59f.
Fixes: QTBUG-69216
Change-Id: Ic629cc28936e0ef27277c243717e97226bf01b1c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
- It should not be built for systems without process feature.
Task-number: QTBUG-99123
Pick-to: 6.2 6.3
Change-Id: I71caa59c2168435894c7d1afcc8226e44178439f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If id == 0, then we should grab the specified rect from the screen.
To do that, find all windows intersecting with the screen geometry, and
compose their backing store images into a screen-size pixmap.
Otherwise, find the respective backing store and grab only that.
Remove the old code respecting the desktop widget, which is no longer a
thing in Qt 6. The code was also wrongly grabbing only the first
containing - not intersecting - window's backing store into the screen
pixmap.
Enable the QScreen::grabImage test for the offscreen platform, where it
now passes.
Task-number: QTBUG-99962
Change-Id: I16eca7b082d65095a62c73624f86a4423e997a7a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
QSqlQuery::exec() took for granted that it can dereference driver(),
which should be true for all sane usage; however, it should not crash
if used misguidedly. Added regression test, based on bug report's
reproducer, which crashes without the fix.
Fixes: QTBUG-100037
Pick-to: 6.3 6.2 5.15 5.12
Change-Id: I94600bc60f89e82a1121b418144006a683921a38
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
577d698b8e changed QString::isUpper /
isLower behaviors to match Unicode semantics: a string is uppercase
if it's identical to its own toLower/toUpper folding. These semantics
come from Unicode so they're not up for debate.
That commit however left QByteArray untouched. Generally speaking, we
want to move away from QByteArray as "text storage" -- this has
partially happened between Qt 5 and Qt 6, where QByteArray went from
Latin-1 semantics to ASCII semantics. Still, QByteArray offers
toUpper/toLower and isUpper/isLower and all this family of functions
should be consistent in behavior.
Apply the same fix that was applied to QString.
[ChangeLog][Important Behavior Changes] The semantics of
QByteArray::isLower() and QByteArray::isUpper() have been changed. Now
lowercase (resp. uppercase) byte arrays are allowed to contain any
character; a byte array is considered lowercase (resp. uppercase) if
it's equal to its own toLower() (resp. toUpper()) folding. For instance,
the "abc123" byte array is now considered to be lowercase.
Previously, the isLower() (resp. isUpper()) functions checked whether
the byte array only contained ASCII lowercase (resp. uppercase)
characters, and was at least 1 character long. This had the side effect
that byte array containing ASCII non-letters (e.g. numbers, symbols,
etc.) were not lowercase nor uppercase.
[ChangeLog][QtCore][QByteArray] QByteArray::isLower() and
QByteArray::isUpper() now work correctly with empty byte arrays. The
semantics of these functions have been changed.
Pick-to: 6.3 6.2
Fixes: QTBUG-100107
Change-Id: Id56a42f01b2d1af5387bf0e6ccff0f824f757155
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is an issue for QQuickWindow in practice, although it is not hit
by our current tests.
Pick-to: 6.3
Change-Id: Ia73704c1af6a82b2689ce7b844d3b0eb9a17ec18
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
QThreadPool automatically deletes the runnable after it finishes running
the task. In case QThreadPool is nullptr, we should delete the runnable
manually. This amends 87b93c29be.
Pick-to: 6.3 6.2 5.15
Change-Id: Id7e4ed3d4d6de05990edf62e4099852983debc64
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Take the argument by value instead of rvalue ref. In C++17, this is as
efficient, and enables the
return big;
to use the QByteArray move constructor, avoiding the need for a manual
std::move(), which always looks suspicious on a return statement,
because more often than not, it's a pessimization that breaks NRVO.
This code doesn't seem to exist in Qt 6.2, so only
Pick-to: 6.3
Change-Id: I8bf678102f5df1870cfc61090d12f327478d74d1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Clang 10 warns about unused results of relational operators, which is
where this is coming from.
Fix by adding the usual prefix
[[maybe_unused]] auto r = ~~~;
to silence the warning. Do this elsewhere, too, since [[nodiscard]] is
slowly being rolled out across all our APIs. This is not a complete
sweep, though.
Not picking to 5.15, because this pattern doesn't work there and I
don't want to introduce a new one.
Pick-to: 6.3 6.2
Change-Id: I40dd8ad07496b686979dce533e044cbb486e30f3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The timeToTest constant doesn't need to be captured, claims Clang.
Since I don't recall seeing this warning on GCC, be pragmatic and fix
by letting the compiler choose what to capture: [&]. timeToTest is
const, so it doesn't matter whether we capture by reference or value,
the lambda cannot change it either way.
This code doesn't seem to exist in 5.15, so merely
Pick-to: 6.3 6.2
Change-Id: I48d42ab13ed22ac5eb512dc61235b72a19636ea3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The function name suggests that the *= operator is to be benchmarked,
not simple multiplication.
Use the correct operator.
Pick-to: 6.3 6.2 5.15
Change-Id: I6718e8aea640a153083858b39963199e7bab26e9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The class is not intended for inheriting from it (see also
e502906305), so we can mark it as final
to explicitly forbid this. The tests were still using it as a base
class to clean the results during destruction, so fix them accordingly.
Task-number: QTBUG-99883
Pick-to: 6.3
Change-Id: I4a7ee3e2b462bd704e4b5a95ed733144805d6e5b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
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>
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 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>
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>
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>
This is added specifically for the QPA platform and theme plugins, to
honor the QT_QPA_PLATFORM_PLUGIN_PATH environment variable and the
(inadvisable) -platformpluginpath command-line argument.
This removes the last QFactoryLoader used with an empty path (also the
only two that could be reached), which were causing a scan of the
application's binary directory whenever the platform plugin path was
set. In case of applications installed to /usr/bin, the entire /usr/bin
was scanned, which can be qualified as "not good".
Fixes: QTBUG-97950
Pick-to: 6.3
Change-Id: Ice04365c72984d07a64dfffd16b47fe1d22f26d3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The test is timing sensitive; if it takes more than 100ms
to process events, then the timer that clicks the button might
have fired. So only verify that the button is still down if 100ms have
not yet passed, and verify that at least 100ms have passed when the
click is complete.
Also use QSignalSpy to test the signal emissions.
Pick-to: 6.2 6.3
Change-Id: I95f99e204a17c6709f8e2913eefe4b487e949123
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
