We have some patterns for how to document certain functions, but we
also vary the sentences a lot, and you have to look up one
documentation piece and copy it, essentially. If we ever want to
change them, we end up with shotgun surgery.
So apply DRY to the documentation and start a collection of macros to
help with repetitive C++ class documentation tasks.
The first macro is for member-swap(), and the first patch is for
documentation that used the traditional phrasing ("Swaps the X \a
other with this X.").
This doesn't change the documentation, except as follows:
* adds the "very fast and never fails" blurb, if it was missing
* changes the function's argument name to `other`, as required by
the macro.
Task-number: QTBUG-129573
Pick-to: 6.7 6.5 6.2
Change-Id: Ib494bd218334724b3b43796ba6f71fb52b83aa94
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 3ccb4ce781463f1b8e0cb4c9283b3067fe92a32e)
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Changed the number, which caused the problem of showing the snippet.
Two of the same numbers were given to the different snippets.
Fixes: QTBUG-130565
Change-Id: Iba738a1bdaf5821df48bf5e222bee911c5ddf1fc
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit b3e5b134eeaae85025879cd0309664ce0ba1f6de)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
... as is required by the standard.
We have already found that QAnyStringView::max_size() can also not be
static (because the size depends on the charset of the contained
data), so we have a second reason (besides STL compatibility) to
change the current static into non-static max_size() member functions:
Qt consistency.
Found in API-Review.
Amends 7ce6920aac.
Fixes: QTBUG-128450
Change-Id: Id5ee3fec82bc557bd83b6843838ccdd753442cd0
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 6d5e39f4756945b8ada74d745bd949856c1b17f9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
max_size() will be made non-static to strictly follow the C++ Standard
Library concept, but it makes no sense for the Qt containers to have
allocations limited per instance, as they are not allocator-aware. This
commit adds a Qt-style camelCase() function to the STL-style
snake_case() with the semantics we want.
Task-number: QTBUG-128450
Change-Id: I2e4aa228c71c821c01bafc0f37956d29fe652ef1
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 6306ebe749e083126a39b9dd13d7060aa7bdacc2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Formatting indicates that this was how it should be rendered, but qdoc
won't paragraph-break unless there's an empty line.
Add it.
Amends 7ce6920aac.
Change-Id: Idfd3cbc9f075b5f206c2042dc7b22508735dcb38
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 02b436f2c5d7368827794e7ec1224419dca39e7f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In QChar we don't return the upper-case from when it's not
representable as a single QChar; for strings, the uppercase string may
be longer than the original.
Pick-to: 6.7 6.5 6.2 5.15
Change-Id: I57bb1412d79d579a9cc4dc6bdbb839e56f9ea0a8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 65eb1c5579ec56d15583b4af45b50fddd3c799a6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
eb60e94020 refactored the QString::replace
helpers as to avoid a full copy of a string (when detaching) only to
then modify it in order to apply replacements into the new copy.
Unfortunately it also introduced a regression: if we are replacing into
a string that does not need detaching (that is: it's non-static and
there are no shallow copies of it), and the string does not have
sufficient capacity, then the code chose to allocate a brand new string
and do piecewise copies/replacements into the new string.
This is suboptimal, as it precludes the possibility that the string gets
reallocated in place (via a realloc() that doesn't actually move the
string data in memory), which is a huge performance win. (It also
precludes the possibility of compacting the string data "to the left" in
case we do have sufficient capacity, but not at the "right end".)
This caused a 3x slowdown when replacing in large strings.
Solve this by removing the capacity check and unconditionally
reserve()ing enough space so that we can then do in-place replacements.
Change-Id: I921e3ea65222eca8125996d8d3ea77e9c09ba205
Pick-to: 6.7
Fixes: QTBUG-127549
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit 315210de916d060c044c01e53ff249d676122b1b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
MSVC doesn't define __ARM_NEON, but neon is a necessary part of arm64,
so will always be there.
At the same time fix the NEON code for MSVC which has a different
idea of what the intrinsics types are, even if all the intrinsic
functions are the same. This has two consequences:
1. Since NEON lacks construction intrinsics except duplication, NEON mask constants needs to be built differently.
2. Since MSVC has all the NEON types aliases of the same underlying type, QSimdNeon cant do the same type based dispatch as before.
Fixes: QTBUG-127646
Change-Id: I8038bb6bb4557e8ce29e3844f2742a97b4489818
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit 572aa7caa04e85cbc07b18e1d0c720038facbf83)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Added the text as a \note in QString::replace and QStringlist::replace
to make it more visible to the users.
Fixes: QTBUG-63485
Pick-to: 6.7
Change-Id: I519ab079ec86103a768f313cbc5ac625a0170839
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 3e56757d651ffcba9ea65aa990b4e02b05e00b17)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
TSAN has the same issue as ASAN when it comes to the SSE2 usage here.
WARNING: ThreadSanitizer: heap-use-after-free (pid=621)
Read of size 8 at 0x721000049f78 by main thread:
#0 _mm_load_si128(long long __vector(2) const*) /usr/lib64/gcc/x86_64-suse-linux/13/include/emmintrin.h:700 (libQt6Core.so.6+0x2ba056)
#1 qustrlen_sse2 qtbase/src/corelib/text/qstring.cpp:431 (libQt6Core.so.6+0x2ba056)
[...]
Previous write of size 8 at 0x721000049f78 by main thread:
#0 realloc <null> (libtsan.so.2+0x5bdbd)
#1 QArrayData::reallocateUnaligned(QArrayData*, void*, long long, long long, QArrayData::AllocationOption) qtbase/src/corelib/tools/qarraydata.cpp:244 (libQt6Core.so.6+0x309913)
[...]
(gcc 13.3.0)
Pick-to: 6.7
Change-Id: Id0127d5fb498dcf78bb977e6ff1b6b380ae423c7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 600368279dafa60e788d8e3cd3af5c1915990fbb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Most of the Part internal type (except 'number') was one of two
QAnyStringView-look-alikes originally developed for
QStringView/QLatin1StringView arg() support.
Clean it up to use QAnyStringView directly, thus taking the first step
towards UTF-8 support in QString/View::args().
While we can't encounter UTF-8 Parts with this patch, yet, adjust the
concatenation logic to deal with them already: the concatenation
code-path required by the call to visit(), and the result truncation
due to the potential overestimation of UTF-8 decoded lengths.
Task-number: QTBUG-124365
Change-Id: Idcbcbf10fa8125026115201b963877efe498a18b
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Found by ubsan: if rhs is nullptr, then we fed a nullptr as the second
argument of memcmp(), which is UB.
Fix by catching an empty rhs before we reach that line.
Amends e52d50a03d (which, despite
pick-to's to the contrary, never made it into 6.2 or 5.15).
Change b977ae371a fixed this for
UTF-8/UTF-8 comparison from 6.5 on, but 6.4 ad 6.3 remain vulnerable
there, but they're closed, so can't be fixed anymore.
Pick-to: 6.7 6.5
Change-Id: I12fa986aa82a7440a9d53fad19a15e9420233e0b
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
There are some architectures where
sizeof(qregisteruint) > sizeof(size_t)
so this could be a minor performance improvement.
Change-Id: If05cb740b64f42eba21efffd17cf30c3ae5bd88f
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
There was a discrepancy that the multi-arg arg() overload would accept
any number of digits in the placeholder, resolving up to value 999
(e.g., %000001 was interpreted as placeholder #1), but the single-arg
arg() overload only supported exactly one or two digits. The single-arg
behavior was documented, so use it.
[ChangeLog][Important Behavior Changes] The QString::arg() overload
taking multiple QString-like arguments is now fixed to interpret
placeholders like the other arg() overloads: it will find at most two
digits after the '%' character. That is, the sequence "%123" is now
interpreted as placeholder #12 followed by character '3' (verbatim).
Pick-to: 6.7
Fixes: QTBUG-118581
Change-Id: I455fe22ef4ad4b2f9b01fffd17c767a948d41138
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Commit fb50ab7006 replaced relational
operators in QByteArrayView with comparison helper macros.
That commit had to implement the helper methods as static members
instead of hidden friends, because otherwise it broke the
construction of QByteArrayView from QLatin1StringView.
The reason for that is the conditional noexcept on the relational
operators. The noexcept(noexcept(comparesEqual)) check inside the
class declaration expands before the class is complete, and as a
result discards the QByteArrayView constructor, which is restricted
by the QtPrivate::IsContainerCompatibleWithQByteArrayView trait.
Back then I could not find a proper solution, so just decided to
declare the helper functions for QByteArrayView as private static
members.
Such approach has two drawbacks:
- all new helper functions for QBAV vs other type T relational
operators should also be static member functions, because
the compiler always prefers member functions over friend
functions, even if the argument types do not match.
- QBAV helper functions cannot be used in generic code. Also,
qCompareThreeWay() would not work for QBAV.
To fix the issue this patch explicitly adds a
QByteArrayView(QLatin1StringView) constructor which is not
restricted by any trait. To keep the constructor constexpr, we
have to move the actual definition into qlatin1stringview.h
header file.
Integrity compiler also complains about
QByteArrayView(QUtf8StringView) constructors, so the same approach
is used to enable them.
This allows to convert all the private static member helpers in
QByteArrayView to hidden friends.
The extended tests will be added in a follow-up commit, because
they require some more changes.
Amends fb50ab7006 and
a08bafc920.
This patch removes some exported methods and adds new ones, but
it is not BiC, because the aforementioned patches are only merged
into dev branch at this point.
Task-number: QTBUG-108805
Change-Id: Iee6526a71d859c4fcb2e95bf20fe84ddead6dfb0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Unlike most of everything else in the Bootstrap lib, this is code that
couldn't be eliminated by the linker because they were referenced in one
static array. Maybe an exceptionally smart whole-program analysis could
do it, but GCC and Clang LTO modes don't do that now.
I removed the code that performed detection from HTML and from data too.
I could have left the detection of UTF-8 and "other" but this code
wasn't necessary. In particular, QTextStream couldn't benefit from it
because it already defaults to UTF-8, so the detection code would never
determine anything different from the input.
Drive-by removed QStringConverter::availableCodecs() too because it was
in the middle of functions #ifdef'ed out to.
This reduced the size of release-mode moc
text data bss dec hex filename
1079858 5440 640 1085938 1091f2 original/moc
1074386 5200 640 1080226 107ba2 updated/moc
-5472 -240 0 -5712 difference
Change-Id: I01ec3c774d9943adb903fffd17b7f114c42874ac
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
That is, use the inline functions that refer to <numeric_limits> and
<cmath> directly, instead of the out-of-line wrappers. Someone should
verify if the hacks for QNX's <math.h> are still required.
Change-Id: I01ec3c774d9943adb903fffd17b7ee560b4b71b9
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
It was only used by the cmake_automoc_parser so it would write a 64-bit
in big-endian format. So bypass QDataStream and write it native
endianness.
Change-Id: I01ec3c774d9943adb903fffd17b79c78e56db4cf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Commit 8a7b74f6e7 added these functions
and already placed the checking for the size in the inline code. Aside
from the operators==, the only other place that calls equalStrings()
directly is QAnyStringView::equal() and that also checks the size for
the non-UTF-8 string views do match. Unfortunately, the size checking
for UTF-8 was only added in 52e0a91fbc.
This reverts commit e0eb93d9a2
("QLatin1StringView: delegate operator== to QByteArrayView") because
that would compare the sizes again.
Change-Id: I83dda2d36c904517b3c0fffd17b38e422b5e2c25
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Replace the existing friend relational operators with the macros.
Add the previously-missing relational opertors with QChar and char16_t.
This allows to remove the last dummy relational operators and the
macros to generate them in tst_qstringapisymmetry.
Because of a bug in libstdc++[0], we have to explicitly keep the
QBA vs QBA relational operators even in C++20 mode. This problem is
specific to QByteArray, because it is convertible to const void *.
[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114153
Task-number: QTBUG-117661
Change-Id: Iac7f81cd3274331b7c7695a51803321b511361c0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace the existing friend relational operators with the macros.
Add the previously-missing QChar vs `const char *` relational operators.
These require out-of-line helper methods, because we need to interpret
the `const char *` array as utf-8.
The `const char *` relational operators cause ambiguities when
comparing QChar with 0 (previously it was only handled by the nullptr_t
overloads). As we have it in several places in our tests, I'd assume
that the users can also do it. To resolve the ambiguities, mark the
new relational operators as Q_WEAK_OVERLOADs.
This allows to remove the dummy QChar vs `const char *` relational
operators from tst_qstringapisymmetry, but at the same time requires
that we introduce new dummy operators for QByteArray vs char16_t
comparison. These will be fixed in a follow-up patch.
For QLatin1Char - convert to uchar before doing the comparison, to
match the behavior of QLatin1StringView and QChar. Extend QChar's
unit tests.
Task-number: QTBUG-117661
Change-Id: I9213fe05a5efdb96d48688f07bec9519f9887a77
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This allows to remove the dummy relational operators from
tst_qstringapisymmetry.
Task-number: QTBUG-108805
Change-Id: I7cb3154d6fcb571cafab6b318806f74bc8300448
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The comparison with QStringView works as is, there is no need to add
explicit operators.
Add the missing relational operators with QUtf8StringView. Once it
is added, comparison of QString with u8"string literal" becomes
ambiguous, so explicitly add operators for `const char8_t*` as well.
This also makes the comparison with u8 string literals faster,
because it now uses a view instead of constructing a QString.
Adding QUtf8StringView overloads also makes comparison with
`const char *` ambiguous if QT_RESTRICTED_CAST_FROM_ASCII is defined.
To fix that, mark the overload as Q_WEAK_OVERLOAD. Luckily, we can
just use the third Attributes parameter of the macro for that.
Provide more unit-tests to cover the new relational operators.
Task-number: QTBUG-117661
Change-Id: I60d1f4ad7ea607472deeb5c250e62f2bb7019268
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use the comparison helper macros to replace the member relational
operators for comparison with QByteArray and const char *.
As QString and QByteArray are exported, we cannot simply remove the
inline methods, so wrap them into QT_CORE_REMOVED_SINCE.
Add relational operators with QByteArrayView.
Provide more unit-tests for the comparison with the byte array types.
This enables operator<=> for QString vs byte arrays in C++20 builds.
Task-number: QTBUG-117661
Change-Id: I305343e1b6c5d78b10f2976573db4e904ba6b44b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace the hidden friend relational operators with hidden friend
helper functions and comparison helper macros.
Provide more unit-tests for the updated types.
This enables operator<=> in C++20 builds.
Task-number: QTBUG-117661
Change-Id: I17329cd6422f272a435fc1da241203581eef7fbb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QString/QByteArray] Added slice() methods that work
like sliced(), but modify the string/byte-array they are called on.
Task-number: QTBUG-99218
Change-Id: I3075562983ef123d9aa022a2304c7e774cf2ea42
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
One more method for STL compatibility.
This one is particularly subtle as it's required by the
`reservable-container` concept:
https://eel.is/c++draft/ranges#range.utility.conv.general-3
Without this concept, ranges::to won't reserve() before copying the
elements (out of a sized range which isn't a common_range).
Implementation notes: there were already a couple of constants denoting
the maximum QByteArray and QString size. Centralize that implementation
in QTypedArrayData, so that QList can use it too.
The maximum allocation size (private constant) needs a even more central
place so that even QVLA can use it. Lacking anything better, I've put it
in qcontainerfwd.h.
Since our containers aren't allocator-aware, I can make max_size() a
static member, and replace the existing constants throughout the rest of
qtbase. (I can't kill them yet as they're used by other submodules.)
[ChangeLog][QtCore][QList] Added max_size().
[ChangeLog][QtCore][QString] Added max_size().
[ChangeLog][QtCore][QByteArray] Added max_size().
[ChangeLog][QtCore][QVarLengthArray] Added max_size().
Change-Id: I176142e31b998f4f787c96333894b8f6653eb70d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by using the new comparison helper macors.
Note that by providing helper functions for QByteArrayView,
we can support all three types: QByteArray, QByteArrayView, and
const char *.
Use the regular QT_NO_CAST_FROM_ASCII and
QT_RESTRICTED_CAST_FROM_ASCII guards to disable the operators
if the cast from ASCII is forbidden.
Also use QT_ASCII_CAST_WARN on each operator.
This allows to enable related tests in tst_qstringapisymmetry.
Task-number: QTBUG-117661
Task-number: QTBUG-108805
Change-Id: I0d77c30245d8b5ac4b8cfd98d650c1885aca2005
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by using the new comparison helper macros.
The operators are marked as QT_ASCII_CAST_WARN, like the pre-existing
relational operators with QByteArray and const char *.
This allows to enable related tests in tst_qstringapisymmetry.
Task-number: QTBUG-117661
Task-number: QTBUG-108805
Change-Id: Ic9bcddffc25585edb7375c3e651d49d040a60454
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For these classes it's not really a new feature, but exposing
the current resize() behavior (which does uninitialized resizes)
under a proper name.
Changing the existing behavior for resize() is a behavioral
break that we can only likely afford in Qt 7.
[ChangeLog][QtCore][QString] Added resizeForOverwrite().
[ChangeLog][QtCore][QByteArray] Added resizeForOverwrite().
Change-Id: I15b3104aee2bc29d23e91d97b0e64f87612d0099
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This status is supposed to be used when the stream tries to read
or write more data than it is supported by the current platform.
For example, reading more than 2 GiB of data on a 32-bit platform will
result into this status, but it will work fine on a 64-bit platform.
This patch uses the new status in read operations.
Amends fd48ce0b73
Found in 6.7 API review
Pick-to: 6.7
Change-Id: I675b1ee25fafba174ce8f94c3470dbb7893d6d9e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We can't have those macros defined while compiling the headers on
Windows (mainly MSVC, but there are some corner cases that apply to
MinGW too) because the inline functions must be emitted and added to the
DLL export table. Trying to undefine (as qchar.cpp did) won't work in
builds with PCH or in CMake Unified builds, because the headers in
question will have already been included. So instead just #error out.
qchar.cpp is #included in qstring.cpp so it no longer needs this. For Qt
7, we'll un-export the class (see next commit).
Note: it's possible we only need a single .cpp including the headers and
compiled without these macros for the export to kick in. That could be
removed_api.cpp, because that can never be part of PCH or Unified
sources. But I have not confirmed this is the case.
Task-number: QTBUG-121356
Change-Id: I5dd50a1a7ca5424d9e7afffd17acba32fb27f1ca
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Changed section titles to sentence case.
Added or removed commas as required.
Simplified language were appropriate.
Varied terms to improve engagement.
Corrected resultant text to within the 80 character
width, so there will be whitespace change warnings.
Fixes: QTBUG-119553
Pick-to: 6.6 6.7
Change-Id: I5f40605fde4639a6dfcdb3816f32ad7599572fae
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mats Honkamaa <mats.honkamaa@qt.io>
A null QString / QStringView has a null begin pointer stored as its
array beginning (something we hide a little in the QString::data()
function, but not in QStringView::data()). We've been passing a null
pointer to memcpy() every time someone passed a null QStringView for
QString's single-argument arg() call, though not the multi-string arg()
version (which is the only one QStringView offers).
Commit f5021835df made this worse by
making QStringViews created from null QStrings retain the nullness (as
was intended).
Fixes: QTBUG-120624
Pick-to: 6.2 6.5 6.6 6.7
Change-Id: I6e2677aad2ab45759db2fffd17a870639b19340b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
In the case of QString, the vast majority of searches are case-
sensitive, so by inlining we make the user code call qustrchr() directly
instead of QtPrivate::findString(). In the case of QByteArray, the call
is to memchr(), which being a compiler intrinsic, may itself be inlined
or even just resolved at compile time.
In both cases, a great deal of searches use from=0.
Benchmark for QByteArray; before:
8.83207052 nsecs per iteration
22.01568546 CPU cycles per iteration, 2.49 GHz
60.00000331 instructions per iteration, 2.725 instr/cycle
21.00000281 branch instructions per iteration, 2.38 G/sec
After:
6.42561493 nsecs per iteration
16.01623130 CPU cycles per iteration, 2.49 GHz
49.00000261 instructions per iteration, 3.059 instr/cycle
18.00000211 branch instructions per iteration, 2.8 G/sec
This shaves 6 cycles in the execution and 11 instructions (3 of which
were branches), slightly improving the IPC raito, for the QByteArray
case. For QByteArrayView, there are 2 fewer instructions (1 a branch),
but the number of cycles is the same at 16.
Task-number: QTBUG-119750
Change-Id: Ica7a43f6147b49c187ccfffd179e2204ebb6a348
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This is a repeat of the last commit, which did the same for QByteArray.
No benchmarks in this commit, assuming the results are similar (at least
for cs = Qt::CaseSensitive).
Task-number: QTBUG-119750
Change-Id: Ica7a43f6147b49c187ccfffd179e1f852272af8b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This patch is specific to the return type of updatePtrSimd function as boolean to avoid the bug of GCC 9.2.
Fixes: QTBUG-112920
Pick-to: 6.7 6.6 6.5
Change-Id: I21cb1f6dda34448b2290ab72ec280b6b2a3732c9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The `from` value is not constrained, so the code must be able to
handle all values, incl. `Min := numeric_limits<qsizetype>::min()`.
But the result of negating `Min` is not representable in qsizetype, so
it's UB to try.
Fix by multiplying both sides by -1 (which flips the relational
operator).
This works because the size() of a string is always non-negative, and
the negation of all such values is representable in the same type. Add
a comment to avoid a "fix back".
Amends f9b867216b.
Pick-to: 6.6 6.5
Change-Id: I10d2e400b86f07a6a6c0a61080a27f41a16b3517
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Provide qspan_p.h as backward-compatibility header.
[ChangeLog][QtCore][QSpan] New Qt equivalent of std::span.
Fixes: QTBUG-115022
Change-Id: I1cc27dc0aa1f7406f0a41d7a75f176cd7f858feb
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also update the QCollator::compare() docs for consistency.
Task-number: QTBUG-114822
Change-Id: I5fca896cacedd93ce5a4a1a8aead1986a21f6993
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Marc Mutz
Jaishree Vyas
Allan Sandfeld Jensen
Thiago Macieira
Edward Welbourne
Giuseppe D'Angelo
Ahmad Samir
David Faure
Ivan Solovev
Paul Wicking
Tim Blechmann
Nicholas Bennett
Kai Köhne
shjiu
Luca Di Sera
Anton Kudryavtsev