Some internal links to `QSet` methods were missing from the
documentation. In particular, all methods that were written with one
attribute.
It seems that QDoc might automatically recognize method/function
links only if they have zero parameters, such that the identifier is
followed by `()` directly.
To avoid this problem while keeping the current parameter-containing
form of the text; each function of the form `functioname(\a
parametername)` was changed to `\l {functionname()} {functioname(\a
parametername)}.
Furthermore, one of those text instances was modified to use `\a` for
the parameter name, instead of the previously used `\e`, to enhance
consistency.
An instance of `operator<<()` was not recognized as a link.
To resolve this it was marked with the `\l` command.
Fixes: QTBUG-95389
Pick-to: 6.2 6.1
Change-Id: I16b2a7a2fbaf4785c2c6bfa5017a3db46d9db2f4
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Was lost when we un-explicit'ed the default ctor in
c34242c679.
Pick-to: 6.2 6.1 5.15
Change-Id: Ifb4943b9e9647ae59c1cc6d5fc5076e8620b73ce
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
Use the same new pattern as in QtWidgets.
Amends de18b3ff37.
Change-Id: Ia1cbd40aa7a7efc9a954d22b599e13a19a6a9266
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>
Explicitly specify that calling this method for an empty set or with
an invalid iterator results in undefined behavior.
On a debug build an assert is triggered in such case, but on a release
build it will access the incorect index of an array.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Ibc3e91512a0ad9d9779a41083fedb8a91780380b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The insert() overloads that took a const_iterator started by calling
std::distance(begin(), pos) - which has a cost linear in how far pos
is from begin() - in order to, after detach()ing, obtain an iterator
at the same offset from the new begin(), using std::next() - also
linear. This leads to quadratic behavior when large numbers of entries
are added with constEnd() as the hint, which happened to be tested by
tst_bench_qmap. That wasn't running, due to some assertion failures,
but once those were fixed the hinted tests timed out after five
minutes, where their unhinted peers completed comfortably within a
second.
Check whether detach() is even needed and bypass the std::distance() /
std::next() linear delay when it isn't. This brings the hinted tests
down to running faster than their unhinted equivalents.
Pick-to: 6.1 6.2
Task-number: QTBUG-91713
Change-Id: I6b705bf8fc34e67aed2ac4b3312a836e105ca2f2
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Andrei Golubev <andrei.golubev@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>
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>
Was missed in the int -> qsizetype port for Qt 6.0.
Pick-to: 6.2 6.1
Change-Id: I1ae8190601f2e1a1bc02a736c12230a9c71acb18
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
...by providing std-compatible insert() functions via a local subclass
of QSet, reducing the #ifdef'ery somewhat.
Change-Id: Ib532a866b47b82e8e3b9f199e8d1e01a87ed016d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We have space for so many elements, so reserve()ing anything less
makes no sense.
Pick-to: 6.2 6.1 5.15
Change-Id: I84d692b10a6a491c37661f84aa3fdd9af43d71e5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Instead of just sizeof(T), we, of course, also need to take the
support structure into account, to wit: the bucket list and, in the
node, the next pointer and the stored hash value.
Pick-to: 6.2 6.1 5.15
Change-Id: I8227a95c49e316aacf3d4efd8f6170ea3bea1cf0
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
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>
Now that calling hashLengthInternal() is cheap, use it to factor
common code in switch statements. For sha3, that would have been
possible before, too. Reason for duplicating the case bodies is
unclear.
Change-Id: I281617546e0b3e701315eee2f10df8d26ada92ae
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
... instead of the "usual" rule of three: ctor, addData(), result().
Not only does it generate less code in the caller, it's now also
faster.
Change-Id: I67c7eeb01f527b90e80a08f60c1c7f2ec1e49dd4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Just create it on the stack, we know the lifetime.
Reduces memory allocations in static hash() from 2 to 1.
Change-Id: Ie0e22b023331da9a6f39c80b4cd1a5c016f63a87
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
...and use it internally.
Exported symbols are LD_PRELOADable, so the compiler might not
constant-fold calls to them. Besides, it's a requirement for a
follow-up change.
Change-Id: I437f46d7d42ed0a6921dee3027a471e2aa52baa1
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It never changes, making it const might improve code-gen.
Change-Id: Ife8723e27ae9cf6cfcca48d58d46307003123354
Reviewed-by: Lars Knoll <lars.knoll@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>
The code assumed that any C++ implementation would implement the
resolution for LWG2996 in C++20 mode. While that may be the case in
the future, the current state in GCC 9.3 as shipped in Ubuntu 20.04
LTS is that it doesn't, which leads to tst_qsharedpointer fail there.
Fix by using the safe version of std::move, std::exchange, which
guarantees the state of the src object, no matter what the callee
does.
Pick-to: 6.2 6.1 5.15
Change-Id: Icc39b527df4d3a7b398ff2b44bcbdf9082b81f2f
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Taking the copy after the resize is completely pointless: the copy is
there to ensure that `t`, being a reference potentially aliasing an
element in [begin(), end()[ before the resize(), isn't invalidated by
the resize(), so it must be taken before resize().
Add a comment so the next rewrite doesn't cause this to be mixed up
again.
[ChangeLog][QtCore][QVarLengthArray] Fixed an aliasing bug affecting
insertions of objects aliasing existing elements.
Pick-to: 6.2 6.1 6.0 5.15 5.12
Change-Id: I26bc449fa99bf8d09a19147a12a69ac4314cc61d
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Triggered by API review in Gerrit patch 355960.
Task-number: QTBUG-94407
Pick-to: 6.2
Change-Id: I7cafc1cc9d4b929040b53c6bf92c91d73c3b39f2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The spurious warning is not emitted any more by GCC 10 / 11.
Even if it's still emitted by earlier GCC versions, now it's no longer
an error.
Change-Id: Ia8bf3e10905909c097ecc025bf89f818410a8dae
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The code uses std::numeric_limits but is lacking the appropriate include
Pick-to: 5.15 6.1 6.2
Change-Id: I41fa5ac4d8c4e06f35b5b1551ef2ad8417df80bd
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
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>
Due to capacity() reporting the size of all allocated space, this is
somewhat inconsistent with what QVector::capacity() in Qt5 provided,
due to Q6List being double-ended. So let's document this better
Task-number: QTBUG-92941
Pick-to: 6.2
Change-Id: Iba46389121e721a8d21f0344b154f41c2c245867
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Add module header wrapper that loads the real QtCore header and
qandroidextras_p.h to generate docs for those types
* Add missing dummy typedefs to doc/include/jni.h
* Use the correct \namespace name (QtAndroidPrivate) and mark it
as \preliminary
* Add missing 'const' specifier for Q[Untyped]Bindable methods
* Drop documentation for removed method QProperty::markDirty()
* qmath.h: Fix \fn commands for qFloor(), qCeil()
* QHashSeed: Drop incorrect usage of \relates
Fixes: QTBUG-93942
Task-number: QTBUG-93995
Change-Id: If76b5aa4b79a64add3cb6275eac82ec44ef10319
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
When a weak pointer calls getAndRef and there is no strong reference
yet, getAndRef creates a new ExternalRefCountData. Normally,
ExternalRefCountData is never constructed directly, only its subclasses
are constructed via placement new into a memory buffer.
To that end, ExternalRefCountData has a custom operator delete, which
calls the global operator delete (do deallocate the memory buffer
correctly).
When using operator new directly in getAndRef, gcc notices a new/delete
mismatch with the delete in the same function: global operator new
matched with class operator delete. This isn't actually an issue in
practice, as the class operator delete simply calls the global delete.
But to avoid the warning, we can simply call the global operators
explicitly.
To make it clear that allocation of ExternalRefCountData requires some
care, we additionally delete the class operator new, and only allow
placement new (or usage of global operator new, as in getAndRef).
Pick-to: 6.1
Task-number: QTBUG-93360
Change-Id: I132d1e4e07520eadc5b8f3f955c06aecec80c646
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
It's how much there is in Linux's AT_RANDOM block.
I've also removed the check for validity. It's highly unlikely that 128
bits are bad.
Change-Id: Id2983978ad544ff79911fffd16723161ea7ec315
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Instead of initializing the whole QRandomGenerator::system(), which in
turn gets to checking CPUID and whether the HWRNG works, trust the
operating system functions for an initial value. On Linux, we'll use 4
or 8 of the 16 bytes of random data that the kernel populates for us on
AT_RANDOM.
This should make Qt applications not stall on an early system launch
without an RNG daemon, if compiled without getentropy() support. And
avoids silly mistakes causing recursion, like QTBUG-78007 found.
Additionally, qt_random_initial_value() will most likely not throw
either. It's marked noexcept, even though SystemGenerator::fillBuffer
could throw on Linux, if the current thread is canceled, but Linux also
has AT_RANDOM. That leaves the other Unix systems without getentropy()
(read: macOS, since the BSDs have getentropy()).
Fixes: QTBUG-69555
Change-Id: Id2983978ad544ff79911fffd1671fca1a9f9044d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
That's two years from when the replacements were added (6.2).
Change-Id: Id2983978ad544ff79911fffd1671f7dd38fede02
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
It is noexcept, except when initializing. When initializing, let's just
use qEnvironmentVariableIntValue (which we should have used anyway),
which avoids the memory allocation and is noexcept. The QRandomGenerator
functions are not marked noexcept, but are mostly so: they can't throw
regular exceptions, but some implementations do call POSIX Thread
Cancellation Points, which may cause forced stack unwinding. That's
unlikely to happen at the moment of the QHash initialization.
This is also mitigated in the next commit.
Change-Id: Id2983978ad544ff79911fffd1671fd16f8d6378d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
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>
Use __has_include instead QT_HAS_INCLUDE
Use __has_feature instead QT_HAS_FEATURE
Change-Id: If9b0af1f4386f7bcae6ca2fb911ffaba422750dd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Adds runtime CPU detection for Windows and macOS, and switches feature
detection of AES to runtime like for x86,
So far only on ARM64, since gcc doesn't do function versioning on ARM32,
but clang can, so it could be added later.
Change-Id: Ibe5d60f48cdae3e366a8ecd6263534ba2b09b131
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
Stop going through the implicit int conversion.
[ChangeLog][QtCore][QFlags] QFlags now has a qHash() overload.
Change-Id: Id380ed252695f24af2e8c239b650dcb6f44e2893
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It is deprecated so it shouldn't get mentioned by the ordinary docs.
Pick-to: 6.1
Change-Id: Ic867fd45396871245d6f5714f6a886c706e99c04
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>