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>
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>
This is a combination of Q_UNREACHABLE() with a return statement.
ATM, the return statement is unconditionally included. If we notice
that some compilers warn about return after __builtin_unreachable(),
then we can map Q_UNREACHABLE_RETURN(...) to Q_UNREACHABLE() without
having to touch all the code that uses explicit Q_UNREACHABLE() +
return.
The fact that Boost has BOOST_UNREACHABLE_RETURN() indicates that
there are compilers that complain about a lack of return after
Q_UNREACHABLE (we know that MSVC, ICC, and GHS are among them), as
well as compilers that complained about a return being present
(Coverity). Take this opportunity to properly adapt to Coverity, by
leaving out the return statement on this compiler.
Apply the macro around the code base, using a clang-tidy transformer
rule:
const std::string unr = "unr", val = "val", ret = "ret";
auto makeUnreachableReturn = cat("Q_UNREACHABLE_RETURN(",
ifBound(val, cat(node(val)), cat("")),
")");
auto ignoringSwitchCases = [](auto stmt) {
return anyOf(stmt, switchCase(subStmt(stmt)));
};
makeRule(
stmt(ignoringSwitchCases(stmt(isExpandedFromMacro("Q_UNREACHABLE")).bind(unr)),
nextStmt(returnStmt(optionally(hasReturnValue(expr().bind(val)))).bind(ret))),
{changeTo(node(unr), cat(makeUnreachableReturn,
";")), // TODO: why is the ; lost w/o this?
changeTo(node(ret), cat(""))},
cat("use ", makeUnreachableReturn))
);
where nextStmt() is copied from some upstream clang-tidy check's
private implementation and subStmt() is a private matcher that gives
access to SwitchCase's SubStmt.
A.k.a. qt-use-unreachable-return.
There were some false positives, suppressed them with NOLINTNEXTLINE.
They're not really false positiives, it's just that Clang sees the
world in one way and if conditonal compilation (#if) differs for other
compilers, Clang doesn't know better. This is an artifact of matching
two consecutive statements.
I haven't figured out how to remove the empty line left by the
deletion of the return statement, if it, indeed, was on a separate
line, so post-processed the patch to remove all the lines matching
^\+ *$ from the diff:
git commit -am meep
git reset --hard HEAD^
git diff HEAD..HEAD@{1} | sed '/^\+ *$/d' | recountdiff - | patch -p1
[ChangeLog][QtCore][QtAssert] Added Q_UNREACHABLE_RETURN() macro.
Change-Id: I9782939f16091c964f25b7826e1c0dbd13a71305
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Platforms where we use futex do not allocate.
Windows gained support in 6.2, but the noexcept macro was missed.
Amends 91f6460aff
Change-Id: I76da48fbaac5749fdec4ec76de6a0ff891b78442
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace, with manual
unstaging of the actual definition and documentation in dist/,
src/corelib/doc/ and src/corelib/global/.
Task-number: QTBUG-99313
Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
qExchange is one of the few remaining functionalities that have not been
moved out of qglobal. Given that std::exchange exists in the standard, we
can simply move to it everywhere...
...if it weren't for the fact that std::exchange is only constexpr in
C++20, and only has its noexceptness specified in (most likely) C++23.
Still, we want to move to the existing std functionality where
possible, to allow the removal of qglobal includes in lieu of something
more fine-grained in the future.
So leave any constexpr calls[1] alone for now (and observe that none of
our current usages cares about the conditional noexceptness), but
replace everything else.
[1] QScopedValueRollback' ctor and QExplicitlySharedDataPointerV2::take
Task-number: QTBUG-99313
Change-Id: I599cb9846cf319c7ffd3457130938347a75aad25
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The define has always been set, so we can simplify all the code that
checked for it.
Change-Id: I9133ba95dbd6e1da465ade1d1306310bd3fb9a45
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
C++11 atomics should be available everywhere, even it bootstrapped
builds. This will allow further simplificattions.
Task-number: QTBUG-103847
Change-Id: Ic8aaec5667ef7616a6aa1f0dfc2f64d327308501
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QAtomic] Documented new overloads of testAndSet()
that were originally added for 5.3.
Fixes: QTBUG-103008
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I96c7b5828dc284651e6514389f405d7670d6784b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
To support cancellation of continuations attached via the parent future,
for each future returned by a continuation we store a pointer to its
parent (i.e. future the continuation is attached to). Later, before
executing a continuation, we go through chain of parents and check if
any of them is cancelled. However, if one of the parents is destroyed
while the chain is executing, the next continuations' parent pointers
will become invalid. So storing the parent pointers isn't safe.
This commit changes the logic of handling the cancelled continuation
chain in the following way:
- Instead of storing a parent pointer in the continuation future's data,
we do the opposite: we store a pointer to continuation's future in the
parent.
- When a future is cancelled, we mark all continuation futures in the
chain with a flag indicating that the chain is cancelled.
- To guarantee that the pointers to continuation future's data don't
become invalid, we clean the continuation (that stores a copy of its
future's data and keeps it alive) only when the associated promise
is destructed, instead of cleaning it after the continuation is run.
Fixes: QTBUG-105182
Fixes: QTBUG-106083
Pick-to: 6.2 6.3 6.4
Change-Id: I48afa98152672c0fc737112be4ca3b1b42f6ed30
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
__has_include(<chrono>) is always true, because C++11 chrono include
is required since 6.0.
Pick-to: 6.4 6.3 6.2
Change-Id: I50cb92571bf4f1f86e2f3f2b5f486dd3c3f30f4a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Applied Q_CONSTINIT to variables with static storage duration, but
skipped the POD types with core constant initializers.
Task-number: QTBUG-100486
Change-Id: Iaabf824e9cb0f29a405a149912200d4e4b3573c1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Fix possible undefined behavior in clear_thread_data.
The key used in pthread_setspecific must be obtained
from pthread_key_create or undefined behavior occurs.
Use set_thread_data to clear it since it ensures that
the key has been obtained using pthread_key_create
by calling pthread_once using
create_current_thread_data_key.
Fixes crash when closing threaded qt apps on NetBSD.
Pick-to: 5.15 6.2 6.3 6.4
Change-Id: I1c7d2628f4248e00a12724a952568f7d92011986
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add implementation for requestInterruption() and
isInterruptionRequested().
Pick-to: 6.4
Change-Id: I9ffabb0181a48c71deded7362c6c8e2e96418cc0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use correct text formatting; this ensures e.g. the decrement
operator isn't converted to an en dash in the docs. Apply
to increment operator docs also for consistency.
Task-number: QTBUG-105729
Change-Id: I5f126b90bc1d1b91d86e1f87c9b17a583841adb6
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
error: right shift count >= width of type [-Werror=shift-count-overflow]
Pick-to: 6.4
Fixes: QTBUG-105687
Change-Id: Ic6547f8247454b47baa8fffd170bd9cd0e2a8ca3
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Deal with the case that the object gets deleted between a call to
moveToThread and the start of the thread by removing the object from the
list in that case.
Fixes: QTBUG-104014
Pick-to: 6.4
Change-Id: Ib249b6e8e8dfbc4d1332bb99a57fa9d3cff16465
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If we create a QThread from QThread::current(), we want it to have a
correct value for its bindingStatus. Thus, initialize bindingStatus in
the ctor of QAdoptedThread.
Task-number: QTBUG-101177
Task-number: QTBUG-102403
Pick-to: 6.4 6.3
Change-Id: I3ef27ed62c5dc25eed05d551c72743a1b8528318
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QFutureCallOutEvent is used externally, so it needs to be exported.
This reverts commit 3141a13b2a.
Fixes: QTBUG-104732
Pick-to: 6.4
Change-Id: I82c9e7414192ee948f78259bd74a404691a7805a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
It's always true these days, assert so in qatomic.cpp and
tst_QAtomicInteger.
Update the docs.
Pick-to: 6.4
Change-Id: I3684cff96c1d2e05677314e29514cc279bd6b1a1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This method isn't used anymore, but we can't remove it entirely for BC
reasons, because it was called from inline code.
Pick-to: 6.4
Change-Id: I9183c666c466030787ac7c2386706b50abf23eaa
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
While in a private header, it did manage to place QList<QPostEvent>
operations near the top spots of all Qt template instantiations in a
QtWidgets build.
Task-number: QTBUG-97601
Pick-to: 6.4
Change-Id: I4fa1972b8764b71ad0559633131e7e44b3d4ae6a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If the QFuture is canceled because the associated QPromise has been
destroyed, we still need to run its continuations (i.e. onCanceled
handler, if it's attached), so replaced the cleanContinuation() call
inside ~QPromise() with runContinuation(), which will also take care of
cleaning the continuation.
[ChangeLog][QtCore][Important Behavior Changes] QFuture now runs its
continuations when its associated QPromise has been destroyed.
Previously, if a QFuture was canceled because the associated QPromise
has been destroyed, its continuations were skipped.
Fixes: QTBUG-103992
Pick-to: 6.4 6.3 6.2
Change-Id: Ie05bc760c96c349aade8adb8d2fe5263aff8efac
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Found by codespell
Pick-to: 6.4
Change-Id: Ie3e301a23830c773a2e9aff487c702a223d246eb
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
On finishing/terminating a thread, when processing posted events,
we need to consider QThread's own data instead of caller thread's data.
Otherwise we can get into unexpected situations such as double
destruction of an object, premature destruction, etc.
Fixes: QTBUG-103922
Pick-to: 6.4 6.3 6.3.1 6.2 5.15
Change-Id: Idf77221ebbaa0b150ee2d0c296b51829ae8dc30e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... and bindingStatus()
QBindingStatus* is the final state of the value chain in
m_statusOrPendingObjects, so we can use the Double-Checked Locking
Pattern to avoid locking the mutex when we already have a status - it
won't go away again, unlike the vector in the List state.
To enable the change, make the data member an atomic<>. All loads and
stores can continue to use memory_order::relaxed, except the loads of
a potential status, which have to acquire, and the store of the
status, which has to release. This creates the necessary
synchronizes-with relation. So even though we synchronize out of
middle of the mutex critical section in QThread::exec() this way,
there's no data race between QThread::exec() and a potential
bindingStatus() call.
Change-Id: I0e0b7bd305649fa5f56a0f8723fb75f2577b90dd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Amends ba6c1d2785, 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>
Includes fixes in indexed for loops that are either known to modify
the container under iteration, or else aren't known not to do it, so
were kept as indexed loops, instead of being ported to ranged ones.
Pick-to: 6.3 6.2
Task-number: QTBUG-103532
Change-Id: I7047b6127fbc4ac16ee113cfd6d1c71f2caba1e7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The writerCount member variable is only ever accessed under
Private::mutex protection, so we need to lock the mutex here, too.
Pick-to: 6.3 6.2 5.15
Change-Id: I1717e5282eed2ecc14ccdc5090b9fc41174cccc8
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>
The function dereferences the load()ed pointer, so it needs an acquire
fence.
Pick-to: 6.3 6.2 5.15
Change-Id: Ib951de3f00851d915fec3392cdaba64f4a994300
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We need an acquire fence before we delete the d-pointer. Otherwise,
the reads that the dtor performs (QReadWriteLockPrivate contains many
non-trivial data types such as std::mutex and QVLA), race against
writes performed in other threads. The qWarning() indicates that
QReadWriteLock can not rely on external synchronization to ensure
a happens-before relationship between reads in the dtor and said writes.
While an explicit fence just before the delete would suffice, the guard
return is an extremely unlikely error case, and if we ignore it, then
loadAcquire() is correct, so use that.
Pick-to: 6.3 6.2 5.15
Change-Id: I29773b665a7f864cd6b07a294da326e8b10399b5
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
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>
I don't see a way this can be anything but a bogus warning.
In member function ‘std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::fetch_or(__int_type, std::memory_order) [with _ITp = int]’,
inlined from ‘static T QAtomicOps<X>::fetchAndOrRelaxed(std::atomic<T>&, typename QAtomicAdditiveType<T>::AdditiveT) [with T = int; X = int]’ at qatomic_cxx11.h:449:33,
inlined from ‘T QBasicAtomicInteger<T>::fetchAndOrRelaxed(T) [with T = int]’ at qbasicatomic.h:168:36,
inlined from ‘int switch_on(QAtomicInt&, int)’ at qfutureinterface.cpp:97:31,
inlined from ‘void QFutureInterfaceBase::setThrottled(bool)’ at qfutureinterface.cpp:194:18:
atomic_base.h:648:33: warning: ‘unsigned int __atomic_or_fetch_4(volatile void*, unsigned int, int)’ writing 4 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
A few more of those appear in other modules. I'm not fixing them all,
assuming GCC will soon fix the warning.
Pick-to: 6.2 6.3
Change-Id: I7fb65b80b7844c8d8f26fffd16e93f68e278d048
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The std variant is faster and more compact.
Use the QtPrivate wrappers to avoid the Integrity mess.
Change-Id: I4a1b1626d29472af059fee55ca26c31d9522b179
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Commit 1808df9ce5 changed the Linux code
to read the third field in the TCB header instead of the first, because
that matches what FreeBSD does and what the documentation for the ABI
appears to say. But it broke MUSL builds because they apparently don't
obey the ABI. So don't use the inline code with libcs other than glibc.
Pick-to: 6.2 6.3
Task-number: QTBUG-103000
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eba7748de50ddd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Mike Achtelik <mike.achtelik@gmail.com>
This loop here was a lonesome instance of a CAS loop in which adding
_mm_pause() was simple, because the code didn't use the usual pattern
do {
construct new value
} while (!testAndSet)
we use everywhere else in Qt.
In search of an elegant pattern that would allow to apply
qYieldCpu()/_mm_pause() to those idiomatic CAS loops, too, I've
reached for a lambda to construct the new value. This should apply to
all (tight) CAS loops, and may form the basis of an API extension
whereby we take that lambda as a function argument to encapsulate the
CAS loop in an algorithm (a function).
Pick-to: 6.3
Change-Id: Id4a8f174dd812aa26f0b163e943bd4558e5e6a7b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We were reading from the wrong offset. It just happened to work on Linux
because the values stored in the first and third fields of tcbhead_t[1]
are the same. But that is not the case on FreeBSD for the same thing[2].
Confirmed by disassembly. Linux:
Dump of assembler code for function __GI___pthread_self:
0x00007ffff71b6efe <+0>: endbr64
0x00007ffff71b6f02 <+4>: nop
0x00007ffff71b6f03 <+5>: nop
0x00007ffff71b6f04 <+6>: mov %fs:0x10,%rax
0x00007ffff71b6f0d <+15>: ret
FreeBSD:
(gdb) disass pthread_self
Dump of assembler code for function _Tthr_self:
0x0000000800324790 <+0>: push %rbp
0x0000000800324791 <+1>: mov %rsp,%rbp
0x0000000800324794 <+4>: cmpq $0x0,0x8b1c(%rip) # 0x80032d2b8 <_thr_initial>
0x000000080032479c <+12>: jne 0x8003247a5 <_Tthr_self+21>
0x000000080032479e <+14>: xor %edi,%edi
0x00000008003247a0 <+16>: call 0x80031de40 <_libpthread_init>
0x00000008003247a5 <+21>: mov %fs:0x10,%rax
0x00000008003247ae <+30>: pop %rbp
0x00000008003247af <+31>: ret
Also confirmed not to affect macOS:
(lldb) disass -n pthread_self
libsystem_pthread.dylib`pthread_self:
libsystem_pthread.dylib[0x7ff80032186c] <+0>: pushq %rbp
libsystem_pthread.dylib[0x7ff80032186d] <+1>: movq %rsp, %rbp
libsystem_pthread.dylib[0x7ff800321870] <+4>: movq %gs:0x0, %rax
[1] https://code.woboq.org/userspace/glibc/sysdeps/x86_64/nptl/tls.h.html#tcbhead_t
[2] https://github.com/freebsd/freebsd-src/blob/main/sys/x86/include/tls.h#L43
Pick-to: 6.2 6.3
Fixes: QTBUG-103000
Change-Id: I7fb65b80b7844c8d8f26fffd16ea67d2f3461964
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
From the Intel Software Optimization Manual[1], Chapter 11 ("Multi-core
and Hyper-Threading Technology"), offers:
User/Source Coding Rule 14. (M impact, H generality) Insert the PAUSE
instruction in fast spin loops and keep the number of loop repetitions
to a minimum to improve overall system performance.
See section 11.4.2 for an explanation of why this is a good idea.
[1] https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html#inpage-nav-5
Pick-to: 6.3
Change-Id: I7fb65b80b7844c8d8f26fffd16e94088dad1ceee
Reviewed-by: Sona Kurazyan <sona.kurazyan@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>
This constructor was used in the previous implementation of
clone(). The current implementation uses the compiler-generated
copy-constructor.
Change-Id: Ibae163653e43ceb2b07872b496cd004e50b1e625
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add one and reset the wakeAll bit atomically.
This avoids a race in a case where an acquiring thread
is owning the semaphore, and deleting it after a
set number of releases (one for each thread referencing the semaphore).
Two releasing threads could enter the if statement under
futexNeedsWake(prevValue), the counter been incremented at
this point and reached the value being acquired, meaning the thread
acquiring can be awakened by just one of the two releasers,
delete the semaphore, and then the second releaser would access
the now deleted semaphore.
The patch avoids that by unsetting and reading the wakeAll bit
atomically, so only one thread will try to wake all threads.
Pick-to: 6.3 6.2 5.15
Fixes: QTBUG-102484
Change-Id: I32172ed44d74378c627918e19b9e1aaadb5c6d1d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A previous commit Q_CORE_EXPORTed this class so it could be used in
tst_qevent. But we can also keep it Q_AUTOTEST_EXPORTed and make the
testing of the class subject to QT_BUILD_INTERNAL on the test side.
That's what this patch does.
Change-Id: I9bd5f80ada856b7db4b39dfb59b32bd825416c13
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
There's no advantage to them being inline: Absent de-virtualisation,
clone() is only supposed to be called through the vtable, and the copy
ctor is only supposed to be used in the implementation of clone().
And when the compiler de-virtualises, we don't want the code
duplication associated with inlining.
Enforce this by introducing new macros to hide the boilerplate.
This fixes missing out-of-line dtors in:
- QSinglePointEvent
- QApplicationStateChangeEvent
- QFutureCallOutEvent
Wrong covariant return in:
- QFutureCallOutEvent
And missing clone() reimplementations in:
- QCloseEvent
- QIconDragEvent
- QShowEvent
- QHideEvent
- QDragEnterEvent
- QDragLeaveEvent
While these don't carry extra data or members, a dynamic_cast of the
result of clone() as well as using the expected covariant return value
would fail:
QShowEvent *e = ~~~;
QShowEvent *e2 = e->clone(); // ERROR: converting QEvent* to QShowEvent*
Check that reimplementing clone() is binary compatible (covariant
returns may change the numerical pointer value returned, cf.
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B).
The copy-assignment operator stays inline for the time being, as the
goal is to = delete it in the future.
This patch covers, roughly, QtCore and QtGui.
[ChangeLog][QtGui][QEvent subclasses] Fixed missing clone()
reimplementations on QCloseEvent, QIconDragEvent, QShowEvent,
QHideEvent, QDragEnterEvent, and QDragLeaveEvent.
Task-number: QTBUG-45582
Task-number: QTBUG-97601
Change-Id: Ib8a0519dbe85a7a8da61050d48be338004dfa69a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Marc Mutz
Luca Di Sera
Mårten Nordheim
Thiago Macieira
Fabian Kosmale
Jaishree Vyas
Sona Kurazyan
Konrad Kujawa
Niclas Rosenvik
Tobias C. Berner
Morten Sørvig
Paul Wicking
Kai Köhne
Vladimir Belyavsky
Lucie Gérard
Marc Mutz
Allan Sandfeld Jensen