| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A single global QT_REMOVED_SINCE will start hurting us once more
modules downstream of QtCore start using the mechanism.
With every use of feature, the set of code that needs to compile under
QT_BUILD_REMOVED_API increases. Since we use QT_REMOVED_SINCE in
situations where overloading the new and the old function don't work
in general, this means all code included by any removed_api.cpp needs
to be very carefully written to ensure that any calls to the overload
set formed by the combination of old and new function(s) don't create
ambiguities.
Likewise, the set of APIs that change semantics under
QT_BUILD_REMOVED_API also increases. At some point, the combination of
removed_api.cpp including almost every module header and almost every
header exposing source-incompatibilities when included in
removed_api.cpp will make maintenance a headache.
By making QT_REMOVED_SINCE and QT_BUILD_REMOVED_API per-module
(QT_CORE_REMOVED_SINCE, ...), easy now that we generate the export
macros using CMake, we limit the scope of this problem to the module
using the feature. Downstream modules (say, QtWidgets) will now see
the QtCore API like every other user, even in the
widgets/compat/removed_api.cpp TU.
Pick-to: 6.3
Change-Id: I177bc7bd5aa8791639f97946c98e4592d2c7f9d9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On 32-bit machines, qsizetype is int, so we don't actually need to
QT_REMOVE_SINCE the QByteArrayList_join() helper, because it didn't
change.
Thanks to Thiago for showing me the QT_POINTER_SIZE trick in a similar
change to QVersionNumber.
Pick-to: 6.3
Change-Id: Iae6e315107e42da51fcb4e7325b6d40b9c3fe0bc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Null- vs. emptiness of the separator is not significant for join(), so
skip the isNull() check in the conversion ctor of QByteArrayView from
QByteArray by using the named conversion function that exists for this
purpose instead.
Pick-to: 6.3
Change-Id: I6ef07cc9bcc0bc8b87ecadc5cfaac9793cfb1b77
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... instead of waiting for Qt 7.
Found in API review.
[ChangeLog][QtCore][Potentially Source-Incompatible Changes]
[QByteArrayList] The join() overload set has changed. Code such as
qOverload<>(&QByteArrayList::join) will have to be rewritten,
e.g. using lambdas. We advise against taking addresses of library
functions other than signals and slots.
Pick-to: 6.3
Change-Id: I67449df9adc2efea7f1163034caa135f31f39e7c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We forgot to adjust the interface and implementation of join() to the
int → qsizetype change in Qt 6.
This part of the two-part patch fixes things in a non-forwards-BC way,
so it can't be picked into released versions. The forwards-BC part is
in the first patch of the series.
We can't just replace the int seplen with qsizetype, because qsizetype
is an alias to int on 32-bit platforms. So, pass the separator by
QByteArrayView.
[ChangeLog][QtCore][QByteArrayList] Fixed a bug when calling join()
with separators of length > INTMAX.
Change-Id: I2ccc61de1c8901ac5504aea1ebd895d12dbcb064
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We forgot to adjust the interface and implementation of join() to the
int → qsizetype change in Qt 6.
This part of the two-part patch fixes things in a forwards-BC way, to
allow picking into released versions. The forwards-BC break is in the
second patch of the series.
[ChangeLog][QtCore][QByteArrayList] Fixed a bug when calling join() on
lists with more than INTMAX elements.
Pick-to: 6.2
Change-Id: I26976864e77169ff0db7c672d1d42d88dbfcc437
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since QByteArray/QByteArrayView don't overload nicely, we need to make
the existing QByteArray overload a Q_WEAK_OVERLOAD (= a template) as a
tie breaker. This automatically prefers the QByteArrayView version
over the QByteArray overload, transparently optimizing existing users
passing char string literals to avoid the implicit creation of a
QByteArray just for passing the separator.
None of our modules exports a subclass of QByteArrayList, so turning
join(QByteArray) into a function template should be ok.
[ChangeLog][QtCore][QByteArrayList] Added join(QByteArrayView)
overload.
Change-Id: I090671d9b94c30b63a986f17e966d124c22b5c54
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no reason why they shouldn't be; one might want to do a
lookup passing an object which is comparable with the list's value
type (e.g. search with a QByteArrayView needle into a QByteArrayList
haystack). Insofar we've had to add overloads to QListSpecialMethods
for all these cases, which clearly doesn't scale and creates
top-tier and low-tier lists.
There is one downside, namely, calling QList<A>::indexOf(B) for a B
for which there isn't an operator==(A, B) but only a conversion
towards A. Before, B was converted only once (at call site), now
it's converted at every call of operator==.
In general: such types are broken and should be fixed on their own.
However let's avoid a possible regression in client code, so I've
left the QString overloads in QStringList in.
To get there: centralize the implementation of those methods in a
empty base class, which gets then inherited by QListSpecialMethods,
which is inherited by QList. This is there are still special methods
that may want to overload contains, e.g. QStringList which also
passes a case sensitivity).
The only breakages comes from code that was already broken, for
instance mixing signed and unsigned types, and the beauty of this is
that now we *detect* that instead of silently ignoring.
QVLA and other QList methods will be tackled in future commits.
[ChangeLog][QtCore][QList] The indexOf, lastIndexOf and contains
methods now take an object of any datatype -- and not just the
list's own value type. This allows for heterogenous lookup in
QLists.
Change-Id: Ib34812217eb2b0f926fad1fc195b33758196941c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
| |
It was used as exported symbol for the implementation of
QByteArrayList::indexOf. Since then, the implementation has
been changed, and this code is unused.
Change-Id: I468d05507b6b520cf5bfa4bc567a3d67c43b9a32
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And name the main class QList. That's also the one we document.
This gives less porting pain for our users, and a lot less churn
in our API, as we use QList in Qt 5 in 95% of our API.
In addition, it gives more consistent naming with QStringList and
QByteArrayList and disambiguates QList vs QVector(2|3|4)D.
Fixes: QTBUG-84468
Change-Id: I3cba9d1d3179969d8bf9320b31be2230d021d1a9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
| |
Change-Id: I82feeb2c9bd2900f421fc0c8d78698b1e83db043
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Add QGenericArray to simplify operations. This class can be shared by
other tool classes. If there is nothing else to share it, we can move
the code onto qvector.h. The one candidate is QList.
All tests pass and valgrind is good.
Change-Id: Ieaa80709caf5f50520aa97312ab726396f5475eb
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend QVector with special methods for QByteArray and QString,
just as QList had them in Qt 5.
This also means that QStringList and QByteArrayList
are now implemented through a QVector, not a QList anymore.
QListIterator<QString> is now slightly source incompatible as QStringList
is a QVector, but that will be fixed in a follow-up change when
QList<QString> will start mapping to a QVector.
Change-Id: I7cfb8a72d4d95b347bbd386892f244b7203b41c2
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
This includes byte array, string, char, unicode, locale, collation and
regular expressions.
Change-Id: I8b125fa52c8c513eb57a0f1298b91910e5a0d786
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|