summaryrefslogtreecommitdiffstats
path: root/src/corelib/thread
Commit message (Collapse)AuthorAgeFilesLines
* Fix return type of _q_futex()Marc Mutz35 hours1-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | syscall(2) returns long, not int. Says Clang: qfutex_linux_p.h:48:18: error: implicit conversion loses integer precision: 'long' to 'int' [-Werror,-Wshorten-64-to-32] int result = syscall(__NR_futex, addr, op | FUTEX_PRIVATE_FLAG, val, val2, addr2, val3); ~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Don't truncate to int in _q_futex(), pass it as long into the few callers that care about the result. Amends the start of the public history, but not picking back all the way because the code moved around a lot. In 6.7 it found its current place. Pick-to: 6.8 6.7 Task-number: QTBUG-103528 Task-number: QTBUG-126219 Change-Id: I54ccaf5564bcaf38f05fab153b1b32379a66a178 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThread: mark is(Main|Current)Thread() noexceptMarc Mutz2 days3-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The rationale given for the addition of these functions was that they are a more efficient way to check these things in public API. If so, they shouldn't cause compilers to insert exception handling around their calls, so mark them noexcept. This is safe, as both conceptually and practically, these functions should not and cannot fail, so we'll never need to remove noexcept again. Found in API-Review. Amends 7a374c38d288435b3c0a76b82a1c2ca53ea9c003 and a3d50112e44bc42b310d9d3a8e6c7805ef31ef53. These two commits also lacked each the changelog entry, so adding them here: [ChangeLog][QtCore][QThread] Added isMainThread() static member function. [ChangeLog][QtCore][QThread] Added isCurrentThread() member function. Pick-to: 6.8 Change-Id: Iaf39ce2cc0abd45049bff60b24693e84bf76d9e0 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qfuturewatcher_p.h: fix missing qfuturewatcher.h includeMarc Mutz2 days1-1/+2
| | | | | | | | | | | | | | | | | | Extending headersclean_check to private headers has shown that Q_DECLARE_PUBLIC needs to know the Public class in-size, so a forward-declaration is not enough. Says Clang: qfuturewatcher_p.h:31:5: error: static_cast from 'QObject *' to 'QFutureWatcherBase *', which are not related by inheritance, is not allowed Q_DECLARE_PUBLIC(QFutureWatcherBase) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Amends the start of the public history. Pick-to: 6.8 6.7 6.5 6.2 5.15 Task-number: QTBUG-126219 Change-Id: I1e132aaa844f5c87d57446e8818280fd141d2b1e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Add -Wweak-vtables to headerscleanJesus Fernandez2024-05-191-0/+5
| | | | | | | | | | | | | | | | | | | This requires some fixes in several classes that are also included in this patch. The QTestEvent hierarchy is all-inline and changes layout depending on QT_GUI_LIB and QT_WIDGETS_LIB, so we can't just export it. Suppress the warning in that header for now. Created QTBUG-104486 to track a fix for the real issue. The QFutureInterface hierarchy is also all-inline, but templates, so doesn't trigger, except the <void> specialization. Created QTBUG-125115 to track a fix for the real issue. Done-with: Marc Mutz <marc.mutz@qt.io> Task-number: QTBUG-45582 Change-Id: I96b3e109aa989b70e0d4809b90bd53a369e50d55 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Don't rely on TLS to call QThread::finish on VxWMichał Łoś2024-05-171-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On VxWorks, its pthread implementation fails on call to `pthead_setspecific` which is made by first `QObject` constructor during `QThreadPrivate::finish()`. This causes call to `QThreadData::current`, since `QObject` doesn't have parent, and since the pthread is already removed, it tries to set `QThreadData` for current pthread key, which crashes. The aforementioned `QObject`'s instances are created in multiple places during `QThreadPrivate::finish` method, first one in during call to `qCDebug()`. The sequence currently leading to call to `QThreadData::current` starts with `qCDebug` call in `QThreadPrivate::finish`, which: - creates `QDebug` object, which - creates `Stream`, which - creates `QTextStream`, which - creates `QTextStreamPrivate`, which - creates `QDeviceClosedNotifier`, which - is a `QObject`, which - calls `QThreadData::current()` because its `parent` is nullptr. Even ignoring debug print, next line calls `QCoreApplication::sendPostedEvents` which calls `QThreadData::current` directly. Pick-to: 6.7 Task-number: QTBUG-115777 Change-Id: I4d405eebdff0c63c6cd66fba4eaa95c3818ceaea Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QtPrivate::ResultIteratorBase: use modernize comparisonsTatiana Borisova2024-05-142-10/+9
| | | | | | | | | | | | | Replace class operators operator==(), operator!=() of QtPrivate::ResultIteratorBase to friend method comparesEqual() and Q_DECLARE_EQUALITY_COMPARABLE macro. Use QT_CORE_REMOVED_SINCE and removed_api.cpp to get rid of current comparison methods and replace them with a friend. Task-number: QTBUG-120304 Change-Id: Ib9a50a400df86d1dc034d2a0cfee804109a2b93f Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QThreadPool: store the expiryTimeout in a std::chrono typeThiago Macieira2024-05-092-5/+4
| | | | | | | | | | For future-proofing. I'm not changing the front-end API because it's seldom used. Task-number: QTBUG-125107 Change-Id: Ic5b1273bb0204c31afd8fffd17ccf9ac42f57762 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* QThreadPool: add waitForDone() based on QDeadlineTimerThiago Macieira2024-05-093-16/+28
| | | | | | | | | | | | It was already being used internally this way, so all we needed was to provide the front-end API and inline the old API. [ChangeLog][QtCore][QThreadPool] Added an overload of waitForDone() based on QDeadlineTimer. Fixes: QTBUG-125107 Change-Id: Ic5b1273bb0204c31afd8fffd17ccf7c5bee07c35 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* QThreadPool: wrap the #include <functional> in QT_CORE_REMOVED_SINCEThiago Macieira2024-05-091-0/+2
| | | | | | | | | Might improve compilation time a little for people using this header. Amends 0e7e1c33965c43932e6c0228acc2f68259533482. Change-Id: Ic5b1273bb0204c31afd8fffd17cd558e4578c359 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* QFuture::const_iterator: use modernize comparisonsTatiana Borisova2024-05-082-6/+10
| | | | | | | | | | 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>
* QThread/Unix: make QThreadPrivate::finish() be called much laterThiago Macieira2024-05-071-7/+7
| | | | | | | | | | | | | | | | | | | | We need it to run after all the thread-local destructors have run, to ensure that some user code hasn't run after QThreadPrivate::finish() has finished. We achieve that by making it get called from a thread-local destructor itself, in the form of a qScopeGuard. This ought to have been done since C++11 thread_local with non-trivial destructors became available. However, it only started showing up after commit 4a93285b166ceceaea2e10c8fc6a254d2f7093b9 began using thread_local inside Qt itself. The visible symptom was that QThreadPrivate::finish() had already destroyed the thread's event dispatcher, but some user code ran later and expected it to still exist (or, worse, recreated it, via QEventLoop → QThreadData::ensureEventDispatcher). Fixes: QTBUG-117996 Pick-to: 6.7 Change-Id: I8f3ce163ccc5408cac39fffd178d682e5bfa6955 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QThread/Doc: update the docs on setStackSize()Thiago Macieira2024-05-071-4/+12
| | | | | | | | | | There's some confusion about minimum and maximum. Pick-to: 6.7 Fixes: QTBUG-109512 Change-Id: I262c3499666e4f4fbcfbfffd17cc1d592bc658b3 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> Reviewed-by: Philip Van Hoof <philip@codeminded.be>
* QtPrivate::Continuation: add missing Q_DISABLE_COPY(_MOVE)Marc Mutz2024-05-031-0/+1
| | | | | | | | | | | | This polymorphic class is not designed for copying or moving, so statically assert that it isn't moved or copied. Amends dfaca09e85a49d2983bb89893bfbe1ba4c19eab4. Pick-to: 6.7 Task-number: QTBUG-124909 Change-Id: I6a4fe460adf9bf903578601e500ccc697a3f7c96 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThread: relax memory semantics from seq_cst on interruptionRequestedThiago Macieira2024-05-022-4/+4
| | | | | | | | Amends a0faf9e23666d4aa26a93d6e9ebf420e71d5e6c2. Pick-to: 6.7 Change-Id: I262c3499666e4f4fbcfbfffd17cb1e141ad104d8 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* qfuture_impl.h: remove redundant declarationMarc Mutz2024-05-011-3/+0
| | | | | | | | | | | | | | | QtPrivate::watchContinuationImpl() is already declared in qfutureinterface.h, which qfuture_impl.h already includes. Fixes GCC -Wredundant-decls. Amends 59e21a536f7f81625216dc7a621e7be59919da33. Pick-to: 6.7 Task-number: QTBUG-115583 Change-Id: I9c77209d2d10492f4d81aacc1f1da3201b5d1810 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Arno Rehn <a.rehn@menlosystems.com>
* QThread: Use storeRelease when assigning the pointerJarek Kobus2024-04-291-1/+1
| | | | | | | Make it consistent with other assignments. Change-Id: If6aeb1007436e3b6a035494116786c2ab2f079ca Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThread: Reuse isMainThread()Jarek Kobus2024-04-293-6/+6
| | | | | | | Internally, reuse threadId and theMainThreadId. Change-Id: Iea6e7d8fcbcaf7e2f4dbf8ab33890d0f7954edc0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThread: Introduce static isMainThread() helperJarek Kobus2024-04-264-4/+28
| | | | | | | | | | | | Useful for QtCreator, as a replacement for Utils::isMainThread() inside threadutils.h, may serve for other projects, too. Introduce static QCoreApplicationPrivate::theMainThreadId atomic helper field holding the id of the main thread. Change-Id: Iccc0302f423f47b5ecad86c4cd3de4d1ee36155f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThread: Introduce isCurrentThreadFabian Kosmale2024-04-263-0/+38
| | | | | | | | | | This allows a more efficient way of checking whether a thread is the currently executing one (without using private API). Change-Id: I007edae6b258d7e42e901fa720d4f3cf9fe25a49 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io> Reviewed-by: David Faure <david.faure@kdab.com>
* QFutureInterface: remove comment that was never trueMårten Nordheim2024-03-151-2/+1
| | | | | | | | | Even in the original patch where the comment was added the callouts were made with the lock held. Change-Id: Id8d122010d2195d83ddd4fdaf638f7fc4ac8163d Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QFutureWatcher: Fix race for initial emission of resultReadyAt()Jarek Kobus2024-03-151-16/+10
| | | | | | | | | | | | | | | | | | | | | | When connecting a QFutureWatcher to the QFuture it will connect to the output interface, which will queue up events to notify about the current state. This happens in the thread of the QFutureWatcher. Since 07d6d31a4c0c17d8c897d783a9b0841df6834b02 unfortunately the sending of those events was done outside the lock, meaning the worker-thread could _also_ send events at the same time, leading to a race on which events would be sent first. To fix this we move the emission of the events back into the lock and because it is now inside the lock again anyway, we will revert back to posting the callout events immediately, so this patch also partially reverts 07d6d31a4c0c17d8c897d783a9b0841df6834b02 Fixes: QTBUG-119169 Pick-to: 6.7 6.6 Change-Id: If29ab6712a82e7948c0ea4866340b6fac5aba5ef Reviewed-by: Arno Rehn <a.rehn@menlosystems.com> Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
* QFutureInterface: fix build with GCC14/C++20: template-id not allowedThiago Macieira2024-03-141-1/+1
| | | | | | | | | | | When declaring a constructor, you must use the injected name, not a template. qfutureinterface.h:472:37: error: template-id not allowed for constructor in C++20 [-Werror=template-id-cdtor] Pick-to: 6.6 6.7 Change-Id: I6818d78a57394e37857bfffd17bbbf2313001cbf Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* QThread/Win: set the thread name on non-MSVC alsoGiuseppe D'Angelo2024-03-081-3/+11
| | | | | | | | | | SetThreadDescription is a Win32 API provided by Kernel32.dll, the only thing that MinGW is missing is the declaration of the function. We can provide it ourselves. Change-Id: Iad5fc6cb7b6eb190310f5888326b65f50ddbdca8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFutureInterface: Rename "interface" variables to "iface"Nodir Temirkhodjaev2024-03-051-13/+9
| | | | | | | | | | On Windows the "interface" is defined as "struct". Do not #undef it to fix a unity build. Task-number: QTBUG-122980 Pick-to: 6.7 Change-Id: I9379c996d8b67b16a8b825af0ff3469111533291 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Mention QChronoTimer in API docsAhmad Samir2024-03-031-1/+1
| | | | | Change-Id: Iaf9fb31994f1580b2051dbd0b1b8eef2a218aa39 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThread: set the thread name on Windows even in release builds of QtGiuseppe D'Angelo2024-02-291-1/+1
| | | | | | | | It's not really clear why this feature shouldn't work in release builds of Qt. This aligns the behavior with UNIX. Change-Id: I6a2f50640ab0b2e109e4c3ef7317954a3e8c79a2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThread: use SetThreadDescription on WindowsGiuseppe D'Angelo2024-02-291-36/+5
| | | | | | | | Starting with Windows 10 1607 there's a modern API to set a thread's name on Windows (replacing the RaiseException hack). Change-Id: I45b7abef7b082b9f239b2ac948bb79cce44cdb5e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix the instruction of RISC-V arch that yield CPUAlex Bu2024-02-281-3/+1
| | | | | | | | | | | | | | | Replace fence with pause in opcode form, as GCC doesn't support fence operand. Amends a7f227f56cfe562280e89d3c73040f7e8384129e. Remove the builtin pause checking, as in GCC13 this will always pass, while the opcode pause works regardless of the pause extension. Task-number: QTBUG-103014 Pick-to: 6.7 Change-Id: I26e3c3b9f7d234be24abe1570aaf4c8cb3a272b3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThread::currentThreadId: fix build on x32 (ILP32) ABIThiago Macieira2024-02-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | On this ABI, pointers are 32-bit, so Qt::HANDLE (void *) is a 32-bit variable and the "movq" instruction is inappropriate. There's a GCC extended inline assembler modifier for the instruction size suffix (%z0) but Clang seems not to understand it. Instead, I just removed the suffix: we can do that because this is a memory load instruction, which implies the destination is a general purpose register (also required by the "=r" constraint) and therefore the assembler can determine the size of the memory load from the name of the selected register. Note: I did not verify this compiles on x32 at all, much less that it loads the right thing from memory. Fixes: QTBUG-122674 Pick-to: 6.5 6.6 6.7 Change-Id: I01ec3c774d9943adb903fffd17b6513d146e89ce Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Change license of .qdoc filesLucie Gérard2024-02-021-1/+1
| | | | | | | | | | | | According to QUIP-18 [1], all .qdoc files should be LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I7c4d8a1957db6f6d7ad18cbc1928499724e9305f Reviewed-by: Kai Köhne <kai.koehne@qt.io>
* QSemaphore::release: Revert "Optimize cond var notification"Thiago Macieira2024-01-121-4/+4
| | | | | | | | | | | | | | | This reverts commit 60113056bc4c328f62808d1c0fa2a1abec481f78. Calling d->cond.notify_all(); without the mutex means that another thread could acquire the semaphore (acquire the mutex, subtract from d->avail, return to caller) and destroy it. That would mean this thread is now effectively dereferencing a dangling d pointer. Fixes: QTBUG-120762 Pick-to: 6.5 6.6 6.7 Change-Id: I196523f9addf41c2bf1ffffd17a96317f88b43dd Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
* [docs] Remove references to C++11 feature availabilityMarc Mutz2024-01-091-2/+2
| | | | | | | | | | | | | QVersionNumber, e.g., was added for Qt 5.6, the last Qt version that didn't require C++11. So it made sense that the original documentation stated that certain functions were only available in C++11 mode. But already Qt 5.7 required C++11, so these historical anecdotes are no longer pertient to today's Qt users, so remove them from the docs. Pick-to: 6.7 6.6 6.5 6.2 5.15 Change-Id: I5c732d3b9b33e1fb6947eff4fac546476c8379f2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFuture: immediately delete watcher after the context is destroyedIvan Solovev2024-01-091-1/+1
| | | | | | | | | | | | | | | | | | We used deleteLater(), which was triggering ASAN use-after-free error. Apparently, what could happen is that after the context was destroyed, we called deleteLater(), but if at this point the previous future got finished, we still tried to emit watcher->run() to execute the continuation. And then the watcher got deleted. This patch replaces deleteLater() with a plain delete call. This looks safe, because the watcher is only accessed while holding the lock. Amends 59e21a536f7f81625216dc7a621e7be59919da33. Fixes: QTBUG-120302 Pick-to: 6.7 6.6 Change-Id: Ia32f20bfe8daea2e2346f3d446c978ae305d2f68 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* wasm: fix single thread apps build QScopedScopeLevelCounterLorn Potter2023-12-281-0/+2
| | | | | | | | | QScopedScopeLevelCounter was added and it doesn't really need threads to function, but apps fail to link without it. Change-Id: I7b355369079bc11b8b8b45b3ee1bf5ba81cd1953 Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* wasm: fix single thread buildLorn Potter2023-12-221-0/+4
| | | | | | | | Fixes linking of apps Pick-to: 6.6 6.7 Change-Id: I9bbec9b63af8ae2801643fe124aeda8b25abeca5 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Add categorized logging of delete later machineryTor Arne Vestbø2023-12-214-5/+19
| | | | | | | | | A QT_MESSAGE_PATTERN including %{backtrace depth=4} should give the call site of the QScopedScopeLevelCounter. Task-number: QTBUG-120124 Change-Id: Ie477994882bde9168c931479102017ad5fde426a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Remove references to Qt 4 in Qt 5.0 in Qt Core documentationKai Köhne2023-12-181-5/+4
| | | | | | | Pick-to: 6.6 6.7 Change-Id: Ide0c1ed441c923753f1e81141460719161662c15 Reviewed-by: Jaishree Vyas <jaishree.vyas@qt.io> Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
* QFuture: Don't use QFutureCallOutInterface for continuationsArno Rehn2023-12-132-71/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces the QBasicFutureWatcher that was used for continuations with context objects with a smaller QObject-based wrapper that works directly from the actual continuation. The idea stays the same: In order to run continuations in the thread of a context object, we offload the continuation invocation to the signal-slot mechanism. Previously, we've hooked into QFuture with QFutureCallOutInterface to emit a signal and trigger continuation invocation. However, it is much easier and robust to emit that signal from the continuation itself. This sidesteps the locking issues that QFutureCallOutInterface handling presents. QFutureCallOutInterface basically requires any consumer to only access the QFuture after all events have been posted and the internal mutex unlocked, i.e. on the next cycle of the event loop. Continuations do not impose this restriction; runContinuation() explicitly unlocks the internal mutex before calling the continuation. This fixes a deadlock when using QFuture::then(context, ...) where the paren future is resolved from the same thread that the context object lives in. Fixes: QTBUG-119406 Fixes: QTBUG-119103 Fixes: QTBUG-117918 Fixes: QTBUG-119579 Fixes: QTBUG-119810 Pick-to: 6.7 6.6 Change-Id: I112b16024cde6b6ee0e4d8127392864b813df5bc Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* qYieldCpu: ensure we don't use asm statement with MSVC on ARMThiago Macieira2023-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Amends a7f227f56cfe562280e89d3c73040f7e8384129e. It doesn't support that anywhere except i386, and even there it has a different syntax than what we're using here. This code assumed ARM was only ued with GCC-like compilers. qglobal.c.obj : error LNK2019: unresolved external symbol asm referenced in function tst_qYieldCpu tests\auto\corelib\global\qglobal\tst_qglobal.exe : fatal error LNK1120: 1 unresolved externals Note: if we're getting here, it means the _YIELD_PROCESSOR() generic macro was not used, which means there is no ARM YIELD being emitted for MSVC on ARM for C code (for C++, the macro appears to be working). This is likely to be a performance issue, which will need to be fixed by someone who has an interest in improving performance on those conditions. Fixes: QTBUG-119881 Pick-to: 6.7 Change-Id: Ica7a43f6147b49c187ccfffd179f04e1ab643302 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Doc: Change deprecation of QFuture::makeReadyFuture to 6.6Kai Köhne2023-12-043-21/+18
| | | | | | | | | | | | | | | | | 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>
* Rename EINTR_LOOP -> QT_EINTR_LOOPMarc Mutz2023-11-301-1/+1
| | | | | | | | | | | | | | | This non-namespaced macro was defined in a header, and while that header is private, we shouldn't define non-namespaced macros in our headers. The macro also clashed with one of the same name defined in forkfd.c, which broke unity-builds including the forkfd_qt.cpp TU. This rename fixes that, too, so we can now remove forkfd_qt.cpp from NO_UNITY_BUILD_SOURCES. Pick-to: 6.6 6.5 Change-Id: Ic4bb4e4d7a632ca87905e48913db788a7c202314 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Doc: Fix \fn template arguments for Qt CoreLuca Di Sera2023-11-301-1/+1
| | | | | | | | | Upcoming changes to QDoc require accurate definition for template arguments in \fn commands. Task-number: QTBUG-118080 Change-Id: I64d50919bc6ffab61ef5ead553d1da99d63a9f21 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Doc: Fix template information for QFutureWatcher membersLuca Di Sera2023-11-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc parses a project, it parses the source code to extract the user-provided documentation and perform sanity checkings based on the code itself on it. When QDoc parses an "\fn" command as part of this process, it tries to understand, based on its intermediate representation built on the information extracted from the code-base, which "documentable element" the "\fn" refers to. When QDoc performs this "matching" process, it takes into consideration only a certain amount of information. For example, no checking is performed over the template declaration of a callable. Due to some upcoming documentation, where two callables are indistinguishable to the current process, as they differ only in their template declaration, QDoc will start to take into consideration the template declaration of a callable when matching. This implies that an "\fn" command should now provide information parity, with regards to template declaration for callables, with the code-base so that QDoc can perform the match correctly. The documentation for some of the members of `QFutureWatcher` is not in sync with the intended target template declaration. Hence, add the missing information to the relevant "\fn" commands. Task-number: QTBUG-118080 Change-Id: I33932d0ef693f6e045ecf4414d05dadfb66d3d09 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Doc: Fix template information for QFuture membersLuca Di Sera2023-11-181-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc parses a project, it parses the source code to extract the user-provided documentation and perform sanity checkings based on the code itself on it. When QDoc parses an "\fn" command as part of this process, it tries to understand, based on its intermediate representation built on the information extracted from the code-base, which "documentable element" the "\fn" refers to. When QDoc performs this "matching" process, it takes into consideration only a certain amount of information. For example, no checking is performed over the template declaration of a callable. Due to some upcoming documentation, where two callables are indistinguishable to the current process, as they differ only in their template declaration, QDoc will start to take into consideration the template declaration of a callable when matching. This implies that an "\fn" command should now provide information parity, with regards to template declaration for callables, with the code-base so that QDoc can perform the match correctly. The documentation for some of the members of `QFuture` is not in sync with the intended target template declaration. Hence, add the missing information to the relevant "\fn" commands. Task-number: QTBUG-118080 Change-Id: I142124e02c9264c8c1b82bb8130162ee89c0f3a5 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Revert "QAtomic: remove the copy ctor and assignment operator"Volker Hilsheimer2023-10-253-7/+58
| | | | | | | | | | | This reverts commit 6a93ec2435b8a453d43956fef6afa5f091d70ffc. Reason for revert: Breaks qtdeclarative build, submodules need to be clean before we deprecate or remove APIs. Change-Id: Id0726b9bfad6072065b380b44b6ff6dffda79e45 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* QAtomic: remove the copy ctor and assignment operatorGiuseppe D'Angelo2023-10-253-58/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These special member functions have no purpose. We never *documented* their semantics. Any code using them is unconditionally wrong (which semantics was it assuming?), so we can accept the SIC (type A). If a user needs such a copy, they would have to reason on the intended semantics (relaxed? acquire/release?) and be explicit in their code. Especially for assignment, they would need understand the consequences of the memory ordering that apply on _each_ atomic object involved and not on the assignment operation as a whole (there are no such semantics). Testing this change on qtbase has already found bugs. From a purely technical point of view: we don't guarantee lock-free atomics nor we require them from the underlying platform. An atomic is therefore allowed to be implemented as a mutex protecting a value, and mutexes are not copiable. std::atomic follows the exactly same pattern (not copiable nor copy-assignable) for exactly the same reasons, and Qt atomics are implemented on top of std:: ones. [ChangeLog][QtCore] The copy constructor and assignment operators of Qt atomic classes (QAtomicInteger, QAtomicPointer) have been removed. Their usage in user code should be considered a programming error, as no memory ordering semantics were ever documented for these operations (and therefore relying on any specific semantic would be relying on undocumented, unportable behavior). This matches the API of the std::atomic class in C++. Note that you can still use explicit load/store operations to transfer a value across two Qt atomic objects, and therefore use the memory ordering specified for the load/store operations. Change-Id: Iab653bad761afb8b3e3b6a967ece7b28713aa944 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThread/Unix: don't hardcode OSes for PThread cancellation supportThiago Macieira2023-10-171-2/+2
| | | | | | | | | Instead, check the macro that we're about to use. This is also done in qprocess_unix.cpp Pick-to: 6.5 6.6 Change-Id: I8f3ce163ccc5408cac39fffd178d657b7594d07a Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Include what you need: <QPointer>Marc Mutz2023-10-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | All these TUs relied on transitive includes of qpointer.h, maybe to a large extent via qevent.h, though, given that qevent.h is more or less the only public QtBase header that includes qpointer.h, something else seems to be at play here. Said qevent.h actually needs QPointer in-name-only, so a forward declaration would suffice. Prepare for qevent.h dropping the include. The algorithm I used was: If the TU mentions 'passiveGrabbers', the name of the QEvent function that returns QPointers, and the TU doesn't have qpointer.h included explicitly, include it. That may produce False Positives, but better safe than sorry. Otherwise, in src/, add an include to all source and header files which mention QPointer. Exception: if foo.h of a foo.cpp already includes it, don't include again. Task-number: QTBUG-117670 Change-Id: I3321cccdb41ce0ba6d8a709cea92427aba398254 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Add missing return type to QPromise::emplaceResult/emplaceResultAtLuca Di Sera2023-10-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc reads an `\fn` command it saves it to a file to parse it with Clang, with the objective of using the produced AST to perform certain sanity checks on the documented element. Generally, `\fn` commands that do not represent correct C++ code are accepted as long as Clang is still able to build an AST Node that QDoc can work with, not resulting in any issue in the output documentation. For example, an `\fn` that doesn't state a return type might be able to be parsed correctly enough by Clang to produce a sensible Node for the function that QDoc is interested into. The documentation for `QPromise::emplaceResult/emplaceResultAt` make use of this possibility by not stating a return type. Up to Clang 15 this was not an issue, and a correct-enough AST was produced when the `\fn` commands for those methods were parsed. On Clang 16, Clang chokes on the missing return type, being unable to recognize the function definition and produce an AST that QDoc can work with. This has the effect of losing those documented element in the output documentation. To avoid the issue, a return type is now added to the relevant `\fn` commands. Task-number: QTBUG-111580 Change-Id: I7d41fc52720ff8762bf2cce229969b7250e44754 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* qfuture_impl.h: remove unused qpointer.h includeMarc Mutz2023-10-051-1/+0
| | | | | | | | The last QPointer user was removed in commit 07d6d31a4c0c17d8c897d783a9b0841df6834b02. Prune the include. Change-Id: Id48ffd2f8f5c1790bbdc54d66ac0c404b0af9cd2 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-14 07:12:24 +0000