- don't write explicit meta functions, use std::conditional
- = default the default ctor
The class is already not trivially-copyable, so making the default
ctor trivial doesn't change the ABI.
Change-Id: I8e35bbbb35973c9ff8fc48dfbfc10061de4bfd30
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
At first glance, libraryPathMutex is only recursive because
setLibraryPaths(), addLibraryPath() and removeLibraryPath(), all of
which lock libraryPathMutex, may call libraryPaths(), which does, too.
This is easily fixed by splitting libraryPaths() into public
libraryPaths() and private libraryPathsLocked(), the latter expecting
to be called with the libraryPathMutex already held. And this is what
this patch does.
However, on second glance, the building of the initial app_libpaths
calls a monstrous amount of code, incl. QLibraryInfo, and some of
that code probably re-enters one of the library-path functions.
So while this patch is a step towards making libraryPathMutex
non-recursive, it's probably not the end.
Change-Id: I3ed83272ace6966980cf8e1db877f24c89789da3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
- use std::make_shared instead of QSharedPointer
- two memory allocations saved
- co-locate semaphore and HRESULT object in a single State object
- one more memory allocation saved
- pass the shared_ptr<State> by value into the runnable
- two more memory allocations saved
Not only is the new code much faster, it's also much more readable.
Also use QSemaphoreReleaser, just in case the delegate should throw.
Change-Id: Ib99b9da86984d440d10b72e3071aa88099e24a1f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Spell it out, or entirely remove it if it's not necessary.
Change-Id: Idc371427e9351d948245ce7b719e3457dfc27845
Reviewed-by: Matthew Woehlke <mwoehlke.floss@gmail.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Mark QCalendarBackend as internal since it is in a private header
and fix some issues in the QCalendar related classes.
src/corelib/time/qcalendar.cpp:201: (qdoc) warning: clang found diagnostics parsing \fn int QCalendarBackend::daysInMonth(int month, int year) const
error: incomplete type 'QCalendarBackend' named in nested name specifier
(repeats)
src/corelib/time/qdatetime.cpp:1426: (qdoc) warning: Unknown command '\override' (repeats)
src/corelib/time/qcalendar.cpp:642: (qdoc) warning: Undocumented enum item 'Last' in QCalendar::System
src/corelib/time/qcalendar.cpp:642: (qdoc) warning: Undocumented enum item 'User' in QCalendar::System
src/corelib/time/qcalendar.cpp:744: (qdoc) warning: Undocumented parameter 'year' in QCalendar::isLeapYear()
src/corelib/time/qcalendar.cpp:923: (qdoc) warning: Can't link to 'dateTimeString()' (repeats)
src/corelib/time/qcalendar.cpp:893: (qdoc) warning: No such parameter 'year' in QCalendar::partsFromDate()
src/corelib/time/qcalendar.cpp:893: (qdoc) warning: No such parameter 'month' in QCalendar::partsFromDate()
src/corelib/time/qcalendar.cpp:893: (qdoc) warning: No such parameter 'day' in QCalendar::partsFromDate()
src/corelib/time/qdatetime.cpp:1425: (qdoc) warning: Undocumented parameter 'nmonths' in QDate::addMonths()
src/corelib/time/qdatetime.cpp:1467: (qdoc) warning: Undocumented parameter 'nyears' in QDate::addYears()
src/corelib/statemachine/qstatemachine.cpp:2522: (qdoc) warning: Undocumented enum item 'StateMachineChildModeSetToParallelError' in QStateMachine::Error
src/corelib/kernel/qtimer.cpp:602: (qdoc) warning: Undocumented parameter 'connectionType' in QTimer::callOnTimeout()
src/corelib/time/qcalendar.cpp:159: (qdoc) warning: Undocumented parameter 'name' in QCalendarBackend::QCalendarBackend()
src/corelib/time/qcalendar.cpp:159: (qdoc) warning: Undocumented parameter 'id' in QCalendarBackend::QCalendarBackend()
src/corelib/time/qcalendar.cpp:529: (qdoc) warning: Can't link to 'registerCalendar()'
src/corelib/time/qcalendar.cpp:529: (qdoc) warning: Can't link to 'fromName()'
src/corelib/time/qcalendar.cpp:178: (qdoc) warning: Can't link to 'QCalendar::fromEnum()'
src/corelib/time/qcalendar.cpp:405: (qdoc) warning: Undocumented parameter 'jd' in QCalendarBackend::dayOfWeek()
src/corelib/time/qcalendar.cpp:405: (qdoc) warning: Can't link to 'weekDayName()'
src/corelib/time/qcalendar.cpp:405: (qdoc) warning: Can't link to 'standaloneWeekDayName()'
src/corelib/time/qcalendar.cpp:268: (qdoc) warning: Can't link to 'daysInMonth()'
src/corelib/time/qcalendar.cpp:268: (qdoc) warning: Can't link to 'isLeapYear()'
src/corelib/time/qcalendar.cpp:295: (qdoc) warning: Can't link to 'daysInMonth()'
src/corelib/time/qcalendar.cpp:313: (qdoc) warning: Can't link to 'isLuniSolar()'
src/corelib/time/qcalendar.cpp:313: (qdoc) warning: Can't link to 'isSolar()'
src/corelib/time/qcalendar.cpp:313: (qdoc) warning: Can't link to 'isLunar()'
src/corelib/time/qcalendar.cpp:340: (qdoc) warning: Can't link to 'daysInMonth()'
src/corelib/time/qcalendar.cpp:357: (qdoc) warning: Can't link to 'daysInMonth()'
src/corelib/time/qcalendar.cpp:544: (qdoc) warning: Can't link to 'fromName()'
Change-Id: Ia2fabefb917f8e4cfa361044d9b754717276f4aa
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
According to Windows docs, GetMessage() function retrieves the messages
from the input queue in defined order, where posted messages are
processed ahead of input messages, even if they were posted later.
Therefore, if the application produces a posted event permanently, as
a result of processing that event, user input messages may be blocked
due to hard CPU usage by the application.
It's not a problem, if an internal Qt event loop is running. By calling
sendPostedEvents() on the beginning of processEvents(), we are sending
posted events only once per iteration. However, during execution of
the foreign loop, we should artificially lower the priority of the
WM_QT_SENDPOSTEDEVENTS message in order to enable delivery of other
input messages.
To solve the problem, it is proposed to postpone the
WM_QT_SENDPOSTEDEVENTS message until the message queue becomes empty,
as it works for the internal loop.
Task-number: QTBUG-77464
Change-Id: I8dedb6837c6fc41aa6f497e67ab2352c2b4f3772
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The classes are there. There is no need for the extra #if-ery.
Change-Id: Ic92ff894d6c9d26dbe32ca83b9501fa8d07e3d44
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... except four instances in QCoreApplication that would conflict with
another change.
Replace a locally-defined MutexUnlocker with a call to unlock() +
qScopedGuard'ed lock() to avoid having to spell out the locker type
while we can't depend on C++17 CTAD, yet.
In QSettings, move the new mutex locker into and out of
initDefaultPaths(), such as is idiomatic for std::unique_lock, but
wasn't possible with QMutexLocker (which is not movable).
Change-Id: I23056e13ecaa76159db583c7dccc6e05715e0788
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is a follow-up to commit b7d073e990,
which refactored memory allocation of QMetaCallEvent.
Change-Id: I363256c80ee941b545e6f9c659c65556fff5c907
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Given that this is an exception, it doesn't invalidate the general
thread-safety of static meta objects, and putting a locking mechanism
into Qt for this would be complete over- (and performance-)kill.
Task-number: QTBUG-70915
Change-Id: I4a538b977f5c2e8173cb236023e5d9ca34add5b5
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
As exposed by tst_QObjectRace::destroyRace we would sometimes end up
with a double-free when destroying a QSlotObject in multi-threaded
scenarios. One free would be done in ~QObject as the receiver was being
destroyed while the other free was done when deleting a QMetaCallEvent
object after we realized it was not needed because the receiver was
destroyed.
Since we can be in a separate thread from the receiver we should lock
before referencing the connection object.
Amends b7d073e990.
Change-Id: Icb53862dc880ae9a4e5581a1a9ee693573f7d9c7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
features.animation and features.scroller depend on the feature.
In total, this saves around 180KB from QtCore and 75KB from QtWidgets.
Change-Id: I65aac3ec4d50d62424ee33f44b99f3cfb91121d6
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This saves one more function call in activate().
before after
string based connect: 2436 2380
pointer based connect: 3265 3160
not connected: 400 307
disconnected: 489 404
5 slots connected: 4515 4522
Change-Id: I4789c7400497c2aa08886ea964af5e5e4703eeab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
There are two cases:
In a BlockingQueuedConnection, QMetaCallEvent doesn't allocate memory
and instead passes already existing pointers through. A QSemaphore
is used to serialize data access between threads. So the constructor
taking a QSemaphore can be simplified to only accept an existing arg
array.
In a QueuedConnection, QMetaCallEvent needs to make deep copies of
the arguments, and memory needs to be allocated based on the number
of arguments. The previous code put the burden of memory allocation
on the code generating the event, while the memory was free'd by
~QMetaCallEvent. Instead, make it QMetaCallEvent's responsibility
to allocate and free the memory as needed, and adjust the code
generating QMetaCallEvents.
We can allocate the memory for types and pointers to arguments in a
single block, starting with the space for the array of void*, followed
by the space for the array of integers to avoid byte alignment issues.
By pre-allocating the space that's needed by three arguments, we can
avoid all mallocs for the majority of QMetaCallEvents.
Until this change has propagated through qt5.git, we need to keep the
old API that is still used by QtDeclarative around. Once QtDeclarative
has migrated to the new API, it can be removed.
Change-Id: Id7359ffc14897237ea9672dabae9ef199a821907
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
- add conditional noexcept to move special member functions
- use qExchange() in the move ctor implementation (turns a copy into a move)
- separate the default ctor from the ctor that acquires a resource, then
- overload the latter for rvalue payloads
Change-Id: I6816143a94fe6a74cf0d02569b83a752a8da3089
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(or forward-declare std types)
(with apologies to Mr Walter Brown)
This applies the changes to our other smart pointers that
a0c4b6f345 applied to QSharedPointer,
with the same rationale: wg21.link/p0551.
It also fixes a fwd declaration of std::function, including
<functional> instead. Rationale: wg21.link/p684r0.
Change-Id: If275af91f6eac15eb418b200ac7d08ba084a6130
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
From the comments on QTBUG-73407 and the last comments on
29bcbeab90, it seems like there are still
use-cases when QSignalMapper is useful.
Change-Id: I8402286cb8a395a4601cda8a4cdda51f19aef073
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use the standard tool instead of self-made stuff that cannot decide whether
it wants to be a scoped pointer (why take()?) or a movable one (why no move
special member functions?).
Take advantage of C++11 local structs for pulling the custom deleter into
the scope where its only user is located, too.
Change-Id: I7e097a59edef9adc8455504ae94b8df0f8b9e5d2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Current codebases assume isCompressed() implies ZlibCompression, since
there was no compressionAlgorithm() getter. In order to force codebases
to change, deprecate isCompressed() and force handling of the algorithm.
The replacement API is being introduced in 5.14, which is why the
warning is being emitted in 5.15 only.
Change-Id: Ief874765cd7b43798de3fffd15a9f5d978951ea5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Windows has a problem relating to cross-DLL variable relocations: they
are not supported. Since QMetaObject's link to the parent class is done
via a pointer, every QMetaObject in a DLL or in the EXE that derives
from a class from another DLL (such as QObject) will be dynamically
initialized.
This commit changes the meta object pointers in QMetaObject::d from raw
pointers to a wrapper class SuperData, which is almost entirely source-
compatible with the pointer itself. On all systems except for Windows
with Qt 6, it's binary compatible with the current implementation.
But for Windows with Qt 6, this commit will store both the raw pointer
and a pointer to a function that returns the QMetaObject, with one of
them non-null only. For all meta objects constructed by moc, we store
the function pointer, which allows the staticMetaObject to be statically
intialized. For dynamic meta objects (QMetaObjectBuilder, QtDBus, QtQml,
ActiveQt), we'll store the actual raw pointer.
[ChangeLog][QtCore][QMetaObject] Some internal members of the
QMetaObject class have changed types. Those members are not public API
and thus should not cause source incompatibilities.
The macro QT_NO_DATA_RELOCATION existed in Qt 4 but was called
Q_NO_DATA_RELOCATION and only applied to Symbian. It was removed in
commit 24a72c4efa ("qglobal: Remove
symbian specific features").
Task-number: QTBUG-38876
Fixes: QTBUG-69963
Change-Id: Id92f4a61915b49ddaee6fffd14ae1cf615525e92
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Clang warns that the private field semaphore_ is unused, and is correct,
of course.
Change-Id: Ic1372cedd3f4b2facca9f6f6be398d26f406b379
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
QLinkedList is still used in several tests. Add exceptions for
these subdirs.
Change-Id: I50ccd2a0892129d4a47aa4e2400211690da9a82d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
A declaration of fromStdVariant() was not visible to qdoc
because it was ifdef'ed out. This update ensures that qdoc
sees the declaration.
Change-Id: I4b00a895aa61175296ec80806b43311eff4f25ca
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
In all of these cases, the effect of the change is local to one file.
Change-Id: I3bda3aadee3b42e7797183c2330183390b92d1f2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Because it is. It's just QCoreApplication::postEvent(), which is thread-safe.
It also _has_ to be, because we recommend to use deleteLater() to delete
QObjects that live in another thread:
Quoting the ~QObject() docs:
> Warning: Deleting a QObject while pending events are waiting to be delivered
> can cause a crash. You must not delete the QObject directly if it exists in
> a different thread than the one currently executing. Use deleteLater()
> instead, which will cause the event loop to delete the object after all
> pending events have been delivered to it.
If deleteLater() is not thread-safe, it cannot be used for one of its intended
purposes.
Change-Id: I333d506b42bdfcdff00fe6cefa234c21865625a6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Since commit 6a7cea64 qt_GetMessageHook is effectively a no-op, and
we can remove the complete hook handling code.
Change-Id: I90383c0c09c2b0f1d715872de5f9519a879d9bae
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Casting an object to a subclass that is not the dynamic type of the
object constitutes undefined behavior.
Fix by befriending QObject.
Change-Id: Ib70dbef9095df31a6d89449d82a02cef9fccd348
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Simon Hausmann
Qt Forward Merge Bot
Marc Mutz
Kai Koehne
Alexandru Croitor
Liang Qi
Friedemann Kleint
Alex Trotsenko
Ulf Hermann
Volker Hilsheimer
Mårten Nordheim
Tasuku Suzuki
Lars Knoll
Sona Kurazyan
Tor Arne Vestbø
Thiago Macieira
Martin Smith
Mikhail Svetkin
Joerg Bornemann
Yulong Bai