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>
Instead of having that function load those from memory. This allows us
to pass constant expressions in QVariant::Private s constructor
Change-Id: I3859764fed084846bcb0fffd17045ddd62553710
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Even though it's calling a noexcept(false) constructor, we can declare
when it it won't throw and allow the caller to suppress its own
exception handling.
This necessitated splitting the Q_DECLARE_SHARED into its components
because fromValue<QVariant> uses QTypeInfo<QVariant>::isRelocatable.
Change-Id: I3859764fed084846bcb0fffd1704503aa4d3e535
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Group them by noexceptness and then organize each group logically. We
also don't need to #ifdef the constructors for the unavailable classes,
as they are forward-declared.
Change-Id: I6f936da6f6e84d649f70fffd17060903c78edf0f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
All of those are implicitly-shared Qt data types whose copy constructors
can't throw and have wide contracts (there aren't even any assertions
for validity in any of them). These are all types with a QVariant
implicit constructor, except for QCborValue, which is updated on this
list so QJsonValue (which has a QVariant constructor) is also
legitimately noexcept.
To ensure we haven't made a mistake, the Private constructor checks
again.
Change-Id: I3859764fed084846bcb0fffd17044d8319a45e1f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Commit 2f0a625fd4 added noexcept for
these, but didn't verify that the operation itself was noexcept. And it
wasn't on 32-bit systems, because sizeof(void *) is only 4 bytes, making
QVariant and QVariant::Private a mere 12 bytes. That's insufficient for
QUuid and for almost all geometric types when qreal==double.
We can't use sizeof() in qvariant.h because most of those classes are
only forward-declared.
Change-Id: I6f936da6f6e84d649f70fffd1705ce948891d06a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
customConstruct has to do an additional check to ensure that
QVariant::fromValue(nullptr) returns null.
We can get rid of it by special casing nullptr_t in a fromValue overload
instead, reducing the amount of work that needs to happen at runtime.
Change-Id: I2aea6aecfee0a9404cbd78dbea01a1d5d3047ca0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QHash, QString, QByteArray, and QDateTime are explicitly noexcept, while
QList, QMap, and QModelIndex are implicitly noexcept because all their
members are explicitly nothrow-copyable.
There are a couple more Qt types that ought to be nothrow-copyable too,
like QBitArray and QUrl.
Change-Id: I3859764fed084846bcb0fffd17044b5ebb046ee9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Make them all noexcept and ensure they are all passed by value.
Unfortunately for QRectF and QLineF, they're too big when qreal==double,
so QVariant needs to allocate memory itself. Strictly speaking, they're
too big for passing by value too, but the codegen is identical, so we
may as well. For Qt 7, enlarging QVariant::Private would be a good idea.
Change-Id: I3859764fed084846bcb0fffd17044ac379b3c1d2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@gmail.com>
With very minor code style fixes. Moved up so they can be used in some
methods below.
Change-Id: I3859764fed084846bcb0fffd17044f8e61886e2c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
They don't need to be in the header. They're still inline though.
Change-Id: I3859764fed084846bcb0fffd17044f49031feefc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
And move it into the .cpp file, to hide the ugliness.
Change-Id: I3859764fed084846bcb0fffd17044729e361a42e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It's effectively the same and no one is using v_construct().
Change-Id: I3859764fed084846bcb0fffd1704470801c9e6e7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
They're ALWAYS const objects, though they also chock full of relocations
so they are never in read-only sections of memory (except maybe in final
executables that are position-dependent).
These are methods in a private sub-class of QVariant. No one outside of
QtCore (at least qtbase) should be using them directly. QVariant doesn't
have many friends (a bit anti-social); the one that matters is
qvariant_cast and that one does access QVariant::Private. This is not a
BC problem because QVariant::Private::type()'s signature is not
changing. In any case, QVariant's Q_CORE_EXPORT does not apply to
QVariant::Private anyway (see [1]).
[1] https://msvc.godbolt.org/z/r9cer8eWh
Pick-to: 6.3 6.4
Change-Id: I3859764fed084846bcb0fffd17035355f823dc8f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
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>
The QVariant(bool) is an extremely dangerous catch-all for all sorts of
things that may convert to bool, including arbitrary pointers. Delete
the corresponding constructor, in order to force users to use the
(correct) construction using fromValue, and/or to prevent bugs
altogether. This is technically speaking a SiC, but one of type A -- if
pointer to bool was intented, just do the conversion explicitly.
[ChangeLog][QtCore][QVariant] QVariant used to be constructible by raw
pointers through a conversion towards bool. This is now illegal. If such
a conversion is needed, users are advised to insert manual casts to
bool.
Change-Id: I1b1f81962259514e57d841246740e0f7050104e0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Forward declare more types in qvariant.h, and do the same for qdebug.h
(which will be removed from qvariant in a separate patch).
As we now only forward declare containers (e.g. QMap, QList, ...), code
which includes <QVariantMap>, <QVariantList>... breaks without further
adjustment: So far, those headers simply included qvariant.h. However,
by introducing new actual headers for those types and adjusting
sync.profile, we can avoid this issue.
To avoid breaking leaf modules and user code, we make the change opt-in:
Unless QT_LEAN_HEADERS is defined to a value of >= 1, we still
include the superfluous headers. We also set this macro in qtbase via
QT_EXTRA_INTERNAL_TARGET_DEFINES.
[ChangeLog][Potentially Source-Incompatible Changes] qvariant.h no
longer includes <QList>, <QMap>, <QHash>, <QVarLengthArray>, <QSet> and
<QObject>. Code that relied on transitive includes might need to
explicitly include those headers now. Notably, including <QVariant> (or
qvariant.h) is no longer sufficient when using QVariant(List|Map|Hash).
Using them now requires including respectively <QVariantList>,
<QVariantMap>, or <QVariantHash>. Alternatively, including <QVariant>
and the <QList>, <QMap> or <QHash> header also works.
[ChangeLog][Potentially Source-Incompatible Changes] qdebug.h no longer
includes <QSet>, <QHash>, <QVarLengthArray> and <QMap>. Code that relied
on transitive includes might need to explicitly include those headers
now.
Task-number: QTBUG-97601
Change-Id: I142e5de709ed0b305716369a3266389ab7fbbb71
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This header is a C++17 feature that is already used unconditionally
in qtypeinfo.h.
Change-Id: I26330d298e95102f3e94c0c69fc95c1025666eb4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Qt requires a compiler that support C++17 thus __cplusplus
is always 201703L or higher. This patch removes checks
for __cplusplus value that always succeed.
Change-Id: I4b830683ecefab8f913d8b09604086d53209d2e3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There is no reason for QVariant to go through QMetaType when it can use
the QMetaTypeInterface directly. Without LTO, the QMetaType method calls
are opaque, and we therefore risk to lose optimizations.
Additionally, avoid constructing a QMetaType from a type id if we
already have the QMetaType.
Fixes: QTBUG-90673
Change-Id: I7069ff6aff70d5baecdf5cf5760014c3dda81784
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In Qt 5, QVariant::fromValue<T> would not compile unless
Q_DECLARE_METATYPE(T) was used, and Q_DECLARE_METATYPE(T) would lead to
a compile error if T were not copy constructible.
In Qt 6, we do not require Q_DECLARE_METATYPE before using fromValue,
and QMetaType itself works with non-copy constructible types just fine.
However, QVariant still requires it, thus we need to now enforce this in
fromValue itself.
Change-Id: Ib6964a438d8c46033dd3a037b9d871de2b42e175
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
std::optional<int> is the wrong datatype to use for compare.
First and foremost, it can't be used in the idiomatic form of
auto r = a.compare(b);
if (r < 0) ~~~ // a is less than b
if (r > 0) ~~~ // a is greater than b
which we *already* feature in Qt (QString, QByteArray).
Also, std::optional<int> (explicitly) converts to bool, which is
a trap, because the result of the comparison can be accidentally
tested as a bool:
if (a.compare(b)) ~~~ // oops! does NOT mean a<b
Not to mention extending this to algorithms:
auto lessThan = [](QVariant a, QVariant b) { return a.compare(b); }; // oops!
std::ranges::sort(vectorOfVariants, lessThan);
which thankfully doesn't compile as is -- std::optional has
an *explicit* operator bool, and the Compare concept requires an
implicit conversion. However, the error the user is going to face
will be "cannot convert to bool because the operator is explicit",
which is deceiving because the fix is NOT supposed to be:
auto lessThan = [](QVariant a, QVariant b) { return (bool)a.compare(b); }; // big oops!
Instead: backport to Qt the required subset of C++20's <compare>
API, and use that. This commits just adds the necessary parts
for compare() (i.e. partial ordering), the rest of <compare>
(classes, functions, conversions) can be added to 6.1.
Change-Id: I2b5522da47854da39f79993e1207fad033786f00
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 3e59c97c3453926fc66479d9ceca03901df55f90)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It's been obsolete for a long time already. Make sure
the compiler now warns about it and remove all remaining
uses in qtbase.
Change-Id: I0ff80311184dba52d2ba5f4e2fabe0d47fdc59d7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This mostly reverts change 76e8e8e9c8.
The reason is that storing non relocatable types inline in
QVariants storage would implicitly make QVariant non relocatable.
Fixes: QTBUG-87686
Change-Id: I2a09b1dcdd907d60085dccf17f987086dcba878c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The high-level iterable interfaces should coerce the types of most
QVariants passed to the expected ones. To do this, move the type
coercion code into qvariant.{h|cpp} so that it is available to the
QVariantRef specializations.
The exception are variants passed to the find() functions of associative
iterables. Here, we should not coerce values we cannot convert to the
default-constructed keys. Instead we return end() in such cases.
Fixes: QTBUG-87687
Change-Id: I0bd4e5c4e4e270dd3bf36cb3fb115794828077f2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The only thing we need to modify at runtime is the typeId and that can
be mutable. This way we can have a constexpr ctor for QMetaType which
hopefully makes the importing and exporting of related symbols less
fickle.
On Windows we cannot make QMetaTypeForType constexpr as that leads to
mysterious errors in other places. Until we figure out why that is, we
just leave this class as non-constexpr.
This reveals that qcoreapplication.h and qvariant.h are using QDebug
without including it. We now get template instantiation errors. Include
qdebug.h to avoid that.
Change-Id: If1bf0437ada52459c59c6fa45bab3d22dfb0bc92
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This commit restricts operator<<(QDebug lhs, QVariant rhs) to only work
if rhs is actually of type QVariant (instead of any type convertible to
QVariant). This is especially important as
a) we check in QMetaType whether (slightly simplified) QDebug{} <<
std::declval<T>() is valid, and if so, register a function which
simply uses the operator.
b) In QVariant, we ask the metatype system for the contained types
registered debug function and then use it.
If a type now does not have its own operator<< for QDebug, but is
implicitly convertible to QVariant containing itself, this would lead to
an infinite recursion, when trying to use qDebug with that type. The
registered function in a) would just convert the type to QVariant, and
then ask the QVariant to print itself.
Disallowing implicit conversions in qDebug in general was considered
(i.e. adding template<typename T> operator<<(T) = delete in QDebug ),
but discarded as it breaks too much code relying on conversions.
Fixes: QTBUG-87122
Change-Id: Ib709297670cbc6cc307efd0dfd8e5b0279df9414
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Currently
A a;
QVariant::fromValue(&a).value<const A*>() == nullptr;
Still casting non const to const is safe, and worked in Qt5.
After this change
A a;
QVariant::fromValue(&a).value<const A*>() == &a;
Change-Id: I257049d084c712b00a338a2943d379aa478e0981
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The code was designed to avoid implicit casts when none of the two
types was a QVariant in C++98 times. This can nowadays be achieved
in a better way by making the operators hidden friends of QVariant.
Change-Id: I836b44027fc4ed2bfec401e94d41bddf865c431d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
At the moment we have two main strategies for dealing with move
assignment in Qt:
1) move-and-swap, used by "containers" (in the broad sense): containers,
but also smart pointers and similar classes that can hold user-defined
types;
2) pure swap, used by containers that hold only memory (e.g. QString,
QByteArray, ...) as well as most implicitly shared datatypes.
Given the fact that a move assignment operator's code is just
boilerplate (whether it's move-and-swap or pure swap), provide two
_strictly internal_ macros to help write them, and apply the macros
across corelib and gui, porting away from the hand-rolled
implementations.
The rule of thumb when porting to the new macros is:
* Try to stick to the existing code behavior, unless broken
* if changing, then follow this checklist:
* if the class does not have a move constructor => pure swap
(but consider ADDING a move constructor, if possible!)
* if the class does have a move constructor, try to follow the
criteria above, namely:
* if the class holds only memory, pure swap;
* if the class may hold anything else but memory (file handles,
etc.), then move and swap.
Noteworthy details:
* some operators planned to be removed in Qt 6 were not ported;
* as drive-by, some move constructors were simplified to be using
qExchange(); others were outright broken and got fixed;
* some contained some more interesting code and were not touched.
Change-Id: Idaab3489247dcbabb6df3fa1e5286b69e1d372e9
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Add a method that allows comparing two variants. The method returns
a std::optional, as comparing two variants of different type is not
meaningful, or the types could not be comparable.
Change-Id: If4ae838d671e051dda1b474f25a2f9dcf85dc265
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In order to modify a container through an iterable, we need the original
container to be mutable. The iterable, then, is not a conversion of the
container, but rather a view on the container. The concept may be
extended to other types.
In order to facilitate this, provide a set of methods in QMetaType and
QVariant similar to the convert family. The new methods are non-const
and expect the original value to stay available during the life time of
the view.
Change-Id: I363621033f7fc600edcea2acb786820ccba49c86
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
And add mutable iterators. This requires some refactoring of the
existing iterators.
Task-number: QTBUG-81716
Change-Id: I61b3a3e8c0df5fd449679257a29d9f0c3d19c4f0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Fix our API, so that QStringList and QList<QString> are the
same thing.
This required a bit of refactoring in QList and moving the
indexOf(), lastIndexOf() and contains() method into
QListSpecialMethods. In addition, we need to ensure that
the QStringList(const QString&) constructor is still available
for compatibility with Qt 5.
Once those two are done, all methods in QStringList can be moved
into QListSpecialMethods<QString>.
Change-Id: Ib8afbf5b6d9df4d0d47051252233506f62335fa3
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We want a suitable alignment to hold a double even on
32bit systems.
Change-Id: I35145ded9320c147d4fcd7a04c4b3630912cc00a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Nodir Temirkhodjaev <nodir.temir@gmail.com>
This was causing miscompilations with clang on macOS. As it's
not really required, remove the alignment requirement.
Change-Id: Iacef1af7f51990daddc73fe74449adc1a823aa33
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Luca Di Sera
Thiago Macieira
Fabian Kosmale
Lucie Gérard
Sona Kurazyan
Giuseppe D'Angelo
Jonas Kvinge
Ievgenii Meshcheriakov
Ulf Hermann
Volker Hilsheimer
David Skoland
Allan Sandfeld Jensen
Lars Knoll
Fawzi Mohamed
Edward Welbourne