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>
This reverts commit 22d4c67234fd152296c3ec98fc57526356a9f62b.
Reason for revert: The fix causes crashes
tst_QObjectRace::disconnectRace2 and we don't currently have a
clear resolution on further fixes.
Task-number: QTBUG-107034
Change-Id: I310c27654f125cdb2939940d432724e73c89f485
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Commit 71b4d4f150bc3c904a5aceec37513ddc3cd1c150 is likely the source of
the issue. It fixed a race on disconnection, but kept the call to
disconnectNotify() (which is user code) inside the locked section. My
analysis is that by construction the sender object can't be undergoing
concurrent deletion anyway at this point. All call sites
(QObject::disconnect or the signal-slot activations but before the slot
is activated) imply that the user code that reached here cannot itself
be racing the deletion.
There may be one race condition left: if the same signal was connected
earlier to a slot via queued connection and that slot deletes the sender
asynchronously. A synchronous deletion is handled by doActivate(), so
the single-shot connection is never activated in the first place, but an
asynchronous deletion could race past that check and delete the sender
while QObjectPrivate::removeConnection is running. However, I'd call
this a mistake in user code.
[ChangeLog][QtCore][QObject] Fixed a regression from 6.3 that caused
QObject::isSignalConnected() to deadlock if called from inside
disconnectNotify().
Fixes: QTBUG-106025
Pick-to: 5.15 6.2 6.3 6.4
Change-Id: Ic6547f8247454b47baa8fffd170fe0bdb62cfcaf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
This includes QDBusReply, QProperty, and QStringBuilder expressions.
The new constructor subsumes the QStringBuilder case without requiring
jumping though hoops to delay the definition of the ctor the way we
had to for the explicit QStringBuilder constructor, so remove the
explicit QStringBuilder one again.
[ChangeLog][QtCore][QAnyStringView] Can now be constructed from
anything that implicitly converts to either QString or QByteArray.
Fixes: QTBUG-105389
Change-Id: I0e584dd3e20d591381609a3329ef47cec7356ecc
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
The QObjectPrivate::declarativeData member is stored in a union with
currentChildBeingDeleted. The QObject destructor always sets the
currentChildBeingDeleted member of the union. It also sets the
isDeletingChildren bool, which is the only way to find out which union
member we can safely access.
While the QObject destructor is deleting children and isDeletingChildren
is set, we must not access the declarativeData member of the union.
Add a test case that initializes the function pointers for the
declarative handlers and constructs a situation where an object
emits a signal while it is destroying children.
Fixes: QTBUG-105286
Pick-to: 6.4 6.3 6.3.2 6.2 5.15
Change-Id: Iea5ba2f7843b6926a8d157be166e6044d98d6c02
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
https://developercommunity.visualstudio.com/t/C:-constinit-for-an-optional-fails-if-/1406069
does not only affect constinit thread_local but also constinit in
general on MSVC compilers when C++20 is being used. So disable the
feature for these compilers in general for now.
This commit amends d9531593a248e19f7da7862b2870a6af2f413e75
Fixes: QTBUG-105234
Pick-to: 6.4
Change-Id: I1855f0857d85487895460fc7c56675fb864bfa73
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>
Partially reverts 06c2478
Even though these structs are not meant to be used anywhere outside
QObject, some special applications like Gammaray need them to get
details about connections.
Pick-to: 6.4
Fixes: QTBUG-104734
Change-Id: Ied73021e317cc6aed6192c229d9450ae48b6774c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Set it to nullptr on clear, and deal with possibly null bindingStatus.
Task-number: QTBUG-101177
Task-number: QTBUG-102403
Pick-to: 6.4
Change-Id: I66cb4d505a4f7b377dc90b45ac13834fca19d399
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Amends ba6c1d2785ca6d8a8b162abcd9d978ab0c52ea2d, which made
m_statusOrPendingObjects already atomic, but did not handle concurrent
deletion/push_back of the pendingObjects vector correctly.
We use the existing lock in QThreadPrivate to prevent data races.
Pick-to: 6.2 6.3
Fixes: QTBUG-101681
Change-Id: I0b440fee6ec270d762e6700a4fe74f28b19e75e8
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Replace implicit conversions from QAtomicPointer<T> → T* with the
equivalent, but explicit, loadAcquire().
This is in preparation of deprecating the implicit QAtomic<T> ↔ T
conversions.
Change-Id: I6c8476a705c3996ef724dd63b58d9526d1a39af7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The implicit conversion operator from QAtomicPointer<T> → T* performs
a loadAcquire().
In the cases of this patch, we're only comparing pointer values to
check whether QObject thread affinities are compatible, so relaxed
loads suffice.
Pick-to: 6.3
Change-Id: If19124778b4770d86baeaeb3c91214e47881b288
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
We don't need to reload d->threadData, as we've already loaded it into
a register three lines above, so use the already-loaded value.
We don't care whether we might have read a different value the second
time around, because that would mean we had a race condition elsewhere
in the program (e.g. concurrent moveToThread() calls).
Pick-to: 6.3
Change-Id: I29a27ca23302288b5900ac6b45b8690a80e85680
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We don't need an acquire fence for checking a pointer for nullness,
and we're not dereferencing the pointer later, so use a relaxed load
there.
Pick-to: 6.3
Change-Id: Id84e6fc50100f1bf6a4e33f89424f8b1cbb250cd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We dereference thisThreadData in the next line, at a point in time
where we haven't, yet, verified that it's this_thread's QThreadData,
so we need an acquire fence.
The alternative would be to re-arrange the code so that dereferencing
the pointer is delayed until after we verified it's this_thread's, but
that doesn't seem readily possible.
Even if it was easy, we'd first need to verify whether there are any
writes into QThreadData objects after they've been constructed, in
which case the acquire fence may be needed even in case it's 'ours'.
So just add the acquire fence.
Pick-to: 6.3 6.2 5.15
Change-Id: I468bc1f971bd87345bfcd6c13b7384bdf09d086a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... out of QThreadData.
No-one except two functions in qobject.cpp uses the object, and its
creation is constinit, so there's no advantage to expose it to the
world as a QThreadData member.
Remove it from QThreadData, move the class' definition to the unnamed
namespace in qobject.cpp, ensure constinit'ability by letting the
language zero out the members (as opposed to an STL algorithm call),
declare it constinit thread_local static, and adapt the two users
(basically, removing the retrieval of QThreadData::current()).
Almost no effect on Clang, but saves ~400 bytes on optimized GCC 11.2
Linux AMD64 C++20 builds.
Change-Id: I22432d4ec5eb4ab59920656409b21768983fb4db
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
They already nicely factored this error-only code from the normal path
of execution. All that was missing was for them to be marked as COLD,
so the compiler moves them out of the way even further, and optimizes
them for size, not speed.
TEXT size savings: ~400b on GCC 11.2 and ~500b on Clang 10 optimized
C++20 AMD64 Linux builds.
Pick-to: 6.3 6.2 5.15
Change-Id: I64a4123645855b4e34fbb0bc3304d144d7191a0d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The `inline` keyword does not control inlining, as we all know (use
Q_ALWAYS_INLINE to force inlining, if required). However, it does
control the emission of the out-of-line copy of an inline function, if
the compiler did inline it where it got used: with the keyword, no copy
is required, which is our objective here.
Furthermore, we compile with -fvisibility-inlines-hidden with
GCC-compatible compilers (all but MSVC and Integrity's), which means
those functions will never be in the ABI of QtCore: they'll either have
been inlined with no out-of-line copy, or that out-of-line emission is
hidden.
Change-Id: If2e0f4b2190341ebaa31fffd16e31584561669f2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
All of this connection management code is used only in QtCore and
mustn't be touched by other modules (not even qtdeclarative). So there's
no reason for it to be around and slow down the compilation time of
everything using QObjectPrivate.
Change-Id: If2e0f4b2190341ebaa31fffd16e31313f1b7020f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
It expands to the first available of
- constinit (C++20)
- [[clang::require_constant_initialization]] (Clang)
- __constinit (GCC >= 10)
Use it around the code (on and near static QBasicAtomic; this patch
makes no attempt to find all statics in qtbase).
[ChangeLog][QtCore][QtGlobal] Added macro Q_CONSTINIT.
Fixes: QTBUG-100484
Change-Id: I11e0363a7acb3464476859d12ec7f94319d82be7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This was lost when QtCore, QtGui and QtWidgets were split up. Restored
now via a virtual function on QObjectPrivate.
Chose to return std::string instead of QString or QByteArray because
its SSO is usually sufficient to hold these flag strings.
[ChangeLog][QtCore][QObject] Restored printing of Qt3-style
information from dumpObjectTree().
[ChangeLog][QtWidgets][QWidget] Restored printing of Qt3-style
information from QWidget::dumpObjectTree().
Fixes: QTBUG-101732
Change-Id: I39ff5728ea5f5abbdbf81b5d7e13b8d16b6ee8b7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In no particular order:
- use the variable field width feature of QString::asprintf() to
generate the indentation implicitly, instead of fill()ing a
QByteArray with the desired number of spaces
- just default-construct 'flags', don't assign an empty string
- use qUtf16Printable() to avoid funneling UTF-16 data through 8-bit
encodings
- use a C++11 ranged for instead of a counted loop
- remove a pointless isEmpty() guard (the loop won't execute when the
children().isEmpty())
- avoid copying object->children() (returns by cref, so it's also ok
to stuff it directly into the ranged for loop).
Add a test.
Pick-to: 6.3
Change-Id: Ie7314713cb48de7e890cdee0760c0361dd24fd18
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... while keeping the QString overload for users that pass actual
QStrings (e.g. QStringLiteral).
However, QString and QAnyStringView cannot be overloaded (they're
ambiguous for most arguments), so we need to make one of them a
Q_WEAK_OVERLOAD.
Normally, we'd make the new function weak and keep the old function
as-is, but, here, that would be beside the point, because all callers
would continue to resolve to the QString overload, and nothing would
call the QAnyStringView one.
So we really want the old function to be the Q_WEAK_OVERLOAD, so that
the QString overload is only selected when actual QStrings are
passed. That means we need to leave the old function in a compat build
(compiled in, but not visible in the public header). Since
Q_WEAK_OVERLOADs cannot be (easily) exported (they're templates), make
it call a private function (which can be, and is, exported).
Reviewers may questions whether one can overload
setObjectName() and
template <typename = void> setObjectName()
The answer is that we can, because templates mangle differently from
normal functions. We can even call the template function (with
explicit template arguments), as seen in removed_api.cpp.
This adapts the interface of the function to how most users use it:
They pass QLatin1String or just const char[]. Only very few passed
QStringLiteral, which, ignoring that fact that it produces a ton of
code for the temporary QString's destructor that's never executed,
would have been, and continues to be, the optimal way of passing data,
modulo plugin bugs (QTBUG-51602, QTBUG-49061).
[ChangeLog][QtCore][QObject] Added setObjectName() overload taking
QAnyStringView.
Fixes: QTBUG-101393
Change-Id: I1243545614754b4978d4c8641460980b6b293c1a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
... to centralize the creation of QObjectPrivate::extraData.
Change-Id: I04e97779ceb0168fa7660e77e0dab2ed3e1ad03e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
QObject's cache the binding status pointer to avoid TLS lookups.
However, when an object is moved to a different thread, we need to
update the cached pointer (as the original thread might stop and thus no
longer exist, and to correctly allow setting up bindings in the object's
thread).
Fix this by also storing the binding status in QThreadPrivate and
updating the object's binding status when moved. This does only work
when the thread is already running, though. If it is not running, we
instead treat the QThreadPrivate's status pointer as a pointer to a
vector of pending objects. Once the QThread has been started, we check
if there are pending objects, and update them at this point.
Pick-to: 6.2 6.3
Fixes: QTBUG-101177
Change-Id: I0490bbbdc1a17cb5f85044ad6eb2e1a8c759d4b7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
By changing it to unique_ptr.
Pick-to: 6.2 6.3
Change-Id: I91abb69445b537d4c95983ae735341882352b29d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Even QtCore alone cannot be built without the properties feature since
Qt 5.5. While fixing this is easy, other modules like dbus,
networking are also using QObject::property() and friends liberally.
All in all I doubt that anybody will miss the feature (otherwise it
would have been fixed in the last decade).
Change-Id: Iaf3cc20bda54ee2ff3b809fac8fa82b94ecc88c0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The new binding system made it impossible to read from non-owning threads,
but we have code that did so with external locking. This patch makes it
safe again, assuming all reads and writes are locked. This is left
intentionally undocumented.
Pick-to: 6.3 6.2
Task-number: QTBUG-99775
Change-Id: I845afa5d545ca0ac762ac369181b1497dac52195
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QWidget and QWindow use bits in QObjectPrivate to provide for a couple
of shortcuts -- one in qobject_cast, and another in the isWidgetType() /
isWindowType() functions in QObject. These can be optimized by simply
looking at the bits, without actually doing more expensive runtime
casts.
These bits were set on construction, but not unset on destruction. The
result was for instance that destroying a QWidget would report that the
object was still a QWidget when ~QObject was reached.
Fix this
1) by setting the bits only when QWidget / QWindow constructors start;
2) by resetting the bits once ~QWidget / ~QWindow are completed.
Technically speaking this is not 100% correct in the presence of data
members, but luckily those classes don't have any.
Amend an existing test for QWidget (whose comment said exactly the
opposite of what the test actually did) and add a test for QWindow.
Some other code was wrongly relying on isWidgetType() returning true
for destroyed QWidgets; amend it as needed.
[ChangeLog][QtCore][QObject] Using qobject_cast on partially constructed
or destroyed QWidget/QWindow instances now yields correct results.
Similarly, using the convenience isWidgetType() / isWindowType()
functions now correctly return false on such instances. Before,
qobject_cast (and the convenience functions) would erroneously report
that a given object was a QWidget (resp. QWindow) even during that
object's construction (before QObject's constructor had completed) or
destruction (after QWidget's (resp. QWindow's) destructors had been
completed). This was semantically wrong and inconsistent with other ways
of gathering runtime type information regarding such an object (e.g.
dynamic_cast, obj->metaObject()->className() and so on).
Pick-to: 6.3
Change-Id: Ic45a887951755a9d1a3b838590f1e9f2c4ae6e92
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Like Q_NAMESPACE_EXPORT for Q_NAMESPACE, this variant of Q_GADGET
allows passing an export macro. This is useful to avoid exporting the
whole class just to get the staticMetaObject hidden therein exported.
Before anyone asks: No, we don't need Q_OBJECT_EXPORT, because QObject
subclasses, being polymorphic, always need to have a class-level
export macro (to export their vtable), but while that technique also
works for value classes (the Q_GADGET audience), it is not desirable
for them, because it makes inline functions exported in Windows debug
builds, which is not what we want, because it needlessly restricts
what you can to with the inline functions (e.g. remove).
[ChangeLog][QtCore] Added the Q_GADGET_EXPORT macro, which is like
Q_GADGET, but allows passing an export macro (like Q_NAMESPACE_EXPORT
for Q_NAMESPACE).
Fixes: QTBUG-55458
Change-Id: I546297de1e8aa45d83381991bcd3fbca61e1eef0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
In some bug reports we got code which does deleteLater()
on QCoreApplication, however this is not going to work as
the user may expect.
In cases where an application uses Qt WebEngine, this leads
to weird looking crashes on exit as webenginecontext is not
destroyed.
Pick-to: 6.2 5.15
Change-Id: I4d284f30b0c7cad15ba6da3d65cdf813c36ee036
Reviewed-by: Michael Brüning <michael.bruning@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
QT_VERSION is now at least QT_VERSION_CHECK(6, 3, 0), so remove all
checks against Qt 6.0.0 or earlier. They are superfluous. Tidied up in
some places in the process, particularly #include order.
Change-Id: I2636b2fd13be5b976f5b043ef2f8cddc038a72a4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The connect() documentation makes it clear that UniqueConnection does
not work with free functions / function objects and the like; only with
actual PMFs. Rather than silently *ignoring* the flag, be vocal about its
presence by warning, and make the connection fail (as the user has
passed an illegal argument).
[ChangeLog][QtCore][QObject] QObject::connect() now will refuse to
connect a signal to a free function / function object if UniqueConnection
is passed. Note that UniqueConnection has never worked for such
connections -- the flag was simply ignored, and they were established
multiple times. Now, the flag is not ignored and results in a connection
failure (as well as a runtime warning by Qt).
Change-Id: I6509667018c74f9bd24910cde0a1b16c5f84f064
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Outside tests, all in-tree callers of QObject::findChildren() pass no
name to match, and in my experience that is also true for the vast
majority of out-of-tree users.
Avoid the temporary QString creation in the caller and the repeated
QString::isNull() checks in the implementation by overloading
findChildren() without a name argument and checking for name.isNull()
only once, forking off into separate helper functions.
Adjust in-tree callers that used an explicit `QString()` argument in
order to pass options, which goes to show that `name` should never
have been the first argument of findChilden() in the first place, even
though I appreciate the symmetry with findChild() (the use-cases of
which, however, are radically different).
Change a `findChildren().size() == 0` call found while scanning for
findChildren() calls to `!findChild()` as a drive-by.
Modernize loops in the various qt_qFindChild{,ren}_helper() overloads
to match how the new code looks.
[ChangeLog][QtCore][QObject] Added findChildren() overload taking no
name (thus optimizing this common case).
Change-Id: Ifc56e5438023d079b40c67f11ae274a3e128ad5e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
When a signal/slot connection is broken, it gets added to the
sender's list of "orphaned connections", to clean up later.
This cleanup happens when the sender gets destroyed or as soon as
it emits any signal.
This may cause soft memory leaks in case receivers get destroyed,
and the sender is a long living object and doesn't emit signals
for a while (e.g. QThread).
For some reason, an explicit disconnection cleans up the list
(either by using the QMetaObject::Connection object, or in case
of string-based connect, using a string-based disconnect). This
raises lots of doubts about why having this list in the first
place.
Fix the soft-leak by cleaning up the orphaned connection list when
destroying a receiver.
Note: I still believe that we shouldn't have any "orphaned"
connection list, and rather cleanup on disconnect/deletion
(otherwise, emitting a signal may cause a CPU spike because it
triggers a cleanup). If we allow for any "impredictability" during
signal activation we're just admitting that signals/slots aren't
suitable for e.g. low-latency codepaths. That's why I'm not marking
the problem as fixed.
Original-patch-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Task-number: QTBUG-88248
Task-number: QTBUG-87774
Pick-to: 6.2 6.1 5.15
Change-Id: Id25f67a45dff49f740132a44d36e88740eb12070
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This does not fix all data races that we have in the system yet.
One major issue is the virtual disconnectNotify(), that can be
called from any thread and thus is inherently problematic, as it
can collide with the object getting destroyed at the same time
in another thread.
Pick-to: 6.2 6.1 5.15
Task-number: QTBUG-88248
Change-Id: I9d841eb363b7e4f0de1657aeb8f5340d0fd55190
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This function is/will be used in a few places where we already have a
lock. Temporarily unlocking and relocking invites all kinds of troubles.
By adding a flag we can instead tell the function that we already hold
the lock.
Pick-to: 6.2 6.1 5.15
Change-Id: Ibca089de61133661d5cd75290f2a55c22c5d013c
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
queued_activate adds a reference to the slot object. It also attempts to
deref it again, but that did not work correctly so far. We could end up
with
T1 | T2
queued_activate |
checks isSlotObject |
adds ref |
locker.unlock() |
| QObject::~QObject
| //In disconnect all senders loop
| sets isSlotObject to false
| derefs slotObj, but not deleted
checks isSlotObject |
(no deref because it's null) |
To solve this issue and others caused by early returns, we now use a
RAII helper, which always takes care of calling destroyIfLastRef if the
ref count has been incremented.
Change-Id: I9c011cdb8faa5f344d7e70f024fc13f407e39ccf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Once we're in ~QObject, only methods of QObject are still valid.
Notably, no setter of any derived class is still valid. Thus, to be safe
we must no longer react to binding changes of those properties. To
ensure that this happens for QObjectCompatProperty properties, we
explicitly clear the binding storage.
Fixes a particles3d example crash.
Change-Id: I10d2bfa5e96621ce039d751cffaf3ac41893623e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Extended QObjectPrivate::ExtraData to store a pointer
to its parent, and reimplemented qGetBindingStorage()
function for QObjectPrivate::ExtraData.
This allows to use Q_OBJECT_COMPAT_PROPERTY macro
for a property, stored in QObjectPrivate::ExtraData
and solves all the problems with calling a custom
setter.
Task-number: QTBUG-85520
Change-Id: I40e01c29430846359ef9160fa1ae97c702be9a18
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
