summaryrefslogtreecommitdiffstats
path: root/src/corelib/kernel/qobject.cpp
Commit message (Collapse)AuthorAgeFilesLines
* QObjectPrivate: fix data race on ConnectionData contentsDavid Faure2024-03-191-16/+24
| | | | | | | | | | | | | The atomic pointer "connections" is always populated under mutex in QObjectPrivate::ensureConnectionData() but isn't necessarily read under mutex protection (e.g. in maybeSignalConnected()). This caused a data race, fixed by using storeRelease and loadAcquired. Task-number: QTBUG-100336 Pick-to: 6.7 6.6 6.5 Change-Id: Ifd605e65122248eb08f49e036fdda6e6564226bc Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove QObjectPrivate::isSender/senderList, no longer usedDavid Faure2024-03-141-34/+0
| | | | | | | | | Only QAccessibleWidget was using them, and this was changed some time ago. No point in keeping dead code. Change-Id: I14bc40e6d87df234987e82385ce13433c2b82744 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QAbstractEventDispatcher: port timer uses to the V2 APIThiago Macieira2024-03-131-6/+5
| | | | | | Change-Id: I83dda2d36c904517b3c0fffd17b52b71739928dc Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* QObject: fix a documentation note in the destructorGiuseppe D'Angelo2024-03-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | The docs for ~QObject say: > any pending posted events for the object are removed from the event > queue but then they also say: > Deleting a QObject while pending events are waiting to be delivered > can cause a crash These two contradict each other. In fact, the first one is correct, the second one is factually incorrect. Amend it to what I believe it's the intended meaning: do not destroy a QObject which is _handling_ an event (i.e. we're into QObject::event() or an override). Change-Id: Id1d564f296e17a764e0f49ebfedf6e292085c221 Pick-to: 6.7 6.6 6.5 6.2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Shantanu Tushar <shantanu.tushar@kdab.com> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Mention QChronoTimer in API docsAhmad Samir2024-03-031-12/+14
| | | | | Change-Id: Iaf9fb31994f1580b2051dbd0b1b8eef2a218aa39 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Timers: add Qt::TimerId enum classAhmad Samir2024-03-031-7/+22
| | | | | | | | | | | | | | | | | | | | | | | | Which will be used to represent timer IDs. Thanks to Marc for the idea to use "a strongly typed int". QTimer got a new id() method that returns Qt::TimerId (can't overload timerId()). Various classes in qtbase have a member named timerId(), but a new method is needed anyway in QTimer so id() it is (this is the reason QChronoTimer only has id() and no timerId()). Besides timer.timerId() has an extra "timer". This commit fixes the inconsistency between QObject using `0` timer id to indicate "failed to start", while QTimer::timerId() returned `-1` to indicate "timer is inactive". QTimer::id(), being a new method and all, now returns Qt::TimerId::Invalid, which has value `0`, so that the values match between the two classes. Extend the unittests to ensure QTimer::timerId()'s behavior is preserved. [ChangeLog][Core][QObject] Added Qt::TimerId enum class, that is used to represent timer IDs. Change-Id: I0e8564c1461884106d8a797cc980a669035d480a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Doc: Further replace 'Qt Designer' with 'Qt Widgets Designer'Kai Köhne2024-02-291-2/+2
| | | | | | | | | | Use \QD macro wherever possible. Amends 8aceccc7eb075 Task-number: QTBUG-122253 Change-Id: I276dabd40fb81486f6380fd90cf9968990932a24 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* QSingleShotTimer: use nanoseconds precisionAhmad Samir2024-02-231-4/+9
| | | | | | | | | | | | | | This is a step towards making QChronoTimer have nanoseconds precision. Not changing QTimer::singleShot() methods to take nanoseconds; QTimer uses milliseconds for the most part, having the static singleShot() methods take nanoseconds would be a bit surprising? [ChangeLog][Core][QObject] Added startTimer() nanoseconds overload and removed the milliseconds overload. This change is backwards compatible. Change-Id: I69e79c8feb6354846c6d3be57dc529af7abd1313 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Documentation: Rename 'Qt Designer' to 'Qt Widgets Designer'Friedemann Kleint2024-02-191-1/+1
| | | | | | Task-number: QTBUG-122253 Change-Id: I04ab521decaf908b1c1491987f6de1e816a42a33 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
* Add virtual QObjectPrivate::writeToDebugStreamVolker Hilsheimer2024-02-101-4/+12
| | | | | | | | | | | | | QObject by default writes class- and objectName to the debug stream, but QObject subclasses might want to write different, or additional information. Providing class-specific debug stream operators is not a good solution for this, as it doesn't respect runtime polymorphism. With a virtual helper in QObjectPrivate, class authors can add an override. Change-Id: I382126ae5a56391d0c7e5ccb58fbbafa6aab5c77 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QObject: Let moveToThread return succcess stateChristian Ehrlicher2024-01-241-9/+10
| | | | | | | | | | | | | | | Add bool QObjectPrivate::moveToThread() which returns the success state of the attempt to move the object to the new thread. For Qt7 the public signature of QObject::moveToThread() should be changed to directly return this value. [ChangeLog][QtCore][QObject] QObject::moveToThread() now returns a boolean success state. Pick-to: 6.7 Change-Id: I8441c8155a76b804b473ab9c45c2be6840ef1677 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QObject: de-pessimize installEventFilter()Marc Mutz2024-01-151-3/+3
| | | | | | | | | | | | | | | | | Don't loop over the list of event filters twice, do it once with a combined predicate. This code is still has a big impedance mismatch: the removeIf() will always leave empty space at the back while prepend() needs it at the front. We should fix this by reversing the meaning of the order of event filters to mean back()-is-applied-first, so new filters can be append()ed, but that is for another patch. Done-with: Jarek Kobus <jaroslaw.kobus@qt.io> Pick-to: 6.7 Change-Id: I08324697229a54c8f66c6c320cf7232d707a08f1 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
* QObject: Optimize removeEventFilterJarek Kobus2024-01-151-3/+5
| | | | | | | | | | We can't have duplicated filters installed, so break the loop when removing event filter after we have found the matching one. Pick-to: 6.7 Change-Id: Idda87f3090954e020b27bf3fab62677128607f03 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QObject: clarify docs wrt. member access following Q_OBJECT and coAhmad Samir2024-01-141-0/+11
| | | | | | | | | | | | The macros expand to declarations that end in a private: section, which means everything following them is private. As Fabian said in the bug report, this is obvious when Q_OBJECT/GADGET ...etc are used in a class, but might be a bit surprising when used in a `struct`. Fixes: QTBUG-120297 Pick-to: 6.7 6.6 6.5 6.2 5.15 Change-Id: Iacdfc4eb3bab3554cc1142f682b11b32c3868b8f Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QObject: Make it clear we don't install duplicated event filtersJarek Kobus2024-01-111-0/+3
| | | | | | | Pick-to: 6.7 6.6 6.5 6.2 5.15 Change-Id: I3048b50700880dd2445a5a65823fef02b196ce7d Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Add categorized logging of delete later machineryTor Arne Vestbø2023-12-211-2/+11
| | | | | | | | | 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: Use Qml DefaultProperty as example for Q_CLASSINFOKai Köhne2023-12-201-6/+9
| | | | | | | | | | | Setting a DefaultProperty is arguably something more useful to people than the 'made up' version example. Also add more links to the relevant QML pages. Pick-to: 6.6 6.7 Change-Id: Id967df7ddf81511299f95b9fd24f56af671fb855 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Fix documentation issues for Qt CoreTopi Reinio2023-12-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Fix template arguments in \fn signatures for Qt::compareThreeWay() functions. * Fix template arguments in \fn signatures for QDebug::operator<<() functions. * Fix \sa links to specific overloads of QSpan functions. * Fix \sa links to specific overloads of QFileInfo::fileTime(). * Remove references to 'Custom Type Example' (example has been removed). * Fix linking to 'JSON Save Game' example. * Fix references to 'Queued Custom Type' example. * Fix linking to QCryptographicHash::Algorithm. * Fix linking to Qt Qml module. * Fix undocumented parameters in qHypot(). Pick-to: 6.7 Change-Id: If9eb9978a14e147f003672a682972b319454c311 Reviewed-by: Luca Di Sera <luca.disera@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Move QDeferredDeleteEvent loop level/scope handling into deleteLater()Tor Arne Vestbø2023-12-191-13/+42
| | | | | | | | | | | | | | | | | | | We have all the information we need when deleteLater() is called, so there's no point in deferring it until the event is posted, which requires friended access into the QDeferredDeleteEvent's members. Moving the code focuses QCoreApplication::postEvent() on its primary task, posting of the event (adding to the event list, waking up the event dispatcher). It's also easier to reason about how the action of deleteLater on an object relates to the event loop and scope level when the information is resolved up front. Task-number: QTBUG-120124 Change-Id: If38f601ff653111763004b98915b01ffe8ddc837 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Tweak QObject::deleteLater() documentation a bitTor Arne Vestbø2023-12-191-4/+0
| | | | | | | | | | The Qt 4.8 reference is not relevant. And mentioning that calling the function more than once is safe, or why that is, is strange, as users should still treat the object as something that will go away soon. Pick-to: 6.7 Change-Id: Icf24aa8ffe079e35351006dd77063df48a596fab Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Document how to process deferred deletes in a plugin-scenarioTor Arne Vestbø2023-12-191-0/+15
| | | | | | | | | | | | | | | | | | | | | When Qt is not driving the event dispatching, the event loop level of the thread will stay 0. As a result, we will not automatically bump the deferred delete event's scope level to 1 when the deferred delete happens from a code path that doesn't raise the scope level via QScopedScopeLevelCounter, leaving the event with loop and scope level 0. As we only process these 0+0 deferred delete events automatically from QCoreApplicationPrivate::execCleanup(), which is not going to be called when the app doesn't call QCoreAppliction::exec(), we were failing to process the deferred deletes both during the application's runtime, as well as on shutdown. Task-number: QTBUG-120124 Fixes: QTBUG-117975 Pick-to: 6.7 6.6 6.5 Change-Id: I2b8accb432517a48370923ee2d760f8e2e4a8055 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>
* Debounce QDeferredDeleteEvents in QObject::deleteLater()Tor Arne Vestbø2023-12-151-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to look through the event queue in QCoreApplication::postEvent, and if we found an existing DeferredDelete event for the receiver we would compress the two events into one. This was changed in 99b89d30fa5484c5d1f3cbda828648c28af4fb7d, as the logic was causing O(n^2) for deleteLater, by using one of the bits in QObjectData to track whether the object had already been deleted. But it kept the logic for tracking this in QCoreApplication::postEvent, and QCoreApplication::compressEvent would still do the work of deleting the additional QDeferredDeleteEvents. To avoid the unnecessary heap allocation of the QDeferredDeleteEvents we can move the debouncing/compression to QObject::deleteLater(). We use the same mutex as in QCoreApplication::postEvent to guard concurrent access to deleteLaterCalled. A note has been added about the (preexisting) issue that the mutex is not sufficient to prevent data races, as the deleteLaterCalled flag is part of a bit-field, and we're not guarding any of our other accesses to other bits. As QDeferredDeleteEvents is private API, we can rely on no-one else posting it than QObject::deleteLater(), which should be the case now that tst_QApplication::sendPostedEvents() was fixed. The documentation has been clarified as well. It's safe to call deleteLater() more than once, but that's not _because_ other pending events for the object are cleared. The latter behavior is normal ~QObject() behavior. The documentation was probably written at a point we didn't do any event compression at all for QDeferredDeleteEvents. Task-number: QTBUG-120124 Task-number: QTBUG-119918 Change-Id: I2a733095b7cb066ba494b1335aa40200c749cb0c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove qDeleteInEventHandlerTor Arne Vestbø2023-12-141-6/+1
| | | | | | | | | | It's equivalent to delete these days, and has been for a long time, since 2011 in fact, when the last remnants of QT_JAMBI_BUILD were removed. Change-Id: I7703e41c04204844da4ee75fa251b361e0db4ead Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QObject: allow calling findChild() without a nameRym Bouabid2023-11-221-0/+18
| | | | | | | | | | | Add an overload of findChild() without a name argument to be able to call the function with options value only. [ChangeLog][QtCore][QObject] Added findChild() overload taking no name. Task-number: QTBUG-103986 Change-Id: Id06b6041408fcf4cc1eeba975afce03f3a28f858 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QObject: port findChild/ren() to QAnyStringViewRym Bouabid2023-11-221-33/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | Change the object's name type in QObject::findChild/ren() to QAnyStringView, because they are only used for comparison against objectName property. qt_qFindChild{,ren}_helper() functions taking an objectname as QString have to stay in the ABI as they were exported in inline methods before Qt 6.7. Unlike QString, constructing a null QAnyStringView doesn't involve any code-size overhead. So, get rid of the split in qt_qFindChildren_helper that was introduced for QString. Remove unneeded qt_qFindChildren_with_name helper function and qt_qFindChildren_helper overload without a name. findChildren(options) method used to call qt_qFindChildren_helper overload. Instead, call findChildren overload with name argument and pass QAnyStringView{} as the object name. [ChangeLog][QtCore][QObject] Ported QObject::findChild/ren() and their helper functions to QAnyStringView. Task-number: QTBUG-103986 Change-Id: I68bda0e581f984ae48b7581ad86cc1b95008c1b0 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Doc: Fix template information for QObject::findChildrenLuca Di Sera2023-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 `QObject::findChildren` 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: I325008c22e82c002afe8cbeaa847af7a28277a0b Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Doc: Improve documentation for QObject::findChildRym Bouabid2023-11-171-5/+6
| | | | | | | | | | | | | There is a difference between findChild() and findChild("") that was not explained in the documentation. So, add a sentence to clarify it. The object's search when there are several direct ancestors was documented as "undefined". Change it to "first child in children()". Task-number: QTBUG-103986 Pick-to: 6.6 6.5 Change-Id: I25cb01b87d3b24af498ad494b3f353840ee78807 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QObject: do not copy a ConnectionList objectGiuseppe D'Angelo2023-09-141-1/+1
| | | | | | | | | The semantics of copying a ConnectionList are not defined; the type is copiable by accident. Use a reference to the list instead (like done in other places in the code). Change-Id: Ifbc5d3baca992f3eb13e3781378e79ed1feb4e1c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove redundant QPair includesAhmad Samir2023-09-061-1/+0
| | | | | | | | Nothing in those files uses QPair; and a local build finished fine without them. Task-number: QTBUG-115841 Change-Id: I669cfecaa9129bce6b31e464826287f138b159db Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Implement QSignalBlocker::dismiss()Axel Spoerl2023-08-311-0/+8
| | | | | | | | | ...to set m_o to nullptr and prevent an existing QSignalBlocker from touching the QObject, which it was created for. Add documentation and implement an autotest. Change-Id: Ic18e80af5a57df1928f9d36aa0ab7ad79b6525fd Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Allow QObjects to opt in to receiving ParentAboutToChange/ParentChangeTor Arne Vestbø2023-08-301-0/+15
| | | | | | | | | | | | | | | | | | | QWidget already handles this, but it might be useful for non-Widget object hierarchies as well, such as in Qt Quick. The flag is opt in, and as QWidget already handles these events by itself (without checking any flags), we assert that we don't end up in this code path, instead of enabling it for QWidget. The latter would mean refactoring the QWidget code, with possible regressions. Docs and header comments have been updated to reflect that this event is not widget specific. (This is an issue with other events as well, that are documented to say "widget", since they came from a time when there was only QWidget, but nowadays apply to e.g. QWindow as well. That's something for another fix though). Change-Id: Ib71962131d6011c17dcce8c01bd8adcdaa58d798 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* QObject: Do not register an observer when writing objectName propertyUlf Hermann2023-08-211-2/+2
| | | | | | | | | Observers should only be registered when _reading_ the property. Otherwise we get binding loops. Pick-to: 6.6 6.5 Change-Id: I974f6ea444fa7a5d333ed79eea6f34e3d757d169 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QObject: replace _q_reregisterTimers with a lambdaAhmad Samir2023-07-311-15/+7
| | | | | | | | | | | | | | | - Pass the QList by value, no heap allocation and no plain new/delete - A lambda means that there isn't runtime string-based lookup to find the member method in QObjectPrivate The code is only a couple of lines and used in a single place, so might as well move the code from _q_reregisterTimers to the local lambda. Modify tst_moc to account for the numer of methods in QObjectPrivate changing. The test had hardcoded numbers. Change-Id: I07906fc7138b8e601e4695f8d2de1b5fdd88449c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Port QObjectPrivate::connect() to SlotObjUniquePtr internallyMarc Mutz2023-07-211-5/+4
| | | | | | | | | | | | | This is for consistency with QObject::connectImpl() and QObjectPrivate::connectImpl(), if nothing else. See the commit message of the QObject::connectImpl() porting patch for why we leave the function signature unchanged (key-word: tail-callability). Pick-to: 6.6 6.5 Change-Id: I515d3be4a5126f9f4738dd7bde5174377faf2343 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Port QObjectPrivate::connectImpl() to SlotObjUniquePtr internallyMarc Mutz2023-07-211-12/+4
| | | | | | | | | | | | | | | | | ... removing the custom scope-guard which was .dismiss()ed too early (the allocation of 'c' could theoretically fail, and the old code would leak the slot object in that case; nothing we're generally guarding against in Qt, but it's a nice drive-by gain, probably shuts up static checkers, and makes readers wonder less about the lifetime of the slot object). As mentioned in the patch porting QObject::connectImpl(), leave the unique_ptr out of the function's signature, see there for rationale (key-word: tail-callability). Pick-to: 6.6 6.5 Change-Id: Ib90371b9768a72fd62d080b71eef2c82f851db81 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Port QObject::connectImpl() to SlotObjUniquePtr internallyMarc Mutz2023-07-211-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This gets rid of the smell that one destroyIfLastRef() call guarded against nullptr while the other one did not. Don't change the function signatures, as passing by unique_ptr, while making the transfer of ownership clear, makes it impossible to call the function as a tail-call: Non-trivially-copyable arguments live in the caller's stack frame and the caller has no idea whether the object was moved from in the callee or not, so it needs to run the dtor, which prevents this from being tail-callable. Passing .release(), OTOH, makes it obvious that the unique_ptr is nullptr afterwards, so leaves the door open for tail-calling. However, the QObjectPrivate::connectImpl() wasn't, and continues to not be, a tail-call. Investigating why, while intriguing, is for another patch (and much more important for the template wrappers of these functions than then one out-of-line function we're dealing with here). Pick-to: 6.6 6.5 Change-Id: Ib951ed2a2b622d70cb12ddbf01c83ec56b1ce70d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMetaCallEvent: add ctors and create() overloads taking SlotObjUniquePtrMarc Mutz2023-07-211-2/+33
| | | | | | | | | This makes it clear who is responsible for obtaining additional strong reference to the slot objects, because these functions no longer do. Pick-to: 6.6 6.5 Change-Id: I39187e3c441d8f82d50d907731f1cbdfb2a95b9d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QTimerInfoList: refactor unregisterTimers()Ahmad Samir2023-07-191-1/+4
| | | | | | | | | | | | - Use removeIf(), easier to reason about than removing from the list during iteration - Return true only if any timers were actually unregistered - Assert in QObject::event() that if the list returned by eventDispatcher->registeredTimers() isn't empty, then eventDispatcher->unregisteredTimers() returns true Change-Id: I739a3865b7524a7aab3ff0227e6a060ed98d6191 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMetaCallEvent::create: extract template-argument-independent codeMarc Mutz2023-07-191-0/+19
| | | | | | | | | | Extract Method create_impl() with all the stuff that doesn't depend on create()'s template arguments, which will reduce compile time and amount of generated code. Pick-to: 6.6 Change-Id: I9d8f59c168873ac3527b570ef6142079824061cf Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Port SlotObjectGuard to SlotObjUniquePtrMarc Mutz2023-07-191-7/+4
| | | | | | | Pick-to: 6.6 6.5 Change-Id: I81e64db7e1be9076494bee15bbca372ebffeb3e0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QSlotObjectBase: add Deleter and typedef for a unique_ptr using itMarc Mutz2023-07-191-4/+2
| | | | | | | | | | Use it in QMetaCallEvent, to have some automatic test coverage. Other code that might benefit has undergone changes since 5.15, so will be ported one-by-one to avoid conflicts on cherry-picks. Pick-to: 6.6 6.5 Change-Id: I566bab1803e3675f75a9fdf294a4b0f047d21c11 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* SlotObjectGuard: mark ctor nodiscardMarc Mutz2023-07-181-1/+1
| | | | | | | | QUIP: 19 Pick-to: 6.6 Change-Id: Idaf8cda12fe2ca97a763d78ff4c8cd7304d178e5 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move plug and paint example to manual testTor Arne Vestbø2023-06-301-11/+1
| | | | | | Pick-to: 6.5 6.6 Change-Id: Ibfd870f2f879d6ae68cd6806b0c1ab02da0a3441 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QT_NO_CONTEXTLESS_CONNECT: docs tidiesGiuseppe D'Angelo2023-06-251-1/+1
| | | | | | | Missing verb from sentence... Change-Id: If0afbe3cb7197ec620a61e0b90e379592b581d74 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QObject: introduce QT_NO_CONTEXTLESS_CONNECTGiuseppe D'Angelo2023-06-241-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | The 3-arguments overload of connect() is error-prone / easy to misuse: * it's easy to e.g. connect to a lambda, and capture local state in the lambda. By not passing a receiver/context, the connection won't get disconnected if the local state gets destroyed (effectively, it creates a "dangling connection"); * in a multithread scenario, one may not realize that the connection is forced to be direct. If the signal is emitted in another thread than the one establishing the connection¹, then the functor will be invoked in that other thread. (Not that "the thread establishing the connection" has ever mattered, but again, this API is error-prone.) Add a macro that allows users to disable the overload in their project. I'm not going for deprecation because there's simply too much code around that uses it. [ChangeLog][QtCore][QObject] Added the QT_NO_CONTEXTLESS_CONNECT macro. Defining the macro before including any Qt header will disable the overload of QObject::connect that does not take a receiver/context argument. Change-Id: I86af1029c1a211ea365f417aae9038d3fcacadfd Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QBindable: Fix out-of-bound access in non-bindable property support codeFabian Kosmale2023-06-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | QObjectPrivate::getPropertyAdaptorSlotObject called connectionsForSignal. Calling this function is only safe after it has been ensured beforehand that the vector has size > signalIndex. As getPropertyAdaptorSlotObject is not supposed to modify the vector, it does not resize the vector and it could consequently end up with an out-of-bounds read. To avoid that issue, we instead first check if the vector can potentially contain an entry for the signal. If not, we simply return nullptr, and avoid the call to connectionsForSignal. The issue and its fix can be verified by running the modified tst_qproperty test with ASAN enabled. The test is modified in the following way: - We first create a signal connection to a dummy slot. Otherwise, connections.loadRelaxed() would return a nullptr, and the problematic code would never be reached. - We add enough signals to ensure that the fooChanged signal will actually be out of reach (which means >= 8 signals, as the initial capacity of the vector is 8) Running the test without ASAN will most likely not result in a failure, as then the out-of-bounds read will simply read garbage, and the most likely result is that the cast below will fail. Pick-to: 6.6 6.5 Change-Id: I18a3c4f52769c2b6491a685abb84f6fcfb44e4d8 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* RIP QBasicMutexLockerMarc Mutz2023-06-161-12/+12
| | | | | | | | | | | | | | | | | This was used as a work-around for Q5MutexLocker's UB downcasting QBasicMutex to QMutex, and for some unspecified performance improvements. Now that Q6MutexLocker is a template, the two are almost token-by-token identical, so we can remove this work-around and use QMutexLocker directly. Partially reverts aea500d5d76864bb1a3918e338ca6806e1766e41. Pick-to: 6.6 6.5 6.2 Change-Id: I57ef5c53999869aa3454fbbaad884c1d18591b2a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix sending deferred delete events when posted before outermost loopMikolaj Boc2023-06-091-0/+1
| | | | | | | | | | | | | | | | | | | | | QDeferredDeleteEvent has the loopLevel field, which is a sum of scope and loop levels found at posting. In sendPostedEvents however, it is impossible to only use this information to find delete events posted before the outermost loop (which should be handled by any loop) based solely on this information, as the scope level essentialy removes the information on loop level. Break the loopLevel in two, storing both loop and scope levels in QDeferredDeleteEvent, so that we can check whether an event was posted before the outermost event loop (for which we need to compare only the loop level). QDeferredDeleteEvent was also made private as it should - it is an implementation detail that wasn't hidden properly. Change-Id: I0a607a0bd3a2deb5024acad67f740dbf4338574c Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
* QObject: add setProperty() overload taking rvalue QVariantMarc Mutz2023-05-311-4/+20
| | | | | | | | | | | | | | | | Instead of duplicating the long-ish implementation, simply pass the variant as pointers to const and mutable, and implement a runtime version of std::forward. [ChangeLog][QtCore][QObject] Added setProperty() overload taking an rvalue QVariant. Fixes: QTBUG-113281 Task-number: QTBUG-112762 Change-Id: Ifdc8f626ad5db138073474c3bd95ec7308c4396b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-25 09:08:45 +0000