This portion of the documentation was there since the Qt 4.5 import of
the repository and may have been correct at the time. They haven't been
for some time and definitely aren't now. So be clear that even if there
are overloads, some of them are bad ideas.
Pick-to: 6.2 6.3 6.4
Change-Id: I810d70e579eb4e2c8e45fffd1719adefb6f9f3bf
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
For the constructors, replace int with qsizetype. For the incorrect
return type in \fn of length(), drop the return type, the presence of
which violated DRY, stressing the importance of that SOLID principle.
Fixes: QTBUG-103531
Pick-to: 6.4 6.3 6.2
Change-Id: Ic7a8e1953333c28a2722fd7f753a0b5af6777395
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These don't look like they could cause bugs, because their range of
values is physically limited, but port them to qsizetype nonetheless,
for consistency, and to save the next reader the task of proving that
they're, indeed, ok.
Pick-to: 6.4
Task-number: QTBUG-103531
Change-Id: I337ea327b54bcf5960928f5d1d72c6fc80dcda31
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Building on 15a80cf8a9, this patch fixes
the case where there are more than INT_MAX occurrences of the
lowest-escape-sequence number, as in
QString("%0").repeated(qsizetype(INT_MAX) + 1).arg(42);
by replacing the corresponding int variables with qsizetype ones.
Task-number: QTBUG-103531
Pick-to: 6.4 6.3
Change-Id: I6f4593a86d8d605031bc1d6520a247676091b2c2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The std::boyer_moore_searcher is buggy for older verions of Microsoft's
STL, and missing in AppleClang's libc++ with an inefficient fall back.
Fixes: QTBUG-100236
Change-Id: Ic3cc916946546d2ef78456cd15e1425d957b989d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It's the same implementation. This also inlines the actual comparison,
to allow the compiler to implement the inline memcmp, if it so wishes.
operator< could be changed too, but QByteArrayView's makes an out-of-
line call to QtPrivate::compareMemory, whereas QLatin1StringView's calls
memcmp() directly, which allows the compiler to optimize.
Change-Id: I89c4eb48af38408daa7cfffd16fde9f2b0a8590b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The getEscape function truncated the qsizetype position it got from
the caller to an int, potentially parsing a previous escape sequence
(or, more likely, garbage), by getting the position in the string
wrong.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-103531
Change-Id: I3b921c0991d238bbacfe6699c56146fe032134df
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
I was told this is 32-bit-only code in Qt 5, where it didn't really
matter, because only QStringView could handle > INT_MAX character
strings. Put up a big stop sign now in Qt 6 to enforce that this
information is correct, incl. notes for when it turns out it isn't.
Pick-to: 6.4 6.3 6.2 5.15
Task-number: QTBUG-59150
Task-number: QTBUG-103531
Change-Id: I4620a43e2e67776cc67531fa993a7bb8e01cffed
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QRegularExpression::match (and globalMatch) is currently overloaded
for QString and QStringView. This creates a subtle API asymmetry:
QRegularExpression re;
auto m1 = re.match(getQString()); // OK
auto m2 = re.match(getStdU16String()); // Dangling
This goes against our decision that every time that there's a possible
lifetime issue at play, it should be "evident". Solving the lifetime
issue here is possible, but tricky -- since QRegularExpression
is out-of-line, one needs a type-erased container for the input
string (basically, std::any) to keep it alive and so on.
Instead I went for the simpler solution: deprecate match(QStringView)
and introduce matchView(QStringView) (same for globalMatch). This
makes it clear that the call is matching over a view and therefore
users are supposed to keep the source object alive.
Drive-by, remove the documentation that says that the QString
overloads might not keep the string alive: they do and forever will.
[ChangeLog][QtCore][QRegularExpression] Added the matchView()
and globalMatchView() functions that operate on string views.
The match(QStringView) and globalMatch(QStringView) overloads
have been deprecated.
Change-Id: I054b8605c2fdea59b556dcfea8920ef4eee78ee9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Both format strings > 2GiB, as well as result strings > 2Gi characters
were affected by the append_utf8() helper function being left unported
from int to qsizetype.
There were actually two bugs in that 5LOC function:
1. The len argument was an int, but the caller feeds a difference of
pointers (even explicitly cast to qsizetype) to the function, so
any stretch of verbatim text > 2GiB in the format would cause the
output string to be corrupted.
2. If the result string was already > 2Gi characters in size, a call
to append_utf8() would truncate it mod INT_MAX, because the
string's size() was stored in an int variable and the used in a
resize() call.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-103531
Change-Id: I0a09d27b7782093d3f8ea17bb621ff8dad375072
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
More qsizetype truncation to int, this time in the number of chunks in
SIMD processing, so the limit isn't 2Gi, but 16Gi.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-103531
Change-Id: Ib584c8dc7aa8dedc1cb8181e7d6f20b582c93f8c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QString::arg()s placeholders are limited to triple-digits, so 1000
different ones. By the same token, the length of any one of them is
bounded to five (%L?\d{,3}). But the total possible length of escape
sequences is _not_ 5000B, because there's no limit on the number of
_equal_ placeholders, so a format string where the total escape sequence
length exceeded 2Gi characters, e.g.
QString("%L100").repeated(INT_MAX/5 + 1).arg(42);
would produce corrupt data.
Pick-to: 6.4 6.3
Task-number: QTBUG-103531
Change-Id: Id27ee02579387efcbb5928de1eb9acbeb9f954c9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's not used and not useful.
The macro itself has to stay, for now, because Qt5Compat uses it, too.
Task-number: QTBUG-100861
Pick-to: 6.4 6.3 6.2
Change-Id: I5d0557a6c959d6facf6e47f26786a9d365339e95
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QString has several functions taking a QRegularExpression: indexOf(),
contains(), and so on. Some of those have an out-argument of type
QRegularExpressionMatch, to report the details of the match (if any).
For instance:
QRegularExpression re(...);
QRegularExpressionMatch match;
if (string.contains(re, &match))
use(match);
The code used to route the implementation of these functions through
QStringView (which has the very same functions). This however opens
up a lifetime problem with temporary strings:
if (getString().contains(re, &match))
use(match); // match is dangling
Here `match` is dangling because it is referencing data into the
destroyed temporary -- nothing is keeping the string alive. This is
against the rules we've decided for Qt, and it's also asymmetric with
the corresponding code that uses QRegularExpression directly instead:
match = re.match(getString());
if (match.hasMatch())
use(match); // not dangling
... although we've documented not to do this. (In light of the decision
we've made w.r.t. temporaries, the documentation is wrong anyways.)
Here QRE takes a copy of the string and stores it in the match object,
thus keeping it alive.
Hence, extend the implementation of the QString functions to keep a
(shallow) copy of the string. To keep the code shared as much as
possible with QStringView, in theory one could have a function taking a
std::variant<QString, QStringView> and that uses the currently active
member. However I've found that std::variant here creates some abysmal
codegen, so instead I went for a simpler approach -- pass a QStringView
and an optional pointer to a QString. Use the latter if it's loaded.
QStringView has some inline code that calls into exported functions, so
I can't change the signature of them without breaking BC; I'm instead
adding new unexported functions and a Qt 7 note to unify them.
Change-Id: I7c65885a84069d0fbb902dcc96ddff543ca84562
Fixes: QTBUG-103940
Pick-to: 6.2 6.3 6.4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
We don't support it any more. I don't think it has ever properly
compiled Qt 6 (and it's no longer working for me against GCC 12's
libstdc++ headers). If you report a bug against it, Intel support's
first question is if you can try instead the new Clang/LLVM-based oneAPI
C++ compiler.
So we support only that one, which identifies itself as Q_CC_CLANG.
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb57a092c8439e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
[ChangeLog][QtCore] Deprecated _qs and _qba literal operators
for QString and QByteArray in favor of _s and _ba in the
Qt::Literals::StringLiterals namespace.
Task-number: QTBUG-101408
Change-Id: I26aee0055e3b4c1860de6eda8e0eb857c5b3e11a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QByteArray/QByteArrayView/QLatin1String/QString/QStringView]
The string-to-integer conversion functions (toInt() etc) now support
the 0b prefix for binary literals. That means that base = 0 will
recognize 0b to mean base = 2 and an explicit base = 2 argument will
make toInt() (etc) skip an optional 0b.
[ChangeLog][QtCore][Important Behavior Changes] Due to the
newly-introduced support for 0b (binary) prefixes in integer parsing,
some strings that were previously rejected as invalid now parse as
valid. E.g., Qt 6.3 with autodetected bases would have tried to parse
"0b1" as an octal value and fail, whereas 6.4 will parse it as the
binary literal and return 1.
Fixes: QTBUG-85002
Change-Id: Id4eff72d63619080e5afece4d059b6ffd52f28c8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
[ChangeLog][QtCore] Added literal operators for _s and _ba for QString
and QByteArray respectively in the Qt::Literals::StringLiterals
namespace.
Task-number: QTBUG-101408
Change-Id: I5cd4e7f36f614ea805cfecc27b91c5d981cd3794
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
As a drive-by, did also minor refactorings/improvements.
Task-number: QTBUG-98434
Change-Id: I81964176ae2f07ea63674c96f47f9c6aa046854f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
- Replaced QLatin1String with QLatin1StringView in QString/QLatin1String
APIs and docs (except for QLatin1String class declaration and ctor
names).
- Made the docs look like QLatin1StringView is "The Real Thing".
[ChangeLog][QtCore] Made QLatin1StringView the recommended name for
referring to a Latin-1 string view (instead of QLatin1String).
Task-number: QTBUG-98434
Change-Id: I6d9a85cc956c6da0c910ad7d23be7956e4bd94ac
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Same as the previous commit, one of the reasons it was done like this
was because of git blame. The qt_{starts,ends}_with functions that are
shared between QtPrivate:: and QString:: are getting inlined so there's
no code benefit.
Pick-to: 6.3
Change-Id: Ib42b3adc93bf4d43bd55fffd16c19a8ed3c94483
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
And remove their uses.
[ChangeLog][QtCore][Deprecation Notice] Deprecated QString::count()
and QByteArray::count() that take no parameters, to avoid confusion
with the algorithm overloads of the same name. They can be replaced
by size() or length() methods.
Change-Id: I6541e3235ab58cf750d89568d66d3b1d9bbd4a04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Required for the API symmetry between QStringView and QLatin1String.
[ChangeLog][QtCore][QStringView] Added an overload of
QStringView::count() for QLatin1String.
Change-Id: Ic49a4b31e8f6f0969eff0f792654d23a60e06c49
Task-numer: QTBUG-98431
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The operators are declared in the Qt::Literals::StringLiterals
namespace, to avoid collisions in the global namespace.
[ChangeLog][QtCore][QLatin1String] Added literal operator""_L1 that
converts string literals and chars to QLatin1String and QLatin1Char.
Fixes: QTBUG-98434
Change-Id: Ia945a6acf4b8d4fbbb5f803264e4d79d7b17a8da
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
As a drive-by, fixed misleading wording used in docs.
[ChangeLog][QtCore][Potentially Source-Incompatible Changes][QLatin1String]
Added QLatin1String(std::nullptr_t) constructor, which makes
QLatin1String(0) call ambiguous. To fix the ambiguity, nullptr
must be passed instead of 0.
Task-number: QTBUG-98433
Change-Id: I2b888aa23469343d78aa640dc39a6028b77165dd
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Just as a minor debugging helper: when warning that an invalid
regular expression object is being used to match, also print
the used regular expression pattern.
Change-Id: I0f99bcf4ca87ec67d04ed91d9dc315814f56d392
Fixes: QTBUG-76670
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... instead of self-rolled versions in at least three TUs.
QByteArray's asciiLower() cannot be completely removed, yet, because
it's used for indirect calls.
Change-Id: Icf4e7605184f0a1157967c78cbd7632b283c4a9d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use memchr() if the needle has size() one, and add a fast path in
findString(QLatin1String, QStringView) to circumvent the QVLA path. We
might want to extend this and use a simple C array for very short
needles and (cached?) Boyer-Moore for anything larger.
Pick-to: 6.3
Change-Id: I8364ea9f004d537be8a09cc751408d8adb902d13
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
For a long time now we have fast mixed UTF-16/UTF-8 comparisons. But
no-one told this ol' relic, which still converted UTF-8 to UTF-16 for
comparison.
Fix by using QtPrivate::compareStrings(QSV, QU8SV), which, as the
central entry point, uses the fast-path.
Consequently, compare_helper can now be noexcept.
Pick-to: 6.3 6.2
Change-Id: I4cc9f07d9bc48628f1fe695e80015a9a07b79d6f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This reverts commit 1c164ec7f2,
except for the test additions.
Reason for revert: We need to optimize the implementation, not
complicate the API.
Found during the 6.3 API review.
Pick-to: 6.3
Change-Id: I91c3f65ed6d1fc438deb0e028d578a07c0005362
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This enables the code also for boostrap.
Amends b24e689cb5.
Pick-to: 6.3
Change-Id: I8efc76c20690282a2428f360d6b93896966b97ee
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We were converting the full L1 haystack to UTF-16. But, even so, we
won't be able to find non-L1 UTF-16 needles in L1 haystacks!
Optimize by converting the needle (not the haystack) to L1, after
checking it's actually L1.
Pick-to: 6.3
Change-Id: I413d7a602d44ecb2d3149dc4fa87c690c40e6aaa
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The new overloads mean that when passing QByteArrayView or
QLatin1String objects, we don't expand them into .data() and
.size() anymore.
Pick-to: 6.3
Change-Id: I0c898e0463d0bf81ce1f7d57e10e64f23bd84587
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Arguably, when talking about «null-string» constructor, it might be
useful to read about which strings are considered null, and which
methods one can use to test that.
Change-Id: Ie30144f33000aac53f4041cfb99da28a79dad946
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If the SIMD code has already determined that the byte content differs,
we don't need to actually subtract the bytes we loaded from memory in
vector operations to return a sorting result.
Change-Id: I0e5f6bec596a4a78bd3bfffd16c908b2902e1b1b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
So we don't accidentally make modifications to one and not the other.
Change-Id: I0e5f6bec596a4a78bd3bfffd16c94f1025aea521
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
If the lengths aren't equal, the strings can't be equal either, so we
can skip the entire comparison. Some of the front-end functions that
call these entry points already check for this, actually.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c8ceb9594512f2
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The compareStrings() entry points take QStringView and QLatin1String,
which are both ordered [size, pointer], so match that in the ucstricmp()
parameters. This further reduces the prologue of the compareStrings()
functions before reaching the case-sensitive comparison.
There's no need to do the same for the case-sensitive functions because
they're getting inlined.
Change-Id: I0e5f6bec596a4a78bd3bfffd16c8ffc980c8af0c
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Case-insensitive comparisons are not common, but both GCC and Clang
inlined the ucstricmp() functions into QtPrivate::compareStrings(), with
the side-effect that a lot of unnecessary setup code saving CPU
registers was executed in the prologue of those functions.
After this, Clang 13 emits both compareString() functions without any
push/pop to save registers on x86-64; GCC 11 still emits a few, but
fewer than before (it's emitting some unnecessary overhead for the
loops).
Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fc2c0be9165f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This is very old code, predating the public Qt history (Qt 4.5). It
predates all other SIMD code in qstring.cpp, actually. Now that we do
have implementations for MIPS DSP, ARM Neon and x86 SSE2, this content
has very little value. It would be relevant for other architectures Qt
still supports (POWER and RISC-V come to mind), but I guess the
compiler's auto-vectorizer functionality can do a better job than this
content.
Change-Id: I0e5f6bec596a4a78bd3bfffd16c90733fb0d8f22
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Hot function, so help the compiler out. In particular, this removes any
touch to the ref count, so there are no atomic operations or dead code
leading to memory allocations and deallocations.
Change-Id: I0e5f6bec596a4a78bd3bfffd16c9a0fbd8dd2c12
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
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>
qstrncmp() would stop at the first null character, which isn't correct.
The tests that had been disabled in tst_qstring.cpp (with an inaccurate
comment) were actually passing. I've added one more to ensure that the
terminating null is compared where needed.
[ChangeLog][QtCore][QLatin1String and QUtf8StringView] Fixed a
couple of bugs where two QLatin1Strings or two QUtf8StringViews
would stop their comparisons at the first embedded null
character, instead of comparing the full string. This issue
affected both classes' relational operators (less than, greater
than, etc.) and QUtf8StringView's operator== and operator!=.
Pick-to: 5.15 6.2 6.3
Change-Id: I0e5f6bec596a4a78bd3bfffd16c90ecea71ea68e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Thiago Macieira
Ahmad Samir
Marc Mutz
Øystein Heskestad
Sona Kurazyan
Giuseppe D'Angelo
Lucie Gérard
Ivan Tkachenko