To support cancellation of continuations attached via the parent future,
we store a pointer to continuation future's data in parent. This
requires preserving the lifetime of continuation future's data while the
parent is still alive (see 24dedaeaa1).
This is achieved by capturing the promise in the continuation's lambda,
which is only cleaned up after the parent's data is destroyed. This is
already the case for continuations without context, but was overlooked
for continuations with context: they transfer the ownership of the
continuation promise to lambda passed to QMetaObject::invokeMethod(),
which destroys the lambda's context after it's run. As a result, the
continuation's promise (and data, if there are no other copies of it)
is also destroyed, leaving the parent pointing to deleted continuation
data.
To fix this, capture a copy of continuation future's ref-counted data in
the continuation's lambda. This will guarantee that the continuation
data remains alive until the parent is destroyed and the continuation
is cleaned up.
Fixes: QTBUG-108790
Pick-to: 6.5 6.4 6.2
Change-Id: Ief4b37f31e652988d13b03499505ac65c7889226
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Makes the pre-existing QFutureInterface functionality available via
the public QPromise API.
[ChangeLog][QtCore][QPromise] Added addResults() to report multiple
results at once.
Change-Id: I18e6ef2781df422020b9022d78d6c45107b01668
Reviewed-by: Sona Kurazyan <kurazyan.sona@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to
handle typedefs and accesses through pointers, too:
const std::string o = "object";
auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); };
auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) {
auto exprOfDeclaredType = [&](auto decl) {
return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o);
};
return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))));
};
auto renameMethod = [&] (ArrayRef<StringRef> classes,
StringRef from, StringRef to) {
return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)),
callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))),
changeTo(cat(access(o, cat(to)), "()")),
cat("use '", to, "' instead of '", from, "'"));
};
renameMethod(<classes>, "count", "size");
renameMethod(<classes>, "length", "size");
except that the on() matcher has been replaced by one that doesn't
ignoreParens().
a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'.
Added two NOLINTNEXTLINEs in tst_qbitarray and tst_qcontiguouscache,
to avoid porting calls that explicitly test count().
Change-Id: Icfb8808c2ff4a30187e9935a51cad26987451c22
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace, with manual
unstaging of the actual definition and documentation in dist/,
src/corelib/doc/ and src/corelib/global/.
Task-number: QTBUG-99313
Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
To support cancellation of continuations attached via the parent future,
for each future returned by a continuation we store a pointer to its
parent (i.e. future the continuation is attached to). Later, before
executing a continuation, we go through chain of parents and check if
any of them is cancelled. However, if one of the parents is destroyed
while the chain is executing, the next continuations' parent pointers
will become invalid. So storing the parent pointers isn't safe.
This commit changes the logic of handling the cancelled continuation
chain in the following way:
- Instead of storing a parent pointer in the continuation future's data,
we do the opposite: we store a pointer to continuation's future in the
parent.
- When a future is cancelled, we mark all continuation futures in the
chain with a flag indicating that the chain is cancelled.
- To guarantee that the pointers to continuation future's data don't
become invalid, we clean the continuation (that stores a copy of its
future's data and keeps it alive) only when the associated promise
is destructed, instead of cleaning it after the continuation is run.
Fixes: QTBUG-105182
Fixes: QTBUG-106083
Pick-to: 6.2 6.3 6.4
Change-Id: I48afa98152672c0fc737112be4ca3b1b42f6ed30
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
__has_include(<chrono>) is always true, because C++11 chrono include
is required since 6.0.
Pick-to: 6.4 6.3 6.2
Change-Id: I50cb92571bf4f1f86e2f3f2b5f486dd3c3f30f4a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Or the previous limit, 10.
The test has a flaky and failing history, esp on macOS. Trying to
provoke race conditions with more threads than we have cores has little
value.
Pick-to: 6.4
Change-Id: I99dd2b5a6f64faa83963c279c84fc547416f914f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Deal with the case that the object gets deleted between a call to
moveToThread and the start of the thread by removing the object from the
list in that case.
Fixes: QTBUG-104014
Pick-to: 6.4
Change-Id: Ib249b6e8e8dfbc4d1332bb99a57fa9d3cff16465
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If we create a QThread from QThread::current(), we want it to have a
correct value for its bindingStatus. Thus, initialize bindingStatus in
the ctor of QAdoptedThread.
Task-number: QTBUG-101177
Task-number: QTBUG-102403
Pick-to: 6.4 6.3
Change-Id: I3ef27ed62c5dc25eed05d551c72743a1b8528318
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's always true these days, assert so in qatomic.cpp and
tst_QAtomicInteger.
Update the docs.
Pick-to: 6.4
Change-Id: I3684cff96c1d2e05677314e29514cc279bd6b1a1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the QFuture is canceled because the associated QPromise has been
destroyed, we still need to run its continuations (i.e. onCanceled
handler, if it's attached), so replaced the cleanContinuation() call
inside ~QPromise() with runContinuation(), which will also take care of
cleaning the continuation.
[ChangeLog][QtCore][Important Behavior Changes] QFuture now runs its
continuations when its associated QPromise has been destroyed.
Previously, if a QFuture was canceled because the associated QPromise
has been destroyed, its continuations were skipped.
Fixes: QTBUG-103992
Pick-to: 6.4 6.3 6.2
Change-Id: Ie05bc760c96c349aade8adb8d2fe5263aff8efac
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
We missed the terminating ";" in the QSKIP lines.
Amends ea4d6b987a
Pick-to: 6.3 6.4
Change-Id: Ibda43b8a84230c243dbcc74e157f4c3f8ef3891d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Thread termination might prevent stack unwinding, which then
generates ASAN errors such as
ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7f3c1d7858b0 at pc 0x7f3c243d8918 bp 0x7f3c1d7857f0 sp 0x7f3c1d7857e8
Skip such tests so that we can enable blocking CI runs under ASAN.
Fixes: QTBUG-104421
Pick-to: 6.4 6.3
Change-Id: I169235a12190e3f72525cddfe1a44a4bee19eca1
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Found by codespell
Pick-to: 6.4
Change-Id: Ie3e301a23830c773a2e9aff487c702a223d246eb
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
On finishing/terminating a thread, when processing posted events,
we need to consider QThread's own data instead of caller thread's data.
Otherwise we can get into unexpected situations such as double
destruction of an object, premature destruction, etc.
Fixes: QTBUG-103922
Pick-to: 6.4 6.3 6.3.1 6.2 5.15
Change-Id: Idf77221ebbaa0b150ee2d0c296b51829ae8dc30e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... in favor of including qabstracteventdispatcher_p.h, where needed.
Keeps the code DRY.
Change-Id: I5bee2e653cb29ffac2601ff03c952a4b3adbdb9c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add the Q_OS_WIN32 guard for the include of QWinEventNotifier.
Change-Id: I7824b2ee236a370c83fd85a2f594a39cf36b36e6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Added QFuture::unwrap() for unwrapping the future nested inside
QFuture<QFuture<T>>. QTBUG-86725 suggests doing the unwrapping
automatically inside .then(), but this will change the return type
of .then() that used to return QFuture<QFuture<T>> and might cause
SC breaks. Apart from that, QFuture::unwrap() might be helpful in
general, for asynchronous computations that return a nested QFuture.
[ChangeLog][QtCore][QFuture] Added QFuture::unwrap() for unwrapping the
future nested inside QFuture<QFuture<T>>.
Task-number: QTBUG-86725
Change-Id: I8886743aca261dca46f62d9dfcaead4a141d3dc4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Skip a test that uses QProcess instead of blacklisting it.
Re-enable this test in CMakeLists.txt, so that it can be checked
in the CI.
Fixes: QTBUG-87431
Pick-to: 6.3 6.2
Change-Id: If8a4acd60735f355dffa60c28b8d07695ee33ec8
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
For x86_32 the alignment of QBasicAtomicInteger<8 bytes> is not
equal to the alignment of TypeInStruct<8 bytes>, so do not perform
the check.
Fixes: QTBUG-87422
Pick-to: 6.3 6.2
Change-Id: I6e6c6cb7b2b7195e430d6a6991004bcfce16d4cb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the QPromise is being destroyed, we should signal the associated
futures to stop waiting. No matter in which state the promise is, if
it's not finished, we should always cancel to avoid infinite waits.
This is also what docs state:
"The promise implicitly transitions to a canceled state on destruction
unless finish() is called beforehand by the user."
Fixes: QTBUG-101284
Pick-to: 6.3 6.2
Change-Id: I65ebfefe03b79b41afacda78a4f49938c54d8b37
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
There is no reason to allow relock() on a locked locker, or unlock()
or an unlocked one, just like we don't allow that on a plain mutex
to begin with. The docs already said that e.g. relock() locks an
_unlocked_ locker.
[ChangeLog][QtCore][QMutexLocker] QMutexLocker allowed relock() and
unlock() on an already closed (resp. open) locker object. These
semantics have always been undocumented and are now unsupported
(in both cases they yield undefined behavior.)
Change-Id: Id5f67beb5dc30d6435dae88a3085fba93ec7d96e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The class is similar to unique_lock in that it allows for unlocking
and relocking. Since the locked state is tracked by QMutexLocker itself,
it's trivial to make it movable.
[ChangeLog][QtCore][QMutexLocker] The class is now movable.
Change-Id: I534044f8024575e996c12efb2236761d493798a3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Connecting to nullptr, or connecting to a non-signal PMF, would result
in a QFuture which would never finish. Catch these cases and handle
them.
Windows+MSVC for some reason fails the test. I can't entirely understand
why, so I've marked it as XFAIL, with QTBUG-101761 to track it.
Change-Id: I314980e7e9b7156d8cddd3b33d5cbf1d0bcd6116
Pick-to: 6.2 6.3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
tst_QFutureWatcher was deactivated for Android. This patch activates it.
Fixes: QTBUG-88136
Change-Id: Iead82e22d73eb15c9ecd2756eb33925910bbffc0
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
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>
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 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>
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>
Suppress the error:
C1128: number of sections exceeded ... limit: compile with /bigobj
Fix by setting the correct target in CMake script.
Pick-to: 6.2 6.3
Change-Id: If241fbaa70b68ca698dae2d484146e7bac970609
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Filter out the last argument of type QPrivateSignal from the signal's
arguments passed to QtFuture::connect().
Pick-to: 6.2
Fixes: QTBUG-92501
Change-Id: Idcd6baba1f01fcc94fa64b1c7030a629d01ed7a1
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
If one destroys a running QThread, so far the behavior has been to crash
(à la std::thread) -- assuming the thread hasn't already signalled that
it has finished. This behavior is hostile to solutions such as using
QThread::create(), which always require a wait() before destroying the
thread object.
We can use the opportunity to change the behavior without breaking any
valid code. Instead of crashing, inside QThread's destructor we can ask
the new thread to quit, and then join it (à la std::jthread). This
simplifies the implementation of long-living runnables and the code that
manages them.
Deploying this solution for the whole QThread class may not be entirely
painless. While no correct code would work differently with the proposed
changes, incorrect code that deletes a running thread would no longer
crash "loudly" -- instead, it might deadlock "quietly", have memory
corruptions, etc.
Hence I'm limiting this approach to only the threads created by
QThread::create(), at least for the time being. This also side-steps
perhaps the biggest problem of generalizing the approach, which is that
placing such interrupt+join logic into~QThread's destructor would cause
it to be run _after_ a QThread subclass' own destructor has run,
destroying the subclass' data members too early. This might create
an antipattern if one chooses to subclass QThread. With create(), a
subclass in question exists, and it indeed has NSDMs, but it's entirely
under our control (in fact, I'm placing the logic just in its dtor).
[ChangeLog][QtCore][QThread] Destroying a QThread object created by
QThread::create() while the thread that it manages is still running will
now automatically ask that thread to quit, and will wait until the
thread has finished. Before, this resulted in a program crash. See the
documentation of QThread::~QThread() for more details.
Change-Id: Ib268b13da422e277ee3ed6f6c7b2ecc8cea5750c
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
std::function, which is used to store the type-erased continuation
lambdas, requires the passed callable to be copy-constructible. This
makes impossible to use move-only callables with continuations/handlers.
In particular, it makes impossible passing lambdas that are capturing
move-only objects. The workaround is to store the continuation lambda
inside a wrapper for the callable, which stores the move-only lambda in
a QSharedPtr and can be stored in std::function, since it's copyable.
Pick-to: 6.2
Fixes: QTBUG-98493
Change-Id: I8b7a22fcf68dc132b3c533216a7a1665e9f9fb0a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Use variable args macros to swallow any extra commas in the
expression. To use this, the type of the exception has to be first.
Use Eddy's suggestion for a new name to avoid breaking the old macro.
[ChangeLog][QtTest] Added QVERIFY_THROWS_EXCEPTION, replacing
QVERIFY_EXCEPTION_THROWN, which has therefore been deprecated.
Change-Id: I16825c35bae0631c5fad5a9a3ace4d6edc067f83
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We have some special handling in qt_windows.h,
use it instead of the original windows.h
Change-Id: I12fa45b09d3f2aad355573dce45861d7d28e1d77
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
[ChangeLog][QtCore] Added QtFuture::whenAll() and QtFuture::whenAny()
functions, returning a QFuture that becomes ready when all or any of the
supplied futures complete.
Task-number: QTBUG-86714
Change-Id: I2bb7dbb4cdc4f79a7a4fd494142df6a0f93a2b39
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
