We have now had several requests for inlining previously-exported
member functions, but no standard mechanism to effect it.
As QT_REMOVED_SINCE has shown, there is great value in having such a
standard mechanism, so here is one.
With this change, to inline a previously exported (member) function,
simply
- mark the declaration with QT_<MODULE>_INLINE_SINCE
- move the definition into the header file (outside the class),
- wrap it in QT_<MODULE>_INLINE_IMPL_SINCE
- #include the header into the module's removed_api.cpp
Just including the header into removed_api.cpp is enough, so you may
want to add a comment:
#include "header.h" // uses QT_<MODULE>_INLINE_SINCE
The effect is as follows:
- A TU in a _different_ library will see an inline declaration,
followed by the definition, and so it will see a normal inline
function.
- A TU in the same library will, however, see a non-inline
declaration, to avoid the ODR violation that at least GCC/ld are
able to detect.
- When QT_<MODULE>_BUILD_REMOVED_API is in effect, the TU will also
see the definition, which is the same setup as before the change,
except in a different TU, and therefore export the member.
- When, OTOH, QT_<MODULE>_BUILD_REMOVED_API is _not_ in effect, the
TU will see no declaration, assuming (correctly), that the
definition will be supplied by a different TU.
This is, of course, an ODR violation, but not worse than what we do
elsewhere, as the definitions differ only between library and user.
The function is inline only for the users of the library, not the
library itself, which will still see the function as non-inline. If
inlining is critical within the library, too, the existing function
should call a new inline function, and calls in the same library should
be changed to call the new inline function instead.
Use the new mechanism to inline the QLocale ctor we intended to inline
for 6.3, but couldn't, because we hadn't found the magic incantation,
yet. Thiago found it a few weeks later, and this is what this patch is
based on.
Fixes: QTBUG-100452
Pick-to: 6.4
Change-Id: Ia0030cddc64b6b92edfed860170d5204aa74b953
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The QBAV one should pass the parameter by value, like QStringView. And
now that we have it, the non-View one should call the View one in an
inline function, like we already do for QString.
The extra, defaulted parameter is there only so we get a different
signature in the new inline function compared to the removed one.
Pick-to: 6.4
Change-Id: If05aeeb7176e4f13af9afffd16e7f08062b1dc86
Reviewed-by: Marc Mutz <marc.mutz@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>
With the public interface ported to QAnyStringView, we can now
internally optimize memory allocations _in a central place_ (e.g. by
returning std::u16string or QVarLengthArray<QChar> from normalizeKey()
instead of QString). But first we needed to get rid of all the
unwarranted allocations in user code.
Effects on Linux AMD64 stripped C++20 release builds:
GCC 11.2 libstdc++ (TEXT -= 6.5%):
text data bss dec hex filename
635148 10992 2824 648964 9e704 tst_qsettings-01-baseline
593691 10992 2824 607507 94513 tst_qsettings-02-qanystringview
Clang 10.0.0 libc++ (TEXT -= 11.6%(!)):
text data bss dec hex filename
790336 10640 2832 803808 c43e0 tst_qsettings-01-baseline
698572 10640 2832 712044 add6c tst_qsettings-02-qanystringview
That's the beauty of QAnyStringView: transparently reducing temporary
QString creation; and the simplest code is also the most efficient.
[ChangeLog][QtCore][QSettings] Keys can now be passed as
QAnyStringView (was: QString). The most efficient way to pass literal
keys is now "key"_L1, the backwards-compatible way is
QStringLiteral("key").
Fixes: QTBUG-101390
Change-Id: I510fb4ce17ef109dac7c9cdc5d90ede0d1a9db5f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
... while keeping the QString overload for users that pass actual
QStrings (e.g. QStringLiteral).
However, QString and QAnyStringView cannot be overloaded (they're
ambiguous for most arguments), so we need to make one of them a
Q_WEAK_OVERLOAD.
Normally, we'd make the new function weak and keep the old function
as-is, but, here, that would be beside the point, because all callers
would continue to resolve to the QString overload, and nothing would
call the QAnyStringView one.
So we really want the old function to be the Q_WEAK_OVERLOAD, so that
the QString overload is only selected when actual QStrings are
passed. That means we need to leave the old function in a compat build
(compiled in, but not visible in the public header). Since
Q_WEAK_OVERLOADs cannot be (easily) exported (they're templates), make
it call a private function (which can be, and is, exported).
Reviewers may questions whether one can overload
setObjectName() and
template <typename = void> setObjectName()
The answer is that we can, because templates mangle differently from
normal functions. We can even call the template function (with
explicit template arguments), as seen in removed_api.cpp.
This adapts the interface of the function to how most users use it:
They pass QLatin1String or just const char[]. Only very few passed
QStringLiteral, which, ignoring that fact that it produces a ton of
code for the temporary QString's destructor that's never executed,
would have been, and continues to be, the optimal way of passing data,
modulo plugin bugs (QTBUG-51602, QTBUG-49061).
[ChangeLog][QtCore][QObject] Added setObjectName() overload taking
QAnyStringView.
Fixes: QTBUG-101393
Change-Id: I1243545614754b4978d4c8641460980b6b293c1a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Remove the member function from the API and re-add it as a hidden
friend on qfloat16, where it will be a complete type.
[ChangeLog][QtCore][Potentially Souce-Incompatible Changes] The
qfloat16 QDataStream operators are now hidden friends and only found
by argument-dependent lookup. Previously, these were member functions
on QDataStream.
Fixes: QTBUG-93499
Pick-to: 6.3
Change-Id: Ib3d4df7a3fe3a9d0938f3be8b70b50fef0416262
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Use Q_CORE_REMOVED_SINCE macro for fromAce()/toAce() API changes.
Pick-to: 6.3
Change-Id: I057c6d648c2141929f04e4b4c4a38ba3275261ab
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Use Q_CORE_REMOVED_SINCE macro for languageToCode()/codeToLanguage()
API changes.
Pick-to: 6.3
Change-Id: I8cc5279b1272165541c345241af49523c0f25737
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@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>
The backend was already ported, so this is just about applying
QT_REMOVED_SINCE and updating the docs.
Change-Id: I2c78908deb9cdb3cee19ce8bc148ab3117c1ad9a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
From the API review.
Pick-to: 6.3
Change-Id: I9877990f75189b99a372ea6342d07a7031228ac7
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Unlike QString and QStringView, QByteArrayView and QByteArray don't
overload well.
Solve the overload issue the usual way: by making the QByteArray one a
Q_WEAK_OVERLOAD. This is trivial for QStaticByteArrayMatcher, which
isn't exported, but require QT_REMOVED_SINCE magic for
QByteArrayMatcher, which is.
The additional const char* overload has shielded us from the worst
fall-out so far, it seems, but it makes for a truly horrible overload
set:
matcher.indexIn(str, 3);
Q: Is the 3 here the length of the haystack or the value of the from
parameter?
A: It depends on decltype(str)!
If the (const char*, qsizetype, qsizetype=0) overload is the better
match, then 3 limits the haystack's length.
If, otoh, the (QByteArray(View), qsizetype) overload is the better
match, then it's the value of the from parameter.
As if this wasn't bad enough, QByteArray implcitly converts to const
char* by default!
A follow-up patch will therefore deprecate the (ptr, size) overloads,
so we de-inline the QByteArrayView ones to avoid having to touch the
implementation once more.
Found during 6.3 API review.
Pick-to: 6.3
Change-Id: I9640e0bdd298d651511adebcc85f314db9221d34
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Add a test (same techniques as for the 4+GiB check in
tst_qcryptographichash).
Takes ~1s to build the 4GiB test data here, and skips
when RAM is too low:
$ qtbase/tests/auto/corelib/text/qbytearraymatcher/tst_qbytearraymatcher haystacksWithMoreThan4GiBWork
[...]
QDEBUG : tst_QByteArrayMatcher::haystacksWithMoreThan4GiBWork() created dataset in 891 ms
[...]
$ (ulimit -v 2000000; qtbase/tests/auto/corelib/text/qbytearraymatcher/tst_qbytearraymatcher haystacksWithMoreThan4GiBWork)
********* Start testing of tst_QByteArrayMatcher *********
[...]
SKIP : tst_QByteArrayMatcher::haystacksWithMoreThan4GiBWork() Could not allocate 4GiB plus a couple hundred bytes of RAM.
Loc: [/home/marc/Qt/qt5/qtbase/tests/auto/corelib/text/qbytearraymatcher/tst_qbytearraymatcher.cpp(242)]
[...]
Found during 6.3 API review.
[ChangeLog][QtCore][QStaticByteArrayMatcher] Fixed searching in
strings with size > 2GiB (on 64-bit platforms).
Fixes: QTBUG-100118
Pick-to: 6.3
Change-Id: I1df420965673b5555fef2b75e785954cc50b654f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
We can handle the UTF-8 case by reinterpreting it as Latin-1.
This way, the suffixIndex stays valid as a return value.
As a drive-by, optimize away toLatin1() calls by using a QVLA.
We really need a better way of converting UTF-16 -> L1 than
qt_to_latin1()...
[ChangeLog][QtCore][QVersionNumber] fromString() now takes
QAnyStringView (was: QString, QStringView, QLatin1String)
and a qsizetype pointer (was: int pointer).
Change-Id: I86abaadba2792658fbf93ccd1e0b86e3302c697c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This completes the update to qsizetype in this class, adding a couple of
methods that need to be removed in Qt 7. They're only required where int
is not qsizetype (i.e., 64-bit platforms).
Change-Id: I0e5f6bec596a4a78bd3bfffd16c9de29bec4c637
Reviewed-by: Marc Mutz <marc.mutz@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 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>
Remove the QString/QStringView/QLatin1String/const char* overloads
from the API, but not the ABI.
As a drive-by, replace a use of QStringView::left() by truncate(), as
suggested by a comment.
[ChangeLog][QtCore][QUuid] The from-string constructor and the
fromString() function now take QAnyStringView (was: overload set with
a subset of QString, QByteArray, const char*, QLatin1String,
QStringView each).
Change-Id: If7fa26cfbef9280480c78b669d9f5f14118995ed
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove the QByteArray overload from the API, but not the ABI.
Adapt callers.
Change-Id: I88aa09cbca3b89d0b249ce336ebe49c4b352c9e1
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Use the same new pattern as in QtWidgets.
Amends de18b3ff370543b5b99bd068b871a2cd677cf9f3.
Change-Id: Ia1cbd40aa7a7efc9a954d22b599e13a19a6a9266
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
