The lock() function, added for std::weak_ptr compatibility, sounds
like QMutex::lock(), but is, in fact, a const function. QUIP-0019 says
such functions must be marked [[nodiscard]]. For symmetry, also mark
toStrongRef() and toWeakRef() as [[nodiscard]].
Pick-to: 6.6 6.5
Change-Id: Ifb6e447d2cd96fedd9a78decdfac6bc57c1d282a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The following private APIs are either RAII or smart pointer classes:
- QAutoPointer
- QBoolBlocker
- QFdContainer
QUIP-0019 says to mark RAII and smart pointer class ctors
[[nodiscard]], so do that.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: Ibc77e6603fadf18ea28428a49635f46a5680b777
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
They both check __has_cpp_attribute(nodiscard), so keep them together.
Move the fall-back (empty) definition to the block that does the same
for all other such macros.
Mention that both P1771 ([[nodiscard]] for ctors) and P1301
([[nodiscard("reason")]]) use the same numerical value.
Amends 959800f6de.
Pick-to: 6.6
Change-Id: I0ef913b6076ffa4058220b542303591de6fefde7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It should be possible to build a test in any configuration
by building Qt in that configuration, and then building
the test with qt-standalone-test.
Not all Qt configurations will be able to run all tests,
(due to exec() calls and similar) but that's OK - some
tests don't have exec() calls, and we want to be able
to run tests for a given configuration to figure out
how well it works.
On CI we want to use batching and asyncify, so it makes
sense to tie usage of asyncify to batching.
Pick-to: 6.6
Change-Id: I05553d250a45c1831f43dc71a43ef02d01d70535
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
If the user is asking us to ignore it, don't set to the default
behavior.
Change-Id: Ib5ce7a497e034ebabb2cfffd17628562f745358d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
... into a new local class called QChildProcess. This groups all the
information that the child process will need between the fork()/vfork()
call and the eventual execve(). That currently includes:
- the argv array, including resolving the program name to a path
- the envp array, possibly a null
- the working directory file descriptor
- the disabled thread cancellation state
We also move the fork() and vfork() calls to inside of this class,
eliminating the the nested lambda was passed to vforkfd(). This
duplicates the trick of calling a lambda in the child side of vfork()
now for the non-file descriptor version too.
None of this should have a side effect for the application. You may be
able to tell apart only in system-call tracing tools like strace(1) or
truss(1).
Change-Id: Ib5ce7a497e034ebabb2cfffd176284edfdd71b32
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
And take the opportunity to clarify what the QtVforkSafe namespace is
doing. Amends commit e71c226d6f.
Pick-to: 6.6
Change-Id: I443cf0c8a76243eead33fffd1767f3fa390a7cdd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Found in API review.
Amends 959800f6de.
Pick-to: 6.6
Change-Id: I00877ce7030c638765b495089899c022deb31a27
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
QFutureSynchronizer is a RAII class. QUIP-0019 says that RAII class
ctors should be marked as [[nodiscard]].
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I0b6710f2b9a14d67f64150f240f819b8336e0929
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
When setFuture() was handed an element of m_futures, it would hold the
reference to past the clear(), which invalidates said reference.
Fix by taking the future by value instead of by cref.
While append() is not affected, as QList::append() already guards
against aliasing, do the same change there, both for consistency as
well as to optimize the common case of passing rvalues. It also means
we can use the rvalue overload of QList::append(), skipping the alias
analysis in the lvalue QList::append().
[ChangeLog][QtConcurrent][QFutureSynchronizer] Fixed a crash in
setFuture() if the argument was already a member of
QFutureSynchronizer::futures().
Pick-to: 6.6 6.5 6.2
Change-Id: Ic0b212b9f265a746df9a6beb6272a5415d131442
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Fixes QDoc warning: 'Documentation for class has no \inmodule command'
for both classes.
Pick-to: 6.6
Change-Id: I59eb5f5b935ea30f756d655158a06f390d2ebc54
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
A \target defines a global doc linking target across all Qt modules,
and they may interfere with link targets local to module documentation.
As we no longer link as heavily to qmake manual after moving to CMake,
remove the \target commands. The section titles remain as valid link
targets; arguably, duplicating a \section1 title with an identical
\target name was unnecessary in any case.
Replace all \l command arguments that used the \target for linking
with the actual section title.
Pick-to: 6.6 6.5
Fixes: QTBUG-114073
Change-Id: I6e595a77268cbd6ddb5d004501bc6df178c3883d
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Of course we managed to rely on a GLSL feature that is only
in GLSL 130 and newer, not 120 which is what the default 2.1 OpenGL
contexts support on macOS.
Change-Id: Ib75e750ea15d59e51b2207669068fba7719a48b1
Pick-to: 6.6
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
... and make it a hidden friend.
This avoids ODR violations when, because they can't use ours (private,
and not exported), users try to produce their own version of
qHash(Key).
[ChangeLog][QtGui][QPixmapCache] Made the qHash() overload for
QPixmapCache::Key public (was: private) API.
Pick-to: 6.6
Change-Id: I324ed001c0ae0a251ac2e1d04713013452ffff9c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Just de-inline the original function instead of merely moving its
implementation into an out-of-line function.
Amends 408fbd3f2d.
Pick-to: 6.6
Change-Id: I6860a10e0a7d876ce1837f196b1fb4165779540a
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
... to hold the optional QApplication.
Saves a memory allocation, and is more readable.
Amends 408fbd3f2d.
Pick-to: 6.6
Change-Id: I390b9cfa367d01feb59bb5deadc5383c8e678749
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
... instead of %s and qPrintable()
Less operations, less code expansion.
Amends 408fbd3f2d.
Pick-to: 6.6
Change-Id: I5a3d2e79623bd32c348a2d655e3a2c8d98eca1e3
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This is not scalable. Instead of putting parts of post-1.0 vulkan_core.h
into this header, apply the appropriate ifdefs instead.
Pick-to: 6.6
Change-Id: I21a9d6f7c51169efa7b66705545bae192ed30c14
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Just in case someone includes the private headers outside of Qt.
Pick-to: 6.6
Change-Id: I79232d2bab7604c71c31226a67ec3ef40210d161
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Without this patch, the compiler will complain about can't find
"qshaderdescription.h" when using "qrhigles2_p.h" from outside of
Qt, which breaks user project compilation.
Pick-to: 6.6
Change-Id: I9e201d82890c92ddd2f6aad48eef0edc9a7c46ef
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The existing implementation as a member function QDALI::op<<(QDebug)
cannot possibly work, as the implicit `this` argument comes first in
this case, while for streaming operators, the QDebug object must come
first.
Rewrite as a hidden friend and apply QT_NO_DEBUG_STREAM protection as
a drive-by.
Amends faec937756.
Task-number: QTBUG-114542
Task-number: QTBUG-112491
Pick-to: 6.6 6.5
Change-Id: Ida400d335491896ec49f2c0f9601a8430eebcd4d
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
They're RAII/smart pointer-like classes. QUIP-0019 says such classes'
ctors should be marked [[nodiscard]].
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I830badfa56fbdfb5819866f67b84cd4fa93acbde
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QWidgetPrivate::focusObject() always returns nullptr. That has lead to
mismatches between QGuiApplication::focusObject() and
QApplication::focusWidget(), when a widget got focus by the window
system (e.g. mouse click).
This patch implements QWidgetPrivate::focusObject.
It returns the current widget, if it doesn't have a focus proxy.
If it has a focus proxy, it resolves the proxy chain and returns the
deepest focus proxy.
(Note: It does not return QWidget::focusWidget(), because the focus
widget might not yet have been set, when the method is called).
Fixes: QTBUG-92464
Fixes: QTBUG-108522
Pick-to: 6.6 6.5 6.2
Done-With: Liang Qi <liang.qi@qt.io>
Change-Id: Icf01e8ac4fc5f722fbf8e0ca5a562617ae9ae8f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
QSqlResult::boundValues is a const member function, but returned a non-
const reference to a QList<QVariant>. This is a bad and potentially
dangerous API, as callers can modify the list stored in QSqlResult.
Move that API into the removed_api translation unit, remove it from
Qt 6.6 on and replace it with two suitable overloads where the const
version returns a QVariantList by value, and the non-const overload
returns a mutable reference.
Driver implementations that used to call the const overload to get a
mutable reference are now calling the non-const overload instead
(those calls are all made in the non-const exec() or equivalent driver
implementations).
As a drive-by, replace "vector" with "list" in the documentation.
Pick-to: 6.6
Change-Id: I6e4fd8f5749b939cdb609bf5876735e9b30b2b5a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Code points is what you get when surrogate pairs have been joined
Pick-to: 6.6 6.5 6.2
Change-Id: I86c4131de5782ce1e6342217947a603ca16bb521
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use the new argument to bundle the OpenSSL prebuilt libararies so that
ssl operations are actually tested at runtime.
Task-number: QTBUG-110025
Pick-to: 6.6 6.5
Change-Id: I0d73fed463a1724a9e0ee84ba603aa2ff1bc649b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The new argument would allow bundling the prebuilt OpenSSL libs
into the test apk so that SSL can actually run. It expects the CMake
argument OPENSSL_ROOT_DIR to be set ( we set that in Coin configs).
Task-number: QTBUG-110025
Pick-to: 6.6 6.5
Change-Id: I4c82796635ca89f5511255ae26182f41a504b026
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is in line with how QMetaType handles QMetaTypeInterface*. You can
retrieve a const pointer to it.
Pick-to: 6.6
Task-number: QTBUG-113690
Change-Id: Iaf3c10603dc6049a5553987c90006807867abc0d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Prior to 30276cec3d all the recognizers
were managed together, so we could safely condition teardown of them
all by checking for the presence of one of them.
Now that we selectively enable only some of the recognizers, we need
to have more granular teardown logic. For extra safety, we tear down
each one individually now, even if some of them are still managed
together.
Pick-to: 6.5 6.6
Fixes: QTBUG-114416
Change-Id: Ie99388cd8abb7543c17df5b6b5a88e86ff86df7e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
Our logic in the edit menu tap recognizer for determining whether the
tap should trigger the edit menu only looks at the bounds of the input
area, and as long as the tap is within these bounds we trigger the edit
menu.
This doesn't take into account that there might be controls laid on top
of the input area, for example a button, where we don't want to trigger
the gesture.
The only related logic we have is a heuristic that checks whether the
cursor ends up moving as a result of the initial press, in which case
we treat it as the edit area "accepting" the touch press.
The proper fix to this is to handle the gesture recognizer delegate
callback gestureRecognizer:shouldReceiveTouch:, and do hit testing
there, but we don't have any machinery for that in our IM protocol,
nor in QWSI.
As a workaround, we treat the gesture recognizer as having failed,
even when we do detect a tap that should open the menu, so that the
recognizer doesn't eat the touch event. We then open the menu manually
instead of relying on the gesture recognizer changing state. This
should be safe, as sending a touch/mouse event down to the input
area should normally be a noop.
The workaround does result in a slight visual wart when clicking
buttons that live inside input areas, as the edit menu temporarily
opens, but the menu is quickly hidden again as the focus object is
transferred to the button. Compared to the current situation, where
the button is visually pressed, but doesn't do anything, and we
bring up the edit menu fully, this is an improvement, even with
the wart.
Note that the original problem outlined in this changed is not an
issue in practice for Qt Widgets, as we synthesize mouse events
from touch events, and (wrongly) synthesize a mouse release in
response to the touch cancel triggered by the gesture recognizer,
so the button is still activated.
Fixes: QTBUG-113975
Pick-to: 6.5 6.6
Change-Id: I41e850f20d69ad8e3247949644a389e1c61c4dcf
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
ACE-encode the domain names, replace dashes with underscores,
prepend underscore to domain name parts that start with a digit.
Add a regression test into tst_qdbusinterface.
Fixes: QTBUG-71674
Change-Id: I92e0c6889163c0eccc4c833f2058d759631f562c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Or old and new load hints in mergeLoadHints() instead of just storing
new ones. Andjust QLibraryPrivate::setLoadHints() to handle objects
with no file name differently and just set load hints directly.
Mention that load hints are merged once the file name is set
in the documentation for QLibrary::setLoadHints().
Add a regression test into tst_qfactoryloader.
Update and extend tst_QPluginLoader::loadHints() to take into account
load hints merging.
Fixes: QTBUG-114480
Change-Id: I3b9afaec7acde1f5ff992d913f8d7217392c7e00
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The code is commented out since 12 years ago.
Change-Id: I5cd7380f8f1e778ea62b510aeece1aced111d662
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's not a real leak in that the string data is being freed on program
exit (or, more recently, QPixmapCache::clear()), but it can lead to
lots of memory being bound for much longer than expected when users
put in new QString keys without attempting to retrive them again. It
can also lead to problems with QStringLiterals lingering around until
after their underlying data has been freed. A bug in the Fusion style,
generating new string keys for identical state, exposed this
misbehavior, and one way to fix the resulting issue for the user is to
make sure that QPixmapCache doesn't leak QString keys.
The Fusion style issue with generating non-repeating keys for use with
QPixmapCache should also be fixed, eventually, but this patch
relegates that to an optimization issue (the caching is effectively
non-existent), the resource exhaustion is gone now.
The issue exists because the QString keys are internally mapped to
QPixmapCache::Key's by way of a QHash<QString, Key> cacheKeys data
structure. When the QCache, indexed by Key, not QString, decides to
evict an entry, the Key is invalidated, but no-one was removing the
corresponding entry from cacheKeys. So make the existing releaseKey(),
used to invalidate copies of Keys referring to evicted pixmaps, do
that, now. So as not to have to scan the whole cacheKeys QHash for the
right Key, store the QString key, if any, inside the Key, so
releaseKey() can retrieve it and use it for O(1) erasure from
cacheKey.
This allows removing the previous work-around in clear()
(6ab0d25a09), greatly simplify
object(QString), and requires to rewrite all code that holds iterators
or references into cacheKeys over an insertion into or removal from
the QCache. Two (insert() and remove()) have already been done in
prequel commits, so only flushDetachedPixmaps() was left.
Fixes: QTBUG-112200
Pick-to: 6.6 6.5
Change-Id: Ic93b0ed388ae963267fe242b491c6c941d146b99
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Implement insert(QString, QPixmap) in terms of insert(QPixmap) to
avoid duplicating code and to separate concerns: insert(QString,
QPixmap) is now only dealing with the cacheKeys, insert(QPixmap) is
only concerned with the Key-based lookup.
Task-number: QTBUG-112200
Pick-to: 6.6 6.5 6.2
Change-Id: I30394da43a5e93b7bd41ef9ce9c7aea044523c30
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The previous code used `cacheKey` as the name of an iterator, which
made the code hard to understand.
Instead of renaming that to the more idiomatic `it`, use QHash::take()
to get an actual `cacheKey` back, and then delegate to
QPMCache::remove(QPixmapCache::Key) for the actual removal.
Pick-to: 6.6 6.5 6.2
Task-number: QTBUG-112200
Change-Id: I9311c19f12a05cad694702672f17ae19ba339b04
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's a RAII class, and RAII classes should have only [[nodiscard]]
constructors.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: Ia83fa003677a839734208b12bde2c6287c1b79a3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
They're RAII classes, and QUIP-0019 says RAII class' constructors
should be marked [[nodiscard]].
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I0080f5b6a3cea346c0860e00958a8c204849040e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We should not export non-polymorphic classes wholesale. Only export
the non-inline functions instead.
There are no implicitly-declared special member functions in this
class that could cause problems, so we don't need to delay until Qt 7.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I2e98782160cccb9c0f59a68e67ffd29fec42b728
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Amends 55fe46fd58. Before that change,
key release events were ignored as the QLineEdit::event reimplementation
continued to call QWidget::event, and as QLineEdit didn't override
keyReleaseEvent, the default implementation in QWidget got called to
ignore the event.
Restore that behavior by explicitly calling the QWidget implementation
after updating QLineEdit-specific states, and add a test case.
Fixes: QTBUG-114654
Pick-to: 6.5 6.6
Change-Id: Ic8aa35a1c915b446aece47aaf03ef5cf1884b936
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
A number of users have explored the behavior and complained about it.
Lets add a \note explaining this. The function in charge is
QThreadPool::stealAndRunRunnable(QRunnable *), which is a private
function, exclusively used by:
QFutureInterfaceBase::waitForResult()
QFutureInterfaceBase::waitForFinished()
also update the documentation to reflect these changes accordingly.
Fixes: QTBUG-112351
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I839858cb449063d8af9bef64d2f35a6816a419b0
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Previously, failure handlers did not propagate cancellation. This would
lead to crashes when a QPromise was cancelled without having generated
any result. Subsequent continuations would be invoked and try to access
the result (which was nonexistent) and then crash.
This patch propagates cancellation through failure handlers to prevent
subsequent continuations from being called in the first place.
Fixes: QTBUG-114606
Pick-to: 6.6
Pick-to: 6.5
Change-Id: I23b28a8e70a76e1ba6416be4440360c6dbaef2a3
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The export name is now ${TARGET_NAME}Entry. This can also be overridden
by using QT_WASM_EXPORT_NAME, both in CMake and qmake
Change-Id: I59c97ae6e22f0b2720716e9d7eff7b6b13d37ab5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
