.. 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>
It's used by the lancebench and the lance tool, and it will probably be
useful for writing some high-dpi related unit and baseline test cases,
so move it to the shared folder.
Change-Id: I969bab51c9504be13b4c192b4f29f69cd9102868
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The current behavior for handling the angle delta of a wheel event
changes index the instant there is a change in angle delta. This works
fine for mouse wheels that send events with 120 angle delta units and
there is also already behavior defined for devices with pixel deltas,
but there is nothing good for handling events from high resolution mouse
wheels that don't have pixel deltas.
This patch makes it so that the current index doesn't change until the
accumulated angle delta for the X or Y axis reaches 120.
[ChangeLog][QtWidgets][QTabBar] Scrolling with a high resolution mouse
wheel changes the current index at a rate more like a normal mouse
wheel.
Task-number: QTBUG-97844
Pick-to: 6.3
Change-Id: I2e7fd88984a253f6ef8a0008deb7233e4cb4d84a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Commit 289f909621 ("Test conversion of
ulonglong variant to JSON") was trying to ensure the result becomes a
double. So there's no reason to make a test in the _data() function.
Drive-by fix the UB condition on Windows (ulong is 32-bit, so 1ul << 63
is UB).
Change-Id: I0e5f6bec596a4a78bd3bfffd16ca4f8f5219f785
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
It was Linux-only and now even Linux is complaining:
tst_qmetatype.cpp:421:26: warning: ‘int pthread_yield()’ is deprecated: pthread_yield is deprecated, use sched_yield instead [-Wdeprecated-declarations]
Change-Id: I0e5f6bec596a4a78bd3bfffd16cb1eadfa301f16
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
All primitive types are initialized and have been since at least commit
33cd680ddb ("New QMetaType
representation").
Change-Id: I0e5f6bec596a4a78bd3bfffd16cb1fe22dc5c8f5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When some test function fails (even as expected), it can leave the
event dispatcher in an inconsistent state where the posted events
queue might not be empty. As a result, this may break the internal
logic of the next test function that is run.
So, calling eventDispatcher->processEvents() after each completed
function resets the event dispatcher to its initial state, which
fixes the problem.
Pick-to: 6.2 6.3
Change-Id: I5a54f892d09a6eca73c8fc82875ce3b9ce4a3242
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We set the wakeUps atomic to prevent multiple WM_QT_SENDPOSTEDEVENTS from
being posted. However, this might happen right after the event processing
thread cleared the atomic, but before it processed the previous
WM_QT_SENDPOSTEDEVENTS message. In that case, we end up with a set
atomic and an empty event queue, resulting in the event loop to block
even though there are posted QEvents.
To prevent that, always reset the atomic when we handle the
WM_QT_SENDPOSTEDEVENTS message. In that case, we either call
sendPostedEvents, or startPostedEventsTimer. The former already resets
wakeUps; reset it in the latter as well.
Fixes: QTBUG-99323
Pick-to: 6.2 6.3 5.15
Change-Id: I931c02be9c42b02e8ca20daba5059cd8185f0a37
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Add two tests for some problematic scenarios where the behavior is not
consistent across platforms and depending on which event dispatcher is
used:
1) reliably waking up the dispatcher when posting events from a worker
thread.
That test fails 100% of the time on Windows no matter what type of
application is created. It passes reliably on Linux and macOS for both
core and gui applications.
2) waking up the dispatcher when we post an event from within an
event handler.
That test fails 100% of the time on Windows, both with core
and GUI event dispatchers. On macOS, the test fails 100% of the time
with the core dispatcher, and passes 100% of the time with the GUI
dispatcher. On Linux, it passes only if a Glib based event dispatcher
is used; the default Unix event dispatcher (which is also the one
used on macOS for core applications) fails.
Task-number: QTBUG-99323
Pick-to: 6.2 6.3 5.15
Change-Id: I2489533b9f0032488707777be0512bb933669a7d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
