There's no class inheriting from ResultStoreBase (and likely won't be),
so the destructor was marked to be made non-virtual in Qt 7. For the
same reason, the internal members don't need to be protected, and the
class shouldn't have "Base" in its name. Add a note about it.
Task-number: QTBUG-99883
Change-Id: I00d7a96d99d2c326d29bd421235a15d68b4d4e5c
Reviewed-by: Mårten Nordheim <marten.nordheim@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>
One might want to build qtbase in Release, but qtsvg or some test in
Debug mode. Before if qtbase was configured as Release, there was no
way to override that.
Now we try to detect whether a custom build type was specified to
qt-cmake / qt-configure-module / qt-cmake-standalone-test /
qt-internal-configure-tests
Note mixing won't work on Windows due to different C/C++ runtimes.
Also, now we don't force set a single build type when a multi config
generator is used as well as one opts out via the
QT_NO_FORCE_SET_CMAKE_BUILD_TYPE variable.
Pick-to: 6.2 6.3
Change-Id: I6dc4325087ff7f905ad677d87b0267e2f3e4693f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This will show the CMAKE_BUILD_TYPE that was computed for a configured
repo or standalone tests, after the logic in
QtBuildInternalsExtra.cmake is executed.
Pick-to: 6.2 6.3
Change-Id: Ib8ffa2c7806a4c16385a2fcd4500f8a0f6a9aa88
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qSwap() is our wrapper around
using std::swap;
swap(lhs, rhs);
it needn't and shouldn't be overloaded.
ADL swap() should be, though, so qSwap(), std::ranges::swap() and all
the other adl_swap()s out there all find the optimized version.
Qt 5.15 has it correct, Qt 6 wrong. Fix it.
Can't pick to 6.2 because, while backwards-source-compatible, because
the generic qSwap() template provides the name for both qualified and
unqualified calls, it's not forwards-source-compatible: A new user of
ADL swap
// compile error w/o `using std::swap`, pessimization otherwise:
swap(dp1, dp2);
would break or performance-regress when going back to an older
version.
Pick-to: 6.3
Change-Id: I725949a4aa9ae438a182b4b7552ff2dced767e2f
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
To make the Qt conan package consumption more seamless for consumers
who use e.g. conan-center packages we should try to make sure that
"the default conan build profiles" people are using should work
with Qt conan packages as well.
This means that we should support the use case that when consumers
are not explicitly defining Qt specific build options, e.g.
-o debug_and_release=True
And the consumer build profiles/settings may contain e.g.
[settings]
...
build_type=RelWithDebInfo
In qtbase conan recipe this should translate to correct
'Options' specific to Qt's configure(.bat).
This change introduces a fallback in case Qt specific
options are not being passed. It sets the Qt specific
options based on the settings.build_type.
Pick-to: 6.2 6.3
Task-number: QTBUG-99571
Change-Id: I961570a100fadc03b8c423dcf0064ccc4be7ae6e
Reviewed-by: Toni Saario <toni.saario@qt.io>
The recipes in conan-center use True/False option values for common
binary options, for example:
- shared
- release
Currently the binary option values for Qt recipes use 'yes'/'no' values
which makes the consumption of Qt conan packages suboptimal.
Example:
$ conan install .. -o qtbase:shared=yes -o shared=True
After the change one can use:
$ conan install .. -o shared=True
The shared=True is applied to all packages in the dependency tree
including Qt now.
Adjust how the booleaness is checked for Conan options which are
wrapped with PackageOptionValue.
Pick-to: 6.2 6.3
Task-number: QTBUG-99558
Change-Id: I52e16d76418ac3c3e9d653e77287ae89248675d7
Reviewed-by: Toni Saario <toni.saario@qt.io>
Create macros that wrap the magic developed in
7d63efc16f and apply it to all
Q_DECLARE_METATYPE invocations that show up in Clang -ftime-trace for
a PCH'ed QtGui build.
Effects on compile times:
Clang 10 -ftme-trace:
$ ClangBuildAnalyzer --analyze qtgui-before.trace | head -n6
Analyzing build trace from 'qtgui-before.trace'...
**** Time summary:
Compilation (523 times):
Parsing (frontend): 628.3 s
Codegen & opts (backend): 304.5 s
$ ClangBuildAnalyzer --analyze qtgui-after.trace | head -n6
Analyzing build trace from 'qtgui-after.trace'...
**** Time summary:
Compilation (523 times):
Parsing (frontend): 546.0 s
Codegen & opts (backend): 304.4 s
GCC 11 time (bash builtin):
before:
$ time for ((i=0; i < 3; ++i)) do touch src/gui/painting/qpolygon.h ; ninja libQt6Gui.so; done
real 4m13,539s
user 49m24,416s
sys 3m18,177s
after:
$ time for ((i=0; i < 3; ++i)) do touch src/gui/painting/qpolygon.h ; ninja libQt6Gui.so; done
real 3m55,697s
user 45m19,941s
sys 3m7,370s
Task-number: QTBUG-97601
Pick-to: 6.3
Change-Id: Ia8e37a58937568a7ed21cfeb4b27274deca4d53b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
I can't test on Windows, so skipped the platform-specific code.
Pick-to: 6.3 6.2
Change-Id: Id13d4abc447ddd5d17fb67b670b83207877456f6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since by default QStyleOptionProgressBar is initialized with initialize
QStyle::State_Horizontal, the example shouldn't overwrite the state, and
instead OR other states into it. Otherwise, the progressbar will be laid
out vertically.
Pick-to: 6.2 6.3
Fixes: QTBUG-100067
Change-Id: Ibebda48a297af4a621719673033f8199b8bc7984
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
After QFuture continuations became non-copyable (see earlier commits),
we have to always use ContinuationWrapper to save the continuations
inside std::function, since it requires the callable to be copyable.
Optimize the wrapper, by storing the callable directly (instead of using
a ref-counted QSharedPointer) and introducing a fake copy-constructor
that makes sure that it's never called.
Pick-to: 6.3 6.2
Change-Id: I0ed5f90ad62ede3b5c6d6e56ef58eb6377122920
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is required to ensure that the continuation attached to a
QFuture returned by QtFuture::when* methods 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
Change-Id: If4e2929b2e638d6b48c95f0aef9dc886066cedbe
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>
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>
Drive-by update one more for to ranged-for and make sure we don't create
the global statics on destruction.
Change-Id: I5e52dc5b093c43a3b678fffd16b5ff674dfd17ae
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Better code style. I need to optimize QCborValueRef::toString() to avoid
a round-trip through QCborValue.
Change-Id: I5e52dc5b093c43a3b678fffd16b5f1f99851cf5f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This showed up on a benchmark when the number of files in the directory
was way too big.
Change-Id: I5e52dc5b093c43a3b678fffd16b5ef9a938abc63
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This works around mismatch in threads starting and restarting QThreads,
and is safe since we don't need to establish a binding, and objectName
access in QThreadPool is locked behind a mutex.
Pick-to: 6.3 6.2
Fixes: QTBUG-96718
Change-Id: Id3f75e4f8344796ca658899645219fe3373ddd6d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Unnecessary. We can't read a directory's entries if it doesn't exist or
isn't a directory.
Change-Id: I5e52dc5b093c43a3b678fffd16b5edce70eb651e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@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>
I'm going to need to call this with a different path.
Pick-to: 6.3
Change-Id: I5e52dc5b093c43a3b678fffd16b5ef59376498ee
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
GCC is unable to emit the SEH metadata about the stack aligning that is
required to execute AVX aligned instructions (VMOVDQA, VMOVAPS, etc.),
so it just doesn't align the stack. That causes crashes on a 50/50
chance every time the compiler attempts to address a stack-aligned
variable. In a debug-mode build, because it always loads & saves
everything on the stack, the chance of a crash happening is a near
certainty.
So we hack around it by going behind the compiler's back and instructing
the assembler to emit the unaligned counterparts of the instructions
every time the compiler wished to emit the aligned one. There's no
performance penalty: if the variable is actually aligned, the unaligned
instruction executes in the exact same time.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c29cac0da18972
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The Intel compiler is now based on Clang, so it always defines the
macros like Clang and GCC do, so we don't need to worry about it any
more. We only need to define the macros that MSVC lacks.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c10f0f6fef43ef
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Since it shows up as a new enum value in the 6.3 header review, it's
reasonable to assume that it was added for 6.3.
Pick-to: 6.3
Change-Id: If766ef56f3354644fbda09088514e55b28a44f32
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
It's private API, but exported, so de-inline the dtor to pin the
vtable in QtGui instead of potentially duplicating it in every library
that uses the class.
Ditto ctor, but that's just code hygiene: we don't want the code to be
duplicated across all users.
Pick-to: 6.3
Task-number: QTBUG-45582
Change-Id: I91ea38be20fc67795466a68ca5721837255b33a0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
Fix various violations of the coding style or general inconsistencies.
No claim for completeness.
* indentation and line breaks
* consistent scopes for case statements where needed
* add curly-brackets for if-statements where needed
* removed {} where not needed
* const'ify a few obvious local variables
* remove random empty lines
* use auto when type is obvious from cast
Deliberately not touching nested if-statements that could be merged into
one.
Pick-to: 6.3
Change-Id: Ie22b36568f33e18d5f15c751c7fd76e1490133b9
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
qSwap() is a monster that looks for ADL overloads of swap() and also
detects the noexcept of the wrapped swap() function, so it should only
be used when the argument type is unknown. In the vast majority of
cases, the type is known to be efficiently std::swap()able or to have
a member-swap. Call either of these.
For the common case of pointer types, circumvent the expensive trait
checks on std::swap() by providing a hand-rolled qt_ptr_swap()
template, the advantage being that it can be unconditionally noexcept,
removing all type traits instantiations. Don't document it, otherwise
we'd be unable to pick it to 6.2.
Effects on Clang -ftime-trace of a PCH'ed libQt6Gui.so build:
before:
**** Template sets that took longest to instantiate:
[...]
27766 ms: qSwap<$> (9073 times, avg 3 ms)
[...]
2806 ms: std::swap<$> (1229 times, avg 2 ms)
(30572ms)
after:
**** Template sets that took longest to instantiate:
[...]
5047 ms: qSwap<$> (641 times, avg 7 ms)
[...]
3371 ms: std::swap<$> (1376 times, avg 2 ms)
[qt_ptr_swap<$> does not appear in the top 400, so < 905ms]
(< 9323ms)
As a drive-by, remove superfluous inline keywords and template
ornaments.
Task-number: QTBUG-97601
Pick-to: 6.3 6.2
Change-Id: I88f9b4e3cbece268c4a1238b6d50e5712a1bab5a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We already have a precedent for this: the QueueCreateInfoModifier
callback. Following the pattern, add a EnabledFeaturesModifier that
can alter the VkPhysicalDeviceFeatures that is passed to
vkCreateDevice().
[ChangeLog][QtGui][QVulkanWindow] QVulkanWindow can now invoke a
callback to alter the VkPhysicalDeviceFeatures object used to create the
Vulkan device. This allows enabling 1.1, 1.2, and extension features.
Fixes: QTBUG-99803
Change-Id: I5ede0c6bc3430cbb304d4961eb9e44faad5ce4d7
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
[ChangeLog][QtGui][QVulkanWindow] QVulkanWindow is now enabling all
Vulkan 1.0 features reported as supported from the physical device.
Pick-to: 6.2 6.3 5.15
Task-number: QTBUG-99803
Change-Id: Ib9cfcd449904c67b07e0e2d4ade5bcaeb4cb0ce6
Reviewed-by: Andy Nichols <andy.nichols@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>
We need it for shadertools.
Change-Id: I9e9c76e535e5cd698564b48beedb7380b08173e2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Simeon Kuran <simeon.kuran@gmx.at>
The mold linker is a new linker for Linux that provides faster link
times compared to BFD ld, ld.gold and lld.
It can be found at https://github.com/rui314/mold
To build Qt with mold, ensure that the binary in your PATH and then
configure Qt with with either
cmake /path/to/qtbase -DINPUT_linker=mold
or
/path/to/qtbase/configure --linker mold
The change was tested with gcc 9, clang 10, clang 12, mold
1.0.0. Only qtbase and qtdeclarative (and dependencies) were tested.
Pick-to: 6.2 6.3
Task-number: QTBUG-99270
Change-Id: I2e64a1f4257c37ff5b64a9326e548b9b46e07c80
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
Not to have warnings about invalid (nullptr) parameters.
Change-Id: I5fdfa7e99df0f3c9907055cf244efa5a56b21c11
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Minor glitch in wording, but it's been bugging me for months.
The meaning of "try to remove [a file]" implicitly says you might be
unable to do so; while the attempt might help with your situation, the
experiment might merely be a diagnostic, e.g. because if you can't
remove the file, that would imply things that would help you solve
your problem. For contrast, "try removing [a file]" says removal
might actually solve the problem for which this action is proposed as
a fix.
Change-Id: Ic995cfdef1523094bb368dcda8bd0d2bbd2e9434
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We do not test actively test setups where a separate graphics and
present queue is used because there is no combined queue at all. (it
won't be tested because we neither want to nor have the possibility to
do so)
However, QVulkanWindow (unlike, say, QRhi's Vulkan backend) attempts
to support this. It turns out the argument passed to vkQueuePresent is
wrong: the present is to be submitted to the present queue. So fix
this up.
Pick-to: 6.3 6.2 5.15
Fixes: QTBUG-73470
Change-Id: Ic9b589aba52e3326637216b98a074e27fdc3e3b9
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Use CMAKE_STAGING_PREFIX instead of CMAKE_INSTALL_PREFIX when
cross-compiling. This separates the host path used in staging
prefix and the target path used in the install prefix for the
device. This prevents for example Windows paths from being used
in a device that does not support those. It also tells qmake
not to sysrootify paths when building with it.
Embedded linux and QNX builds are mostly affected and need this
to use correct RPATHs and to unsysrootify qmake. Mobile platforms
(Android and iOS) are not affected since they package binaries
separately. WASM and INTEGRITY are static builds and device paths
are not used.
Cross-compiled auto tests keep staging prefix in RPATHs due to
the behavior implemented in commit 20292250d4
which keeps the QEMU test runs working as before.
Pick-to: 6.3 6.2
Change-Id: If464ccd8cd9318a853df9afcb2aa709fbb2c1837
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The UB that the C and C++ standards talk about do not apply if we use
intrinsics. We can rely on the processors' architectural behavior
instead.
There are two ways to detect a conversion that cannot be represented in
the result. One would be to check if the #IE bit got set in the MXCSR,
but in order to do that we'd need two issue an STMXCSR+LDMCXSR pair to
clear the bit first and then another STMXCSR at the end to see if it got
set. Those instructions are 4 uops long and necessarily target memory,
so that's a bit slow.
This commit implements the second way, which is to check if the result
of the conversion is the "undefined" value. Unfortunately, that value is
a valid, precise value that double can hold for all data types except
unsigned 64-bit, so we need to recheck if that was the actual value
stored in the original double.
This implementation targets 64-bit exclusively because that avoids
having to deal with the 64-bit intrinsics not even being defined in 32-
bit code (converting a double to 64-bit integer in 32-bit is messy). The
unsigned implementation is only implemented with AVX512F because of the
unsigned conversion instructions that were introduced then.
Change-Id: I89446ea06b5742efb194fffd16bb9f04b2014bab
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
