When trying to fix 0-length matches at the end of a QString,
be83ff65c4 actually introduced a
regression due to how lastIndexOf interprets its `from` parameter.
The "established" (=legacy) interpretation of a negative `from` is that
it is supposed to indicate that we want the last match at offset `from +
size()`. With the default from of -1, that means we want a match
starting at most at position `size() - 1` inclusive, i.e. *at* the last
position in the string. The aforementioned commit changed that, by
allowing a match at position `size()` instead, and this behavioral
change broke code.
The problem the commit tried to fix was that empty matches *are* allowed
to happen at position size(): the last match of regexp // inside the
string "test" is indeed at position 4 (the regexp matches 5 times).
Changing the meaning of negative from to include that last position (in
general: to include position `from+size()+1` as the last valid matching
position, in case of a negative `from`) has unfortunately broken client
code. Therefore, we need to revert it. This patch does that, adapting
the tests as necessary (drive-by: a broken #undef is removed).
Reverting the patch however is not sufficient. What we are facing here
is an historical API mistake that forces the default `from` (-1) to
*skip* the truly last possible match; the mistake is that thre is simply
no way to pass a negative `from` and obtain that match. This means that
the revert will now cause code like this:
str.lastIndexOf(QRE("")); // `from` defaulted to -1
NOT to return str.size(), which is counter-intuitive and wrong. Other
APIs expose this inconsistency: for instance, using
QRegularExpressionIterator would actually yield a last match at position
str.size(). Similarly, using QString::count would return `str.size()+1`.
Note that, in general, it's still possible for clients to call
str.lastIndexOf(~~~, str.size())
to get the "truly last" match.
This patch also tries to fix this case ("have our cake and eat it").
First and foremost, a couple of bugs in QByteArray and QString code are
fixed (when dealing with 0-length needles).
Second, a lastIndexOf overload is added. One overload is the "legacy"
one, that will honor the pre-existing semantics of negative `from`. The
new overload does NOT take a `from` parameter at all, and will actually
match from the truly end (by simply calling `lastIndexOf(~~~, size())`
internally).
These overloads are offered for all the existing lastIndexOf()
overloads, not only the ones taking QRE.
This means that code simply using `lastIndexOf` without any `from`
parameter get the "correct" behavior for 0-length matches, and code that
specifies one gets the legacy behavior. Matches of length > 0 are not
affected anyways, as they can't match at position size().
[ChangeLog][Important Behavior Changes] A regression in the behavior of
the lastIndexOf() function on text-related containers and views
(QString, QStringView, QByteArray, QByteArrayView, QLatin1String) has
been fixed, and the behavior made consistent and more in line with
user expectations. When lastIndexOf() is invoked with a negative `from`
position, the last match has now to start at the last character in the
container/view (before, it was at the position *past* the last
character). This makes a difference when using lastIndexOf() with a
needle that has 0 length (for instance an empty string, a regular
expression that can match 0 characters, and so on); any other case is
unaffected. To retrieve the "truly last" match, one can pass a
positive `from` offset to lastIndexOf() (basically, pass `size()` as the
`from` parameter). To make calls such as `text.lastIndexOf(~~~);`, that
do not pass any `from` parameter, behave properly, a new lastIndexOf()
overload has been added to all the text containers/views. This overload
does not take a `from` parameter at all, and will search starting from
one character past the end of the text, therefore returning a correct
result when used with needles that may yield 0-length matches. Client
code may need to be recompiled in order to use this new overload.
Conversely, client code that needs to skip the "truly last" match now
needs to pass -1 as the `from` parameter instead of relying on the
default.
Change-Id: I5e92bdcf1a57c2c3cca97b6adccf0883d00a92e5
Fixes: QTBUG-94215
Pick-to: 6.2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Take the rvalue insert() function and turn it into the emplace()
function. Reformulate rvalue-insert using emplace(). Lvalue insert()
is using a different code path, so leave that alone. This way, we
don't need to go overboard with testing.
[ChangeLog][QtCore][QVarLengthArray] Added emplace(), emplace_back().
Change-Id: I3e1400820ae0dd1fe87fd4b4c518f7f40be39f8b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
C++20 deprecated compound volatile statements such as pre- and
post-increments, to stress that they're not atomic. So instead of
volatile i;
~~~~;
++i;
you're now supposed to write
volatile i;
~~~~;
int j = i; // volatile load
++j;
i = j; // volatile store
which matches more closely what hardware does.
Instead of fixing every use of volatile pre- or post-increment in this
fashion individually, and realising that probably a few more Qt
modules will have the same kind of code patterns in them, write
QtPrivate functions to do the job centrally.
Change-Id: I838097bd484ef2118c071726963f103c080d2ba5
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We missed the chance of deprecating them in 5.15, so
they'll just add to the pain of porting to 6.0. We
should not keep them around forever, though; QMap isn't
random access and so its iterators should only have
bidirectional APIs.
Pick-to: 6.2
Fixes: QTBUG-95334
Change-Id: I3577f7d25e8ab793722d2f220fd27bc85c622b0d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QHash::squeeze() was unconditionally calling reserve(0), which is
always allocating memory (even for 0 size).
This was leading to a confusing situation when calling squeeze() on
a default-constructed container with 0 capacity() actually allocated
memory. This is very misleading, as squeeze() is supposed to free
unneeded memory, not to allocate more.
This patch adds a check for non-zero capacity. As a result, nothing
is done for default-constructed container.
Note that this patch also affects the QSet::squeeze() behavior, because
QSet uses QHash as its underlying data type.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Ib1c3c8b7b3de6ddeefea0e70b1ec71803e8fd3b3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
This reverts commit c19695ab95.
Just because QSet has limited API doesn't mean we can't provide this
in an efficient way for std::unordered_set :P
Added tests.
Pick-to: 6.2
Change-Id: I4f8f0e60c810acdc666cf34f929845227ed87f3b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This patch introduces some test improvements to check the calls of
different methods on an empty default-constructed container.
Apart from that, many other tests are added to extend code coverage.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Icc1f1342738603c9bed065b2a36c72ea60b48962
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Extend tests to explicitly check the behavior of empty
default-constructed container.
Also add some missing tests to increase the code coverage.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Ie57b5d13fad9a846c29c87be4985c87e69bba305
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Extend tests to explicitly check the behavior of empty
default-constructed containers.
Also add some missing tests for the existing methods
(mostly for QMultiHash) and correct some end()s to cend()s
in comparisons.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Ic9e1b86ef67f6bca2751a65a8589b2f7e0ebb5ea
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch mostly introduces some test improvements to check the
calls of different methods on an empty default-constructed
container.
Apart from that some other tests are added to extend test
coverage.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: If2bc96158462292bbdf8504942141af94568c729
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Extend tests to explicitly check the behavior of empty
default-constructed container.
Also add some missing tests to increase the code coverage.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Ib3c3f5bcb967cd1031cb24ffceaa77a146212ffd
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
The maximum size for a hash result is 64 atm. Even if, and esp when,
we'll get to 128 and 256 bytes in the future, there's no reason to use
dynamic memory, because the sizes will always be statically known.
So use, essentially, a std::array<char, 64> to hold the result
internally. Add a bit of convenience API on top to limit impact on the
rest of the code and add a few static_asserts that ensure this is large
enough. Then give users access to the internal buffer by adding
QByteArrayView resultView() const noexcept. The documentation snippet
is taken from QString::data(), suitably adjusted.
Use resultView() in a few places instead of result().
[ChangeLog][QtCore][QCryptographicHash] Changed to use a
statically-sized buffer internally. Added resultView() to access it.
Change-Id: I96c35e55acacbe94529446d720c18325273ffd2f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It timed out the other day on the CI. Even the SHA-1 check took 137s
(with a 300s timeout). Skip the SHA-512 test on the CI, but keep it
for manual runs.
Pick-to: 6.1 6.2
Change-Id: I49792ac9bcab6512e1803f66cd986b2830e634c0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Extend tests to explicitly check the behavior of empty
default-constructed container.
Also add some missing tests to increase the code coverage.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: I5b418265fc7cb3e56e44782be7704d642923a8e9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
This prevents us from first reserve()ing Prealloc elements, and then
possibly reserve()ing a larger number, which leaves the first bucket
list's memory unused.
Consequently, deprecate reserve().
Change-Id: Ifc0a5a021097f4589557e7b5e45d9d0892797ade
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The ${QT_SOURCE_TREE}/src/network include paths of several tests are
apparently not needed anymore. Remove those.
tst_qfilesystementry and tst_qfreelist are the only tests that actually
need to reference files in qtbase's source tree. Simply use the paths
relative to the project file.
Task-number: QTBUG-88090
Change-Id: Ic6f341e001338c1b07dce6e58316245bc9560c5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The method was never tested, but it failed to compile after
QMultiHash was introduced as a separate class in 6.0.
This patch fixes it and adds some unit-tests to cover the case.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: I5dd989d4775efc6a9bb13c5ed1d892e499d95dc2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Do not detach when find(key, value) is called on an empty QMultiHash.
As a drive-by: fix return value for QMultiHash::remove() in case of
empty QMultiHash.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: I1e32f359e7ee9ce8403dae79d02e0b88a20ec4a5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Use the ctor instead of appending 1'000'000 chars.
Introduce C++14 digit separators as a drive-by.
Change-Id: Icdbef3173f42d12ae2226b8556f9b1519e594adc
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Incl. the static hash() function. Remove the QByteArray versions from
the API, but not the ABI.
Adapt some callers.
[ChangeLog][QtCore][QCryptographicHash] Replaced QByteArray with
QByteArrayView in addData() and static hash() functions.
Change-Id: Ia0e9bf726276305e05894d323d76a29e985f39eb
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Need to decrement 'remaining' (check), but also increment data (meep).
Testing is a bit complicated, as most algorithms are just too slow to
fit into the 5min QTestLib timeout. Picked the fast ones and Sha512
(which completes here in < 17s, with threads), at least.
Amends e12577b563.
[ChangeLog][QtCore][QCryptographicHash] Fixed a bug where presenting
more than 4GiB in a single addData() call would calculate the wrong
result().
Pick-to: 6.1 6.2
Change-Id: Ic72916ebc33ba087d58225af6d8240e46e41f434
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When the element you want to erase is the last element AND the
next element (element 0), when rehashed, would be relocated to the last
element, this leads to the state below. Which is similar to a test in
tst_qhash for some seeds.
auto it = hash.begin + (hash.size - 1)
it = hash.erase(it)
it != hash.end
By forcing the iterator to increment if we were erasing the last element
we always end up with a pointer which is equal to hash.end
Befriend the tst_qhash class so we can set the seed to a known-bad one
Pick-to: 6.2 6.1
Change-Id: Ie0b175003a2acb175ef5e3ab5a984e010f65d986
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Small change needed to make QString_char16 and QString_QChar return -1
in this case, but other combinations already returns -1.
[ChangeLog][QtCore][Behavior Change] QString::indexOf(QChar) and
QString::indexOf(char16_t) now treat a negative start-position, from,
bigger than the string's size as invalid. It previously
clipped such start-positions to the start of the string, inconsistently
with other QString indexOf overloads.
Change-Id: Ic56c8a558bf40a94845c649647db569892d4df02
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
There were two problems here: first, qHash(std::pair) must be declared
before qHashMulti that might call back to qHash(std::pair) (i.e., a pair
with one element that is also a pair). But moving the declaration above
causes the second problem: the noexcept expression can't refer to qHash
functions that aren't declared yet. So we forward-declare a constexpr
function for that result, but implement it far below.
Fixes: QTBUG-92910
Change-Id: Ia8e48103a54446509e3bfffd16767ed2e29b026c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Commit 37e0953613 added a to-do, but we
can actually change the type, since we've documented since Qt 5.10 that
setting a non-zero value (aside from -1) with qSetGlobalQHashSeed was
not allowed. Storing a value to be reset later is simply not supported.
Change-Id: Id2983978ad544ff79911fffd1671f7b5de284bab
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
There's no reason to be storing `int` in the array data header and
then using it as a QFlags. Just store the QFlags.
Change-Id: I78f489550d74d15a560dacf338110d80a7ddfdd2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The comparison between nullptr and QWeakPointer was just bogus
and ill-formed. The INTEGRITY compiler catches that even if
nothing tries to use the comparison. It is an ill-formed, no
diagnostic required case of a function template never being
able to produce a valid specialization. And while we're at
it, this patch makes the result of comparing a nullptr to
a QWeakPointer or vice versa the same as asking .isNull() from
the weak pointer, because it seems mind-boggling if those
are not the same operation.
Task-number: QTBUG-93093
Change-Id: I0cc80e795c9af2be1b76de05157aa458ef260f2e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The major part is stability tests for QList operations,
Also added std::shared_ptr to the Custom type. shared_ptr
accesses the memory which does not directly belong to
QList, so using it inside a passed-to-qlist type is
beneficial (e.g. ASan could catch extra issues)
Basic prepend-aware cases added to QString/QBA tests
Task-number: QTBUG-93019
Change-Id: I50e742bdf10ea9de2de66539a7dbb9abc4352f82
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
(cherry picked from commit adb41bbe00b2b853d4dd26cd9ee77ae5ed541576)
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Test the relocation logic through the QADP::relocate() method which
basically calls q_relocate_overlap_n inside and then ensures that
the data pointers are in good state
Running these locally in fact revealed a bug in the implementation,
so these tests are definitely good to have
Task-number: QTBUG-93019
Change-Id: I353ed46a31c5c77cd0c5fcacd3dfce46e5cf3e67
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
(cherry picked from commit 65d0f6829cc124f6d0d4003a17bedcb74dddf33b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use the data moves to readjust the free space in the QList,
which ultimately fixes the out-of-memory issues caused by
cases like:
forever {
list.prepend(list.back());
list.removeLast();
}
Task-number: QTBUG-91801
Task-number: QTBUG-91360
Task-number: QTBUG-93019
Change-Id: Iacff69cbf36b8b5b176bb2663df635ec972c875c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
(cherry picked from commit a0253f5f0249024580050e4ec22d50cb139ef8d9)
The six properties duration, updateInterval, currentTime,
direction, loopCount and easingCurve have been ported to the
new property system and are now bindable.
Drive-by renamed a local variable to avoid shadowing.
Task-number: QTBUG-85520
Change-Id: Ibabf106f5200d2dd4329a1e1f96112eccc29d6b1
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QList tests have mostly a scheme of:
void opInt() { op<int>(); }
void opMovable() { op<Movable>(); }
void opCustom() { op<Custom>(); }
As a drive by, move the leak checking into a separate struct/macro
Change-Id: I7cdda3a6c2aa324968aa26594da9f9eafbd49a0a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
With C++20, there is a new iterator_category: contiguous_iterator, for
containers whose elements are stored contiguously in memory. In Qt 6,
QList satisfies this requirement.
However, we still need to tell the standard machinery about it. Step one
is to mark the iterators as contiguous_iterator; as that exists only in
C++20, we have to ifdef accordingly.
We also have to ensure that the iterators satisfy pointer_traits by
defining element_type due to how contiguous_range is specified. As this
runs afoul of LWG 3346, we check for known bad _GLIBCXX_RELEASE
versions.
Change-Id: I8c134544e694ba937e4d912393eb72fa75b49e3d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
qtbug_xxxxx is a fairly ambiguous test name
Change-Id: I4b407160464c9b8300d3683549b0ede837161e7b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As QMultiHash uses a pointer for the data, nullptr dereference is a
thing, so check for valid d before doing anything in count()
Fixes: QTBUG-91704
Pick-to: 6.0 6.1
Change-Id: Ia20440cd7bdc03cb09c77f796fb9c5b52765eac5
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
After QPoint(F), it's now the time of QSize(F) and QVectorND,
which can be unambiguously decomposed.
[ChangeLog][QtCore][QSize] QSize is now usable in a structured
binding declaration.
[ChangeLog][QtCore][QSizeF] QSizeF is now usable in a structured
binding declaration.
[ChangeLog][QtGui][QVector2D] QVector2D is now usable in a
structured binding declaration.
[ChangeLog][QtGui][QVector3D] QVector3D is now usable in a
structured binding declaration.
[ChangeLog][QtGui][QVector4D] QVector4D is now usable in a
structured binding declaration.
Change-Id: I67bb152f4210f2be27607179cd2ec522174cc483
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's the QScopedPointer test, so we want to test deprecated APIs.
Change-Id: I029103b3150c576cba9b395aafc571b9fccc914a
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Somehow QList::fill(t, newSize) introduced a regression in Qt6:
when newSize < QList::size() we should resize to the newSize.
This is aligned with QVector::fill() in 5.15 and std::vector::assign()
While 6.0 is already out, picking it to 6.0.x could save someone who
haven't migrated yet as well as fix some accidental bugs in Qt's code
[ChangeLog][QtCore][QList] Fixed QList::fill() regression introduced in
6.0: calling fill() with size < current list size wouldn't truncate the
list
Fixes: QTBUG-91042
Pick-to: 6.0 6.1
Change-Id: Ic166e2c5e42390b61df1030f7c705e344433f7f2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Make stricter alignment requirements for the allocated header
This strict alignment allows reallocateUnaligned() to property account
for the padding occurring in cases when
alignof(QArrayData) < alignof(T) <= alignof(std::max_align_t), which
happens to be the case on e.g. 32-bit platforms with specific alignment
requirements.
This adds 4 bytes (the difference between alignof(std::max_align_t) and
sizeof(QArrayData)) of overhead for QString, QByteArray and certain QLists
on 32-bit systems.
Task-number: QTBUG-90359
Pick-to: 6.0
Change-Id: I8176a4cc79f100ee772b09425e88fe8ff3ae226a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The delta was clearly intended to be used on the total (and still is)
but it also wound up getting stored in the cache, which wouldn't be a
big problem unless the object was removed, in which case we could
incidentally 'free up more space' than intended.
Pick-to: 6.0
Change-Id: Ib2b0f072d30da6d16a93dce60e4c5f6080c109fc
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Those serve no purpose anymore, now that the .pro files are gone.
Task-number: QTBUG-88742
Change-Id: I39943327b8c9871785b58e9973e4e7602371793e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The test case fails also on QEMU ARMv7.
Task-number: QTBUG-88705
Change-Id: Ibe8c777f0205b298f6b9a27c067dd552253fcf33
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
