... when instantiating the MetaTypeQFutureHelper for QFuture<void>.
Simply enabling /W4 for tst_qfuture also generates this warning, but
also much more. So I'm not providing any unit-test here.
Amends 90d9a86c2e762c9426d0facbd54ed5dbff574ecd.
Fixes: QTBUG-133406
Pick-to: 6.9 6.9.0 6.8 6.5
Change-Id: I22a53b872818763b80f333f597ddd19a1c1e30ac
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This method should be used on a future returned from the long
continuation chain, if this chain needs to be canceled altogether.
To achieve it, this commit introduces a pointer to the parent data.
That pointer is set when setContinuation() is called, and cleaned
when the parent is completed and calls its runContinuation()
method. This allows the code in cancelChain() to simply move up
the chain as long as the parent pointer is valid, and cancel each
of the continuations.
The commit also moves the QFIB::cancel() implementation into
QFIBP::cancelImpl(), so that it can be reused in the new method,
and introduces an enum for cancellation options, to address the
differences in the behavior between these two methods.
Note that the approach consistently works only on the last QFuture
of the chain, because the already-executed continuations might
clear their continuation data, which makes navigating down the
chain inconsistent.
[ChangeLog][QtCore][QFuture] Added QFuture::cancelChain().
Fixes: QTBUG-130662
Change-Id: Ic0949ed30a2f54f99597e95b3951fda6bfb9a0be
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The Continuation class is a template and polymorphic, which likely
means that it instantiates a new type with a vtable for each
combination of template parameters.
Remove the Sync/Async continuation classes to get rid of the hierarcy.
Instead, encode all the information about the type of the continuation
into the class itself. This requires to add two new members:
* QThreadPool (which was previously a member of an async class)
* QRunnable (async class was previously derived from it).
We cannot really eliminate the need for QThreadPool and QRunnable
without a larger refactoring of the entire QFuture framework, because
QFutureInterface requires a QRunnable in its implementation.
However, this patch already allows us to get rid of all the virtual
functions in the Continuation implementation.
While on it, also remove the Function member and derive from
QtPrivate::CompactStorage<Function> instead.
This results in a significant reduce of a binary size for the user
projects, specially if they have a wide usage of continuations.
Taking tst_qfuture as an extreme example, the binary size on a
release build on macOS is reduced by ~15% - from 3723576 to 3156344
bytes.
The change seems to be BC, because all Continuation usages are from
the inline code in other template classes, so most probably a binary
linked with the older version of Qt will simply keep using the old
implementation.
Still, if the user project creates a shared library that utilizes
continuations, and builds the library with the default visibility
attributes, the private Continuation class gets exposed in the
exported methods. To avoid ODR violations in such cases, simply
rename the class to CompactContinuation.
Fixes: QTBUG-124909
Change-Id: I8c8263dbaf407d922aed2017d659bbc6fd87083d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace class operators operator==(), operator!=() of
QFuture::const_iterator: to friend method comparesEqual() and
Q_DECLARE_EQUALITY_COMPARABLE macro.
Task-number: QTBUG-120304
Change-Id: Ifa264b83f4d5623db99820847ab9a800cca99be2
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The compilers will only warn about using makeValueFuture from
Qt 6.10 onwards. Anyhow, for the documentation, it makes more
sense to deprecate it right now, as an alternative API is
available. So deprecate in documentation for Qt 6.6, but
mention that the compiler warning will only be shown in Qt
6.10.
While at it, also make sure the deprecation messages are
proper sentences (end with a dot).
Pick-to: 6.6
Fixes: QTBUG-116898
Change-Id: Iff90441372b788f9ea42634866d97068275bf0ca
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
[ChangeLog][Deprecation Notice][QtCore] The QtFuture::makeReadyFuture()
method and all its specializations are deprecated since Qt 6.10.
The reason for the deprecation is that the method has a
makeReadyFuture(const QList<T> &) overload, which behaves differently
from all other overloads (including other non-const ref QList
overloads).
Use QtFuture::makeReadyVoidFuture() when you need a ready void QFuture,
or QtFuture::makeReadyValueFuture() when you need to propagate the
input type to the returned QFuture, or QtFuture::makeReadyRangeFuture()
when you need to create a multi-value future based on an input
container.
Fixes: QTBUG-109677
Change-Id: I55125269989df0a02840d5ddd5763ef5f1070df5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
[ChangeLog][QtCore][QFuture] Added QtFuture::makeReadyVoidFuture()
and QtFuture::makeReadyValueFuture().
Basically, these methods behave like QtFuture::makeReadyFuture(), but
QtFuture::makeReadyValueFuture() does not have a "const QList<T> &"
specialization returning QFuture<T> instead of QFuture<QList<T>>,
which allows it to always behave consistently.
This patch also introduces usage of the new methods around qtbase.
Task-number: QTBUG-109677
Change-Id: I89df8b26d82c192baad69efb5df517a8b182995f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
To allow the user to customize the C++ code that QDoc sees, so as to be
able to work-around some limitations on QDoc itself, QDoc defines two
symbols: Q_QDOC and Q_CLANG_QDOC, both of which are "true" during an
entire execution of QDoc.
At a certain point in time, QDoc allowed the user the choice between a
custom C++ parser and a Clang based one.
The Q_QDOC symbol would always be defined while the Q_CLANG_QDOC symbol
would be defined only when the Clang based parser was chosen.
In more recent times, QDoc always uses a Clang based parser, such that
both Q_CLANG_QDOC and Q_QDOC are always defined, making them equivalent.
To avoid using different symbols, and the possible confusion and
fragmentation that derives from it, all usages of Q_CLANG_QDOC are now
replaced by the equivalent usages of Q_QDOC.
Change-Id: I5810abb9ad1016a4c5bbea99acd03381b8514b3f
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
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>
[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>
QMetaType now implicitly knows how to convert any QFuture<T> to
QFuture<void> without needing to manually register a converter
function.
QtWebChannel will make use of this to transparently support QFuture<T>
return types.
[ChangeLog][QtCore][QMetaType] QMetaType now supports converting any
QFuture<T> to QFuture<void>.
Task-number: QTBUG-92903
Change-Id: Ied7e71be37c346cc3d2c274ffb0d91a6821ab4d4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
For generic interop with other parts of Qt, we need to be able to
extract the type-erased internal storage of QFuture<T>. In particular,
QtWebChannel needs this to transparently support QFuture<T> as a method
return type.
Task-number: QTBUG-92903
Change-Id: I763f054656b8810d58720262d364baf42c47eb37
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
The check is over-arching. is_move_constructible is sufficient;
we don't have to support "ridiculous" types that are copiable but
have deleted move operations (such types are fundamentally broken).
This is in line with the Move* (legacy) named requirements.
Change-Id: Idc7116b39013501b9be39628a4e7afd35fe15530
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
QFuture already has a constructor from QFuture<T> to QFuture<void>. It's
safe to remove this function, since it couldn't be ever used: it tries
to access QFuture's private member, which leads to compilation error. It
was never documented or tested.
Change-Id: Iaed9602e2737455d159012ea18ca241954e1f7df
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Do not include vector; we currently do not use std::vector, and the plan
is to use QList when that one supports move-only types.
Use QMutexLocker instead of std::mutex_locker, considering that the
former is already included with <QMutex>.
Use forward declarations where applicable.
Add header which were currently only indirectly included (to make
QtCreator's code model happy).
Change-Id: I37d5cd3982047a6d8a3132fd66571878298039b3
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
Added overloads of .then()/.onFailed()/.onCanceled() which take a
pointer of a context object, and invoke the continuations in the
object's thread.
Task-number: QTBUG-86794
Change-Id: I0f3cbb0500695673fc4087af5d4b96b416e3e1ce
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Use universal references instead of rvalue references for passing
callables in the implementations of QFuture's continuations.
Change-Id: I1288c78f78f84f30c6607e505e7f9807a9272071
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
(cherry picked from commit b002722dabef794da0e80010b115b2c6cd6dc6b8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
- Remove the casting operator of QFuture<T> to T. It calls
QFuture::result(), which may lead to undefined behavior if the user
has moved the results from QFuture via QFuture::takeResult() before
trying to do the conversion.
- Disable implicit conversion of QFuture<T> to QFuture<void>, by making
the constructor explicit. If the users really intend to do the
conversion, they should do it explicitly.
[ChangeLog][Source-Incompatible Changes][QFuture] Implicit conversions
of QFuture<T> to T and to QFuture<void> have been disabled. Use
QFuture::result() or QFuture::takeResult() where you need to convert
QFuture<T> to T. Use the explicit QFuture<void>(const QFuture<T> &)
constructor to convert QFuture<T> to QFuture<void>.
Change-Id: I153d4137d36365b1611ac934fb3ac2eb667fdd6c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
These operators don't do what the user might expect and may lead to
confusing results.
[ChangeLog][Source-Incompatible Changes][QFuture] The comparison
operators of QFuture have been removed. They were comparing the
underlying d-ptrs instead of comparing the results (as the users
might expect), which is not very helpful for the users point of view.
Change-Id: I80a887610eac38b60329128cca52cdb5fb515207
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
QFuture::takeResult() currently returns std::vector instead of QList,
because QList does not support move-only types. Disable this method
until QList is fixed to work with move-only types in Qt 6.1.
Also did minor doc-fixes.
Change-Id: I87feaf75d9433a3b540edd00039c3e21d6994985
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Deprecated the pause-related APIs of QFuture* classes and
added alternatives having "suspend" in the name instead.
With 2f15927f01ceef0aca490746302a5ea57ea9441c new
isSuspended()/suspended() APIs have been added to QFuture* classes for
checking if pause/suspension is still in progress or it already took
effect. To keep the naming more consistent, renamed:
- setPaused() -> setSuspended()
- pause() -> suspend()
- togglePaused() -> toggleSuspended()
- QFutureWatcher::paused() -> QFutureWatcher::suspending()
Note that QFuture*::isPaused() now corresponds to (isSuspending() ||
isSuspended()).
[ChangeLog][Deprecation Notice] Deprecated pause-related APIs of
QFuture and QFutureWatcher. Added alternatives having "suspend" in
the name instead.
Change-Id: Ibeb75017a118401d64d18b72fb95d78e28c4661c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Because setting QFutureInterface to paused state does not mean that
the computations that are already in progress will stop immediately,
it may be useful to get notified when pause actually takes effect.
Introduced the QFutureWatcher::suspended() signal, to be emitted when
there are no more computations in progress, and no more result ready
or progress reporting signals will be emitted, i.e. when pause took
effect. Added {QFuture, QFutureWatcher}::isSuspended() methods for
checking if pause took effect.
QtConcurrent will now to send QFutureCallOutEvent::Suspended event
when the state is paused and there are no more active threads.
[ChangeLog][QtCore][QFutureWatcher] Added a new QFutureWatcher::suspended()
signal, to be emitted when pause took effect, meaning that there are no
more computations in progress. Added {QFuture, QFutureWatcher}::isSuspended()
methods for checking if pause took effect.
Fixes: QTBUG-12152
Change-Id: I88f2ad24d800cd6293dec63977d45bd35f9a09f0
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Added QFuture::onCanceled() method, for attaching handlers to be called
when the QFuture gets canceled.
Change-Id: I1f01647d6173ba0c1db6641e14140108b33ac7c4
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Added QFuture::onFailed() method, which allows attaching handlers for
exceptions that may occur in QFuture continuation chains.
Task-number: QTBUG-81588
Change-Id: Iadeee99e3a7573207f6ca9f650ff9f7b6faa2cf7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QFuture's original design pre-dates C++11 and its
introduction of move semantics. QFuture is documented
as requiring copy-constructible classes and uses copy
operations for results (which in Qt's universe in general
is relatively cheap, due to the use of COW/data sharing).
QFuture::result(), QFuture::results(), QFuture::resultAt()
return copies. Now that the year is 2020, it makes some
sense to add support for move semantics and, in particular,
move-only types, like std::unique_ptr (that cannot be
obtained from QFuture using result etc.). Taking a result
or results from a QFuture renders it invalid. This patch
adds QFuture<T>::takeResults(), takeResult() and isValid().
'Taking' functions are 'enabled_if' for non-void types only
to improve the compiler's diagnostic (which would otherwise
spit some semi-articulate diagnostic).
As a bonus a bug was found in the pre-existing code (after
initially copy and pasted into the new function) - the one
where we incorrectly report ready results in (rather obscure)
filter mode.
Fixes: QTBUG-81941
Fixes: QTBUG-83182
Change-Id: I8ccdfc50aa310a3a79eef2cdc55f5ea210f889c3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QFuture<void> and QFutureWatcher<void> are specialized to not contain
any of result fetching methods, but otherwise they share almost the same
implementation with QFuture<T> and QFutureWatcher<T> respectively.
This change unifies their implementations to get rid of unnecessary code
duplication.
Change-Id: I9494ddc58c6db192c66edb988105927da6d61a3b
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Added QFuture::then() methods to allow chaining multiple asynchronous
computations.
Continuations can use the following execution policies:
* QtFuture::Launch::Sync - the continuation will be launched in the same
thread in which the parent has been executing.
* QtFuture::Launch::Async - the continuation will be launched in a new
thread.
* QtFuture::Launch::Inherit - the continuation will inherit the launch
policy of the parent, or its thread pool (if it was using a custom one).
* Additionally then() also accepts a custom QThreadPool* instance.
Note, that if the parent future gets canceled, its continuation(s) will
be also canceled.
If the parent throws an exception, it will be propagated to the
continuation's future, unless it is caught inside the continuation
(if it has a QFuture arg).
Some example usages:
QFuture<int> future = ...;
future.then([](int res1){ ... }).then([](int res2){ ... })...
QFuture<int> future = ...;
future.then([](QFuture<int> fut1){ /* do something with fut1 */ })...
In the examples above all continuations will run in the same thread as
future.
QFuture<int> future = ...;
future.then(QtFuture::Launch::Async, [](int res1){ ... })
.then([](int res2){ ... })..
In this example the continuations will run in a new thread (but on the
same one).
QThreadPool pool;
QFuture<int> future = ...;
future.then(&pool, [](int res1){ ... })
.then([](int res2){ ... })..
In this example the continuations will run in the given thread pool.
[ChangeLog][QtCore] Added support for attaching continuations to QFuture.
Task-number: QTBUG-81587
Change-Id: I5b2e176694f7ae8ce00404aca725e9a170818955
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Wait for the result at the target index if the future
is running and the iterator index is past the current
result count.
Determine if there is a result at the target index
after waitForResult() returns, and return -1/end if
not.
Also support decrementing the end iterator. In this
case wait for the future to finish in order to get
the final result count.
Task-number: QTBUG-59811
Change-Id: I8fcc711bab2e72c3c5196a55b794d25e18bb324d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
all of these iterator classes already have a member operator+, which allows iter+int.
This commits addes non-member operator+, which allows int+iter, and forwards to the member
QList and QArrayData iterators now satisfy RandomAccessIterator concept
Change-Id: I25c1dd8cea299e735d5a5e288dbe23dc1d7a1933
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... and make sure we can compile without it. In particular,
Qt Concurrent depends on QFuture, so we specify it as a condition,
and QtConcurrentException should not depend on future but on
concurrent.
Change-Id: I65b158021cecb19f227554cc8b5df7a139fbfe78
Reviewed-by: Martin Smith <martin.smith@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This update corrects several uses of #ifdef macros
that needed updating because qdoc now uses clang to
parse header files.
Change-Id: I285efa4629a1a5d5bcbfaf701eeafbd0e9f1e43e
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
This update corrects many qdoc warnings in the documentation
for the QFuture classes caused by incomplete \fn commands.
Template text and parameters was added.
Change-Id: I360c9db191230b19a9b174a43468d3de1eb24549
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
The compiler-generated ones are just fine.
This is BC because the class is not exported and
QFutureInterfaceBase (needlessly) contains virtual
functions (the dtor), so this class will never be
trivially copyable. It's also not movable, until I
figure out how to add move special member functions
to QFutureInterfaceBase.
Also made the QFutureInterface(State) constructor
explicit, because a State is not a faithful
representation of a QFutureInterface.
Change-Id: Ifa44f87b41c4ee3c5167c282512ec4860075671d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
The macro was made empty in ba3dc5f3b56d1fab6fe37fe7ae08096d7dc68bcb
and is no longer necessary or used.
Discussed-on: http://lists.qt-project.org/pipermail/development/2013-January/009284.html
Change-Id: Id2bb2e2cabde059305d4af5f12593344ba30f001
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
This class belongs to QThreadPool/QRunnable more than to QtConcurrent, so
move to QtCore, where QThreadPool awaits it.
Change-Id: Ibf20288a986593bf779453427c2dae8db1e1423a
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
