[ChangeLog][Potentially Source-Incompatible Changes] The qmetatype.h
header no longer includes qvarlengtharray. It might be necessary to
include the header explicitly if code previously relied on it being
implicitly included.
Change-Id: If58245836715ec8a323ec8cbadc67d73a742b15f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Since this is only used by qtpaths and qmake, let's not make every
application pay the price of dynamically initializing a QString whenever
QtCore is loaded (which 100% of Qt applications do). Instead,
initializing a null pointer costs zero and is one third the size of
QString. Even the assignment in qmake and qtpaths is faster this way.
Pick-to: 6.3
Change-Id: I6fcda969a9e9427198bffffd16ce8d1eb8dc19da
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Clang-cl supports the clang detections, and only approximates specific
MSVC version.
This works as the MSVC standard library is ahead of the clang standard
library. Where this logic was written 7 years ago when it was not the
case.
Pick-to: 6.3
Change-Id: Ic13e2f2fbcde011a0d8831cc48c0c9041bfe3b99
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change ref() and deref() in qatomic_cxx11.h to use acq_rel ordered
semantics as documented instead of the stricter sequential consistency
that was previously used implicitly.
It was pointed out in the discussion on atomic reference counts that
acq_rel semantics should be sufficient for reference counts. It also
turned out that that is all that the definition of "Ordered" in the
documentation really guarantees.
Original-patch-by: Kevin Kofler <kevin.kofler@chello.at>
Change-Id: I6cd50b34bdc699ff8b7c8fe6d303b28d71494731
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The string was used as the return value of QLibraryInfo::build() and
also string-pasted into the format string in qt_core_boilerplate(). As
a proper substring (not suffix) of the format string, QT_BUILD_STR
could not be shared among the two users.
Fix by interpolating QT_BUILD_STR into the format string, so
QT_BUILD_STR appears by itself in both functions. The string should
now be shared, but compilers have quite low limits on lengths of
strings they will share, so turn the macro into an static function so
the actual string literal appears only once, guaranteeing
de-duplication.
It also feels a bit safer to interpolate the build string instead of
pasting it into the format string; it's not immediately obvious that
it cannot contain %s itself, even if we could expect a compiler
warning in that case.
Change-Id: I69d90c37c3a3dcf8ac46d4f36e7c0d2cf3b947af
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's literally
return true; // or
return false;
so it can be marked as noexcept and (the stronger form of) pure.
Change-Id: Id55fee1db5d18201be2ea6c6778ece3de68b05f2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Even if it's unlikely any of those would exceed 2 billion entries.
Pick-to: 6.3 6.2
Change-Id: Ib0d4d4e7a64fcde03b7f24bc0667d63c4a737deb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Apple Clang 12:
qcalendar.cpp:456:22: error: loop variable '[key, value]' is always a copy because the range of type 'QFlatMap<QString,
QCalendarBackend *, (anonymous namespace)::CaseInsensitiveAnyStringViewLessThan, QStringList, std::vector<QCalendarBackend *>
>' (aka 'QFlatMap<QString, QCalendarBackend *, (anonymous namespace)::CaseInsensitiveAnyStringViewLessThan, QList<QString>,
vector<QCalendarBackend *> >') does not return a reference [-Werror,-Wrange-loop-analysis]
for (const auto &[key, value] : byName) {
^
Change-Id: I54f205f6b7314351b078fffd16d05e5cd3ef4c22
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Because it's BiC.
From the API review.
Pick-to: 6.3
Change-Id: I69f1fe58428241a876ae9058e8a0108a8e496c22
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's more efficient than our QThreadStorage and definitely much better
than the Q_GLOBAL_STATIC+QThreadStorage solution. We can do this because
the last compiler not to have thread_local support was MSVC 2013, which
is no longer supported since Qt 5.11.
QThreadStorage also managed the lifetimes of pointers for us, so the
equivalent thread_local requires std::unique_ptr.
Change-Id: Id59bdd8f1a804b809e22fffd15405f1b394c48d8
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
When QCborValue referred to an empty array or map, toArray() and toMap()
would respectively return the default value instead of the empty object,
as expected.
Pick-to: 6.2 6.3
Change-Id: I5e52dc5b093c43a3b678fffd16b60456d0037ad7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Instead of duplicating two dynamically-initialized statics each in two
functions, causing four threading guards to be emitted by the
compiler, pack the two variables into a static struct and the struct
into an Extracted Method, leaving just a single threading guard.
https://godbolt.org/z/a9e5o848f
Uses C++14 NSDMI-in-aggregates, so doesn't work in 5.15.
Pick-to: 6.3 6.2
Change-Id: I98e053df48aafd5720ceffd514d6811fd3b28b1a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The call becomes simpler, and QCollator no longer needs to befriend
QString.
Pick-to: 6.3
Change-Id: Ie2c977dc39973423f07563a0702a83fa3c75270d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Fixes errors like
In file included from
qtbase/include/QtCore/6.4.0/QtCore/private/qcore_mac_p.h:1:
qtbase/src/corelib/kernel/qcore_mac_p.h:61:9:
error: unknown type name 'mach_port_t'
Amends e05300163e
Pick-to: 6.2 6.3
Change-Id: I8f4c579e9b8ef187859497361c4e126a486a543c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Use Q_CORE_REMOVED_SINCE macro for fromAce()/toAce() API changes.
Pick-to: 6.3
Change-Id: I057c6d648c2141929f04e4b4c4a38ba3275261ab
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Use Q_CORE_REMOVED_SINCE macro for languageToCode()/codeToLanguage()
API changes.
Pick-to: 6.3
Change-Id: I8cc5279b1272165541c345241af49523c0f25737
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
A default-constructed QPluginLoader erroneously reports that the
load hints are empty. However, setting a filename would then
automatically set the PreventUnload hint, surprising the user.
Return the correct flags instead.
Amends 494376f980
Change-Id: I7a95964cb680afd3adf2f71ed73d2f93023238f2
Fixes: QTBUG-100416
Pick-to: 5.15 6.2 6.3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It is an important and useful part of the API contract that the
QFutureWatcher signals will emit complete information after
setFuture() on an already started QFuture. If that wasn't so, some
API clients would need two code paths to gather state and progress
information: one through the signals for not yet started QFutures,
and one through the state querying APIs for already started
QFutures.
The previous documentation was not precise enough to rely on, even
though the implemented behavior - cf.
QFutureInterfaceBasePrivate::connectOutputInterface() -
seems well thought out and implemented to rely on.
Pick-to: 6.3 6.2
Change-Id: Iaf3db37a851f07ac85881adaea5c83612a7fd843
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Avoid, for years before the first rule, a whole lot of complications
needed when handling dates later than that rule's start. It is not
entirely clear the code would previously have Done The Right Thing; it
now is clear what it does.
Change-Id: I00a79c0a4733f1deb0bbfecb03e1c64a104d08a3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
To support clang-cl builds, until we add the necessary logic to enable
function targets for this case.
Pick-to: 6.3
Fixes: QTBUG-98253
Change-Id: Ied296babaa85a13321663d50019fad49134f0f44
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Slightly simpler implementation for the tail because of the OpMask
support.
Change-Id: I60fdef243d0c4e04890dfffd16266facd53d78aa
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Since we require C++17 now we can use auto for the retain and release
template arguments, which allows us to get rid of the wrapper functions
for IOObjectRetain and IOObjectRelease.
Pick-to: 6.2 6.3
Change-Id: Ifc4bf0fe50dfd0eaf6bb2e143acce6df7df17bdc
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Some configurations (like MSVC2019 with c++20 on Windows 10) fail
to compile winrt/cpp headers as these include experimental
coroutines unconditionally. In these cases we can fall back to the
legacy implementation.
Pick-to: 6.2 6.3
Change-Id: Ibd574995f8ca1f865bbcdabede1ffcd0c340022f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Introduce the qdoc macros \cmakecommandsince, \cmakepropertysince, and
\cmakevariablesince that insert a paragraph akin to the \since context
command.
Example:
\cmakecommandsince 6.3
produces the paragraph
This command was introduced in Qt 6.3
The macro text is wrapped in \n\n to ensure that we always generate a
new paragraph.
Pick-to: 6.2 6.3
Task-number: QTBUG-100212
Change-Id: Id5c8e8812e6b0b915674d108a0e775091e9eacd8
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR
code in each example project.
This was an internal workaround to ensure examples are installed into
a relative path somewhere under $qt_prefix/examples and not in
$qt_prefix/bin or similar.
To achieve that we do two things.
First, deduce the install prefix for each example in the
implementation of qt_internal_add_example (our add_subdirectory
wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling
add_subdirectory. We need to make sure to remove the default
value of CMAKE_INSTALL_PREFIX in the generated
cmake_install.cmake file.
Second, we set an internal variable called
QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory
call, which will be checked whenever find_package(Qt6Core) is called
in an example project. If the variable is set, the
INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core
is found.
This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our
example projects are changed to ".".
With both changes, our example project install(TARGET DESTINATION)
calls will now install to
"${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/."
Once all repositories are updated to use qt_internal_add_example
instead of add_subdirectory, we can get rid of the
QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround.
For repositories that still don't use qt_internal_add_example,
the install prefix rewriting will not happen, but the examples will
still be installed to the proper place because they use their own
hardcoded INSTALL_EXAMPLEDIR value.
Amends d97fd7af2b
Pick-to: 6.2 6.3
Task-number: QTBUG-96232
Task-number: QTBUG-98545
Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Use IMPORTED_LOCATION of rcc target when generating Android
deployment settings, instead of the hardcoded host path.
Introduce a helper function to find the location of the imported tool
target.
Change-Id: Icfa51ee7a01b3f58fc4892da03055f9ed531cc0b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Even in C++98 one could declare variables in if statements and
contextually convert them to bool:
if (D* d = dynamic_cast<D*>(base))
~~~
else if (D2* d = dynamic_cast<D2*>(base))
~~~
std::optional is contextually convertible to bool, so we don't need
C++17 if initializers. Just use
if (auto optional = ~~~~)
Pick-to: 6.3
Change-Id: Ie64c2c1ceb7b608eda0534d837f46d3c4be49bf8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A single global QT_REMOVED_SINCE will start hurting us once more
modules downstream of QtCore start using the mechanism.
With every use of feature, the set of code that needs to compile under
QT_BUILD_REMOVED_API increases. Since we use QT_REMOVED_SINCE in
situations where overloading the new and the old function don't work
in general, this means all code included by any removed_api.cpp needs
to be very carefully written to ensure that any calls to the overload
set formed by the combination of old and new function(s) don't create
ambiguities.
Likewise, the set of APIs that change semantics under
QT_BUILD_REMOVED_API also increases. At some point, the combination of
removed_api.cpp including almost every module header and almost every
header exposing source-incompatibilities when included in
removed_api.cpp will make maintenance a headache.
By making QT_REMOVED_SINCE and QT_BUILD_REMOVED_API per-module
(QT_CORE_REMOVED_SINCE, ...), easy now that we generate the export
macros using CMake, we limit the scope of this problem to the module
using the feature. Downstream modules (say, QtWidgets) will now see
the QtCore API like every other user, even in the
widgets/compat/removed_api.cpp TU.
Pick-to: 6.3
Change-Id: I177bc7bd5aa8791639f97946c98e4592d2c7f9d9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
... and thereby also QPointer's.
Found by applying C++20 constinit around the codebase.
Pick-to: 6.3 6.2
Change-Id: I9f149b2346624ca913c29b796f94ac7d24fe560a
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
QWinTimeZonePrivate::data()'s search for a rule applicable to a given
time, in the first year whose milliseconds qint64 can represent, tries
to look at the preceding year to get start-of-year data, which leads
to misleading results. It does so to determine whether to use a rule's
standard or daylight-saving details, but this year is long before the
invention of daylight-saving time, so we can bypass the whole mess.
Unfortunately, MS's data does pretend (in some zones) that DST has
always been in effect, so cutting off that claim at some historical
point will actually get better results for before the cut-off than for
the period after it, until the relevant zone actually adopted DST.
Conservatively put the cut-off at 1900, before any actual zone used
DST, albeit after the idea was originally floated.
This fixes a failure found by some QDate::{start,end}OfDay() tests
that I want to introduce.
Pick-to: 6.3
Task-number: QTBUG-99747
Change-Id: I15cf9dd092b946191e8863c7e85fbeb4ba6c106d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Unlike many other uses of QFlatMap, this actually promises to hit the
QFlatMap sweet spot, and we're using all its levers.
To wit:
- Enable lookup via QAnyStringView through a transparent comparator
without having to convert the QAnyStringView to QString first. This
is impossible with QHash, because qHash() values are not consistent
for different string types: u"a"_qsv == "a"_L1, but qHash(u"a"_qsv)
!= qHash("a"_L1). The relational operators don't have this
consistency problem, and they also implement case-insensitive
comparison, another thing qHash lacks.
- Pick different types of containers for keys and values. For the
keys, use QStringList, which makes availableCalendars() trivial and
extremely fast. We can reserve() the flat_map to limit the effect of
reallocations, because we have a pretty good idea about how many
entries we'll have. For the values, use the same container as for
byID. This might be better with QVarLengthArray, but that's for
another patch.
- Fix the double lookup in registerBackendLockHeld() by using
try_emplace() instead of contains() + insert().
To enable QFlatMap's full potential, we still need to teach
ensurePopulated() to create the two containers for the QFlatMap
unordered and let QFlatMap sort them in one go, but that, too, is for
another patch.
Change-Id: I7fe4f3f7596e9b234696fbc8e467128b85629f8a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Division and modulo are guaranteed to be consistent, with the former
truncating towards zero, so the latter giving a remainder that either
is zero or has the same sign as the numerator. In particular, when the
numerator is positive, the remainder is necessarily greater than minus
it, so the formerly correct but unilluminating arithmetic necessarily
gave the answer one and we can just --jd rather than doing anything
cleverer. Assert the fact that ensures this.
Pick-to: 6.3 6.2
Change-Id: Ia718bb947192f1fd2eb36549be12d30e4ee03d58
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@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 private binary_find() overload set is literally identical to the
public find() one, so cut out the middle man.
One less level of function templates to compile.
Pick-to: 6.3
Change-Id: Ia7b248d883b7bcff39c4f7b470d2567970572885
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The backend was already ported, so this is just about applying
QT_REMOVED_SINCE and updating the docs.
Change-Id: I2c78908deb9cdb3cee19ce8bc148ab3117c1ad9a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Move the do_{remove,take}() functions into the private section,
cleaning up after the previous step.
Pick-to: 6.3
Change-Id: I3325336458b34e7f376b42bfe68355d93ff4ce70
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
We don't have to be completely sequential. It's perfectly fine to
overlap loads and stores and this leads to simpler code.
Change-Id: I6fcda969a9e9427198bffffd16ce56ebbc948379
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Commit 0df7831d01 moved these functions
into this file, but forgot to add the marker.
Drive-by replace Q_DECL_NOEXCEPT with noexcept
Pick-to: 6.3
Change-Id: I6fcda969a9e9427198bffffd16ce5543c5fd544e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Those three features can't be used without the VEX prefix, which
requires that the OS has enabled saving of the AVX state on context
switches (i.e., use XSAVE).
The list is automatically maintained by the updated script in
OpenDCDiag[1]. I need to update the copy in util/x86simdgen.
[1] https://github.com/opendcdiag/opendcdiag/blob/main/framework/scripts/x86simd_generate.pl
Pick-to: 6.3
Change-Id: I6fcda969a9e9427198bffffd16ce55193a6cb069
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
This function can allocate memory, so it's not pure.
Pick-to: 5.15 6.2 6.3
Change-Id: I6fcda969a9e9427198bffffd16ce7fcff3ae021d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Use memchr() if the needle has size() one, and add a fast path in
findString(QLatin1String, QStringView) to circumvent the QVLA path. We
might want to extend this and use a simple C array for very short
needles and (cached?) Boyer-Moore for anything larger.
Pick-to: 6.3
Change-Id: I8364ea9f004d537be8a09cc751408d8adb902d13
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Extract Methods do_foo(iterator) from their respective foo(Key)
methods.
This is done in order to separate the common code from the code that
will differ in the is_transparent overloads.
Leave the function bodies where they previously appeared, for easier
reviewing.
Pick-to: 6.3
Change-Id: I49f41f9121a047df696f39daeaa0a9da6a16dddb
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Saves the <qdebug.h> include and expands to a lot less code.
Pick-to: 6.3 6.2
Change-Id: Ic1a0aa707e7c0d4bd54da45a7fcafbf898681b2d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Shorter, because it doesn't need to name the type.
As a drive-by, replace all remaining uses of the private full_map_t
alias with 'QFlatMap', the class name, which, also in templates,
refers to the class, not the class template.
Pick-to: 6.3 6.2
Change-Id: Ie3bada43d9d28a84543e8baa8a36c522dff80b9e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
GCC doesn't like that we modify the contents of passed by pointer in the
pure function. Reading the description of this attribute in the GCC
manual was ambiguous then, but I can see the GCC maintainers'
interpretation.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104243
Fixes: QTBUG-62185
Pick-to: 5.15 6.2 6.3
Change-Id: I6fcda969a9e9427198bffffd16cdf815d059d252
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
We had QT_NO_JAVA_STYLE_ITERATORS in .qmake.conf, but it was lost in
the transition from QMake to CMake, and - plop - they start trickling
in again.
Pick-to: 6.3 6.2
Change-Id: Ib92937e5fe510aba2aad92809f7a6d5fbae6f3a0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
An alternative would have been QDuplicateTracker, but the maximum
number of entries in the tracker is statically limited to six, so we
don't need a fancy hash table, linear scan is good enough.
Pick-to: 6.3
Change-Id: I8ca97d239723b51892cb13a43b1d1a6412faa561
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
For a long time now we have fast mixed UTF-16/UTF-8 comparisons. But
no-one told this ol' relic, which still converted UTF-8 to UTF-16 for
comparison.
Fix by using QtPrivate::compareStrings(QSV, QU8SV), which, as the
central entry point, uses the fast-path.
Consequently, compare_helper can now be noexcept.
Pick-to: 6.3 6.2
Change-Id: I4cc9f07d9bc48628f1fe695e80015a9a07b79d6f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Generic code needs to avoid post-increment and -decrement, because
they're less efficient than pre-increment and -decrement when
implemented in class types as opposed to scalars (extra copy
necessary).
Use the common pattern of implementing post- using pre-increment.
Pick-to: 6.3
Change-Id: Ida38df04c6c6f877453e5b3a1983457cc7f63f11
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This leaves moc_qnamespace.cpp in mocs_compilation.cpp.
Including moc files directly into their classes' TU tends to improve
codegen and enables extended compiler warnings, e.g. about unused
private functions or fields.
Pick-to: 6.3 6.2 5.15
Change-Id: Ifdff378c74828e12ec770cb2f453dab3a880e2a5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
By Amdahl's Law, provides for more scalability.
This is just for backporting. The registry should really be able to
perform lookups without allocating memory...
Pick-to: 6.3 6.2
Change-Id: Ifbb832a06991b9ee9a1fd6a43db567bb572fca4f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The global 'aab' target has its own switch QT_NO_GLOBAL_AAB_TARGET
that prevents it from being created. We need to check if 'aab' target
exists before adding <target>_make_aab as a dependency.
Pick-to: 6.3 6.2
Change-Id: Iea569e3b6c7dfb6d0efa60dd2001fb9de161f725
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We discourage using AUTORCC, so don't make it the default for our
"standard project setup".
Pick-to: 6.3
Task-number: QTBUG-87643
Task-number: QTBUG-100209
Change-Id: I2715ec561266bfed5ea4ac7722ab1f1c8b982788
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Inclusion of qt_windows.h is needed to avoid "No Target Architecture"
in winnt.h.
Change-Id: Ic67ce8a306ef52c4ce3e6eaad0b7864632610737
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This reverts commit 1c164ec7f2,
except for the test additions.
Reason for revert: We need to optimize the implementation, not
complicate the API.
Found during the 6.3 API review.
Pick-to: 6.3
Change-Id: I91c3f65ed6d1fc438deb0e028d578a07c0005362
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
1. Clang-CL can't recognize "/d2FH4" and it's causing
lots of warnings when compiling. So don't apply it
when building with clang-cl.
2. The definition of "FS_INFORMATION_CLASS" need to
be visible to clang as well. Don't know why it was
excluded originally.
Pick-to: 6.3
Change-Id: I7b6e14999eea0ba1f0d73962ff03a35548f88a5a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The tolerance can be set per timer, unlike on Linux.
Fixes: QTBUG-98316
Change-Id: I5e52dc5b093c43a3b678fffd16b788a30bcb9574
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It would check the version regardless of OS, but this macro doesn't exist
on non-darwin platforms.
Amends 3446313c7a
Pick-to: 6.3
Change-Id: I7bdc302c85626d410e77bea1eb7aac7fbf1cb679
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
From the API review.
Pick-to: 6.3
Change-Id: I9877990f75189b99a372ea6342d07a7031228ac7
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This enables the code also for boostrap.
Amends b24e689cb5.
Pick-to: 6.3
Change-Id: I8efc76c20690282a2428f360d6b93896966b97ee
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We were converting the full L1 haystack to UTF-16. But, even so, we
won't be able to find non-L1 UTF-16 needles in L1 haystacks!
Optimize by converting the needle (not the haystack) to L1, after
checking it's actually L1.
Pick-to: 6.3
Change-Id: I413d7a602d44ecb2d3149dc4fa87c690c40e6aaa
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>
QPromise is now used in qfuture_impl.h, so we need to include it. Remove
qfuture.h include from qpromise.h, to avoid circular dependency.
As a drive-by, simplify a type-trait: is_convertible_v<T, S> is true
whenever is_same_v<T, S> is, so we don't need to instantiate both.
Fixes: QTBUG-100144
Pick-to: 6.3 6.2
Change-Id: Ic6df43d96d9d168cc44c2949e41c5e490f4c50ce
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
MSVC complains about illegal uses of void, even though the code should
be guarded by an if constexpr statement.
qproperty.h(85): error C2182: 'val': illegal use of type 'void'
qproperty.h(92): error C2182: 'abstract declarator': illegal use of type 'void'
Avoid the issue by using a dedicated dummy type instead of void.
Fixes: QTBUG-100072
Task-number: QTQAINFRA-4242
Pick-to: 6.3 6.2
Change-Id: Idc4886c26c3794e709eb762ba836139f720f8133
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Base class dtors should either be public and virtual or else protected
and non-virtual.
We don't want to model polymorphy, so protected and non-virtual it is.
Pick-to: 6.3
Change-Id: I3c545b01c3ec831ee8b4a0c522501222a69923e9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
On 32-bit machines, qsizetype is int, so we don't actually need to
QT_REMOVE_SINCE the QByteArrayList_join() helper, because it didn't
change.
Thanks to Thiago for showing me the QT_POINTER_SIZE trick in a similar
change to QVersionNumber.
Pick-to: 6.3
Change-Id: Iae6e315107e42da51fcb4e7325b6d40b9c3fe0bc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Null- vs. emptiness of the separator is not significant for join(), so
skip the isNull() check in the conversion ctor of QByteArrayView from
QByteArray by using the named conversion function that exists for this
purpose instead.
Pick-to: 6.3
Change-Id: I6ef07cc9bcc0bc8b87ecadc5cfaac9793cfb1b77
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
... instead of waiting for Qt 7.
Found in API review.
[ChangeLog][QtCore][Potentially Source-Incompatible Changes]
[QByteArrayList] The join() overload set has changed. Code such as
qOverload<>(&QByteArrayList::join) will have to be rewritten,
e.g. using lambdas. We advise against taking addresses of library
functions other than signals and slots.
Pick-to: 6.3
Change-Id: I67449df9adc2efea7f1163034caa135f31f39e7c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This class is universally supported by all Qt6-capable compilers.
Pick-to: 6.3 6.2
Change-Id: Ib03ed8f73fe656e47f4d0f8f50c3a8ff95b6d8d4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The loop for 32 bytes is left unchanged, but the tail operation for 16
to 31 bytes is replaced with an overlapped load-and-scramble. This
should make the operation even faster.
Also updated the key creation back to something similar to what Go does.
This massively improves performance as well as the bit spread. Histogram
for the bits in the hash value for the testcase from QTBUG-91739:
|| Bit || Before || After ||
| 0 | 35.0300% | 50.4800% |
| 1 | 42.5250% | 50.2400% |
| 2 | 46.0100% | 50.0000% |
| 3 | 67.5150% | 49.9400% |
| 4 | 56.5150% | 50.0000% |
| 5 | 51.9950% | 50.0000% |
| 6 | 58.9800% | 50.1400% |
| 7 | 55.9550% | 50.0000% |
| 8 | 41.9850% | 49.9200% |
| 9 | 69.9700% | 49.6400% |
| 10 | 68.4950% | 50.0000% |
| 11 | 37.4950% | 50.3000% |
| 12 | 61.9950% | 49.8200% |
| 13 | 53.4900% | 50.0000% |
| 14 | 63.0200% | 49.9800% |
| 15 | 54.9700% | 50.1000% |
Task-number: QTBUG-91739
Pick-to: 6.2.3 6.2 6.3
Change-Id: Icad7c1bad46a449c8e8afffd16cb7fe7ffd3584f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
[ChangeLog][QtCore][QHash] Fixed a bug in the qHashBits() function,
which affected the hashing of QByteArray, QString (and their View
classes), QLatin1String and QBitArray, which caused the hash to not
include the final 32 bytes of the data source. As a result, QHash
containers where the initial string was the same had a serious
performance degradation on x86 CPUs with AES support.
Fixes: QTBUG-91739
Pick-to: 6.2.3 6.2 6.3
Change-Id: Icad7c1bad46a449c8e8afffd16cb74dd43440f6c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We don't need to test for actually crossing a page boundary. It suffices
to check if we're in the upper half or the lower half of the page. In
the upper half, we load ending at the end; in the lower half, we load
starting at the current position. This way, it can never crash.
Pick-to: 6.2.3 6.2 6.3
Change-Id: Icad7c1bad46a449c8e8afffd16cb743e622b3405
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Took me a few seconds to figure this out, and I'm the author of the
class, so leave a comment for my future self (and anyone else).
Pick-to: 6.3 6.2 5.15
Change-Id: I65a7aa6f8abf9d671f7d9ba45400f19e0f46728f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The Boyer-Moore tables can be calculated at compile-time, and the
needles are long enough to make skipping worthwhile, even for small
haystacks.
Pick-to: 6.3
Change-Id: I3237812490367ed0491eb8d1667c6da67f38c517
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The new overloads mean that when passing QByteArrayView or
QLatin1String objects, we don't expand them into .data() and
.size() anymore.
Pick-to: 6.3
Change-Id: I0c898e0463d0bf81ce1f7d57e10e64f23bd84587
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
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>
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>
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>
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>
Fabian Kosmale
Thiago Macieira
Allan Sandfeld Jensen
Marc Mutz
Mårten Nordheim
Sona Kurazyan
Alexandru Croitor
Ievgenii Meshcheriakov
Giuseppe D'Angelo
Alexey Edelev
Andreas Hartmetz
Edward Welbourne
Tor Arne Vestbø
Oliver Wolff
Joerg Bornemann
Jani Heikkinen
Yuhang Zhao
Ulf Hermann