summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/tools
Commit message (Collapse)AuthorAgeFilesLines
* tst_qhashfunctions: check qHashRange{,Commutative}() find hidden friend qHash()Marc Mutz2021-11-261-9/+27
| | | | | | | | | ... extending the existing check for ADL-found qHash() implementations. Pick-to: 6.2 5.15 Change-Id: Iac6ed2721db9e95ee921bd1d5170fa8c8d43475d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Long live QVERIFY_THROWS_EXCEPTION!Marc Mutz2021-11-261-1/+1
| | | | | | | | | | | | | Use variable args macros to swallow any extra commas in the expression. To use this, the type of the exception has to be first. Use Eddy's suggestion for a new name to avoid breaking the old macro. [ChangeLog][QtTest] Added QVERIFY_THROWS_EXCEPTION, replacing QVERIFY_EXCEPTION_THROWN, which has therefore been deprecated. Change-Id: I16825c35bae0631c5fad5a9a3ace4d6edc067f83 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Q(Multi)Map: prevent dangling key/value after detach()Giuseppe D'Angelo2021-11-261-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Q(Multi)Map mutating functions that take reference to a key and/or a value (e.g. insert(), take(), etc.) must make sure that those references are still valid -- that is, that the referred objects are still alive -- after the detach() call done inside those functions. In fact, if the key/value are references into *this, one must take extra steps in order to preserve them across the detach(). Consider the scenario where one has two shallow copies of QMap, each accessed by a different thread, and each thread calls a mutating function on its copy, using a reference into the map (e.g. map.take(map.firstKey())). Let's call the shared payload of this QMap SP, with its refcount of 2; it's important to note that the argument (call it A) passed to the mutating function belongs to SP. Each thread may then find the reference count to be different than 1 and therefore do a detach() from inside the mutating function. Then this could happen: Thread 1: Thread 2: detach() detach() SP refcount != 1 => true SP refcount != 1 => true deep copy from SP deep copy from SP ref() the new copy ref() the new copy SP.deref() => 1 => don't dealloc SP set the new copy as payload SP.deref() => 0 => dealloc SP set the new copy as payload use A to access the new copy use A to access the new copy The order of ref()/deref() SP and the new copy in each thread doesn't really matter here. What really matters is that SP has been destroyed and that means A is a danging reference. Fix this by keeping SP alive in the mutating functions before doing a detach(). This can simply be realized by taking a local copy of the map from within such functions. remove() doesn't suffer from this because its implementation doesn't do a bare detach() but something slightly smarter. Change-Id: Iad974a1ad1bd5ee5d1e9378ae90947bef737b6bb Pick-to: 6.2 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QHash: fix thread race around references and detachingMårten Nordheim2021-11-251-0/+56
| | | | | | | | | | | If we detach from a shared hash while holding a reference to a key from said shared hash then there is no guarantee for how long the reference is valid (given a multi-thread environment). Pick-to: 6.2 Change-Id: Ifb610753d24faca63e2c0eb8836c78d55a229001 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* tst_QHashSeed: improve quality of the quality() testThiago Macieira2021-11-231-10/+15
| | | | | | | | | | | We expect to produce all-bits-set in the combined OR'ed value of the seed, so instead of counting how many bits got set and reporting that, simply compare to -1 and count how long it took to get that far. To make sure, I've increased the number of iterations by 50%. Change-Id: I89446ea06b5742efb194fffd16ba37b2d93c19ef Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* tst_QHashSeed: reset the global seed in each iterationThiago Macieira2021-11-231-0/+2
| | | | | | | | | | QHashSeed is not a random number generator (though it uses one). It returns the same value over and over again unless you reset it to a new, random seed. Fixes: QTBUG-98480 Change-Id: I89446ea06b5742efb194fffd16ba36601f08d794 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QtBase: replace windows.h with qt_windows.hYuhang Zhao2021-11-231-1/+1
| | | | | | | | | | We have some special handling in qt_windows.h, use it instead of the original windows.h Change-Id: I12fa45b09d3f2aad355573dce45861d7d28e1d77 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Fix QMultiHash::operator== crashAndreas Buhr2021-11-111-0/+12
| | | | | | | | | | QMultiHash::operator== crashes when comparing two unequal objects. This patch fixes it. Pick-to: 6.2 Fixes: QTBUG-98265 Change-Id: Ibf9fef3372a2b4581843be5f25e65cc9a55ef64d Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QDuplicateTracker: add clear()Thiago Macieira2021-11-111-0/+16
| | | | | | | | I'll need it in QFactoryLoader. Pick-to: 6.2 Change-Id: Ice04365c72984d07a64dfffd16b47f68d25252b4 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* qlibraryinfo.cpp: use qOffsetStringArray for qtConfEntriesThiago Macieira2021-11-031-5/+5
| | | | | | | | | | Beats a manual array with too wide strings. I thought even to simply replace this with a switch (loc)... it's not like this is performance-critical code, given it uses QString. Change-Id: I2bbf422288924c198645fffd16a977778ff8d52d Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix signed/unsigned comparison warnings in tst_QArrayDataEdward Welbourne2021-10-291-6/+6
| | | | | | | | | | QArrayDataPointer<>::size is now a qsizetype, not the uint it used to be. Pick-to: 6.2 Change-Id: I09d7e5a50401b46a12f29f93b2b39d646b771cfc Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* QHash: avoid crashing when reserving on a shared hashMårten Nordheim2021-10-261-0/+17
| | | | | | | | Pick-to: 6.2 Change-Id: I21ad13fa223bd5a2c61112e790965093a2750268 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QHash: double the size of the stored seedThiago Macieira2021-10-261-0/+12
| | | | | | | | | | | | | | | | There's now another half of the seed which will be used by the hashers. This is not stored in QHash, so it is never changed for the lifetime of the application (not even when QHashSeed::setDeterministicGlobalSeed() is called). However, we will not use it when we're in deterministic mode. This commit uses the compiler thread-safe statics to implement the initialization of more than one atomic word, thus freeing us from having to have a reserved value. As a bonus, the QT_HASH_SEED warning will only be printed once. Change-Id: Id2983978ad544ff79911fffd16723f1673f9a5b4 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QVarLengthArray: Reduce memory allocations in emplace()Robert Löhning2021-10-231-0/+27
| | | | | | | | | | | | | | | | Currently, we allocate memory for elements one by one which can get pretty slow when adding many elements. [ChangeLog][QtCore][QVarLengthArray] Reduced number of memory allocations in emplace() by allocating more memory at once. Fixes: QTBUG-97489 Pick-to: 6.2 Change-Id: Idfb5b5946b047d5215c8ed00770574249f9f5d40 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove the unnecessary compile-time check for recursive QSetSona Kurazyan2021-10-211-2/+0
| | | | | | | | | | | | It doesn't make sense to have a recursive QSet with deleted operator==, since it's not possible to add elements to it. Consequently declaring a metatype for it also doesn't make sense. Remove the commented compile-time check for it. Task-number: QTBUG-96257 Change-Id: I74ebefb38adcbe36d5c2f317188743e1f37fe16d Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix metatype declaration for QHash/QMultiHash with no operator==Sona Kurazyan2021-10-201-6/+4
| | | | | | | | | | | | | | | | | | | | | | | When declaring metatypes, the metatype system tries to detect if the comparison operators for the given type exist and automatically register them. In case of QHash, the equality operator was enabled if the value type provides one. But the implementation needs equality operator of the key type as well. As a result, when the key type has no equality operator, the metatype system detects that the equality operator is available for the QHash itself, but the compilation for metatype registration fails when trying to instantiate the code that uses equality operator for the key. This is fixed by enabling equality operators for the QHash only when both the key and value types provide one. The same issue existed also for QMultiHash, with the difference, that QMultiHash didn't have the constraints even on the value type. So added checks for both. Fixes: QTBUG-96256 Pick-to: 6.2 Change-Id: Ib8b6d365223f2b3515cbcb1843524cd6f867a6ac Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QList: avoid a iterator->pointer conversion in the testGiuseppe D'Angelo2021-10-141-1/+1
| | | | | | | | Being a test, I'm going to abuse operator-> on end() to check that we get what we want (a pointer past the end). Change-Id: I7ab8d017b0fe320018820eff336d496328ade481 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QList::iterator: use templates for advancing operatorsThiago Macieira2021-10-121-0/+134
| | | | | | | | | | | | | | | | | | | | | | | | | Because of the addition of the operator T*(), the expression "it + N" where N was not exactly qsizetype but any other integer type was a compilation failure because of ambiguous overload resolution. With GCC it's apparently a warning: warning: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: note: candidate 1: ‘QList<T>::iterator QList<T>::iterator::operator+(qsizetype) const [with T = char; qsizetype = long long int]’ note: candidate 2: ‘operator+(char*, ptrdiff_t {aka long int})’ (built-in) With Clang, it's an error: error: use of overloaded operator '+' is ambiguous (with operand types 'QList<int>::const_iterator' and 'ptrdiff_t' (aka 'long')) note: candidate function inline const_iterator operator+(qsizetype j) const { return const_iterator(i+j); } note: built-in candidate operator+(const int *, long) Pick-to: 6.2 Fixes: QTBUG-96128 Change-Id: Ie72b0dd0fbe84d2caae0fffd16a06f23dd56b060 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* QOffsetStringArray: rewrite in modern C++17Thiago Macieira2021-10-112-13/+18
| | | | | | | | | Less clunky due to having better constexpr support, plus fold expressions. Change-Id: I3eb1bd30e0124f89a052fffd16a6bc73ba79ec19 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Remove checks for features available in C++17Ievgenii Meshcheriakov2021-10-024-25/+0
| | | | | | | | | | This patch removes most of the checks that are made using C++20 __cpp_* macros for features available in C++17 and earlier. Library feature check macros (__cpp_lib_*) are unaffected. Change-Id: I557b2bd0d4ff09b13837555e9880eb28e0355f64 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Compile autotests for IntegrityTatiana Borisova2021-09-204-5/+14
| | | | | | | | | - process environment/DNS are OFF for INTEGRITY Task-number: QTBUG-96176 Pick-to: 6.2 Change-Id: I189a97f88c96a428586c31a66b8d250e04482900 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Remove conditioning on Android embeddedEdward Welbourne2021-09-173-15/+13
| | | | | | | | It is no longer handled separately from Android. This effectively reverts commit 6d50f746fe05a7008b63818e77784dd0c99270a1 Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Add missing dependencies of tests on their helper programsEdward Welbourne2021-09-171-2/+3
| | | | | | | | | | | | | | | | | This ensures that a command such as $ ninja tst_qlocale && ninja tst_qlocale_check will automagically build the syslocaleapp program that the test runs from a subtest. Similar for testlib's selftests and tst_QProcess. As a drive-by, pruned some legacy comments from when CMakeLists.txt files were generated from .pro files. Change-Id: I67691a8175aaef124d4104cf1898193993408bdf Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Fix compilation for recursive Qt containersSona Kurazyan2021-09-071-0/+144
| | | | | | | | | | | | | | | | | | | | The operator checks cause compilation errors when trying to check for their existence for recursive containers. This happens because of trying to check for the operators on the template parameter type(s), that inherit from the container itself, which leads to compilation errors. Introduced alternative versions of the operator checks (with _container suffix), that first check if the container is recursive, i.e. any of its template parameter types inherits from the given container, and skips the operator check, if that's the case. The fix is done for all Qt container types that had the problem, except for QVarLengthArray and QContiguousCache, which don't compile with recursive parameter types for unrelated reasons. Fixes: QTBUG-91707 Pick-to: 6.2 6.1 Change-Id: Ia1e7240b4ce240c1c44f00ca680717d182df7550 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QS(V)/QBA(V)/QL1S::lastIndexOf: fix the offset calculationsGiuseppe D'Angelo2021-08-191-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to fix 0-length matches at the end of a QString, be83ff65c424cff1036e7da19d6175826d9f7ed9 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>
* QVarLengthArray: add support for emplacementMarc Mutz2021-08-161-0/+19
| | | | | | | | | | | | | 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>
* tests: fix some -WvolatileMarc Mutz2021-07-282-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QMap: add operator+ and - for iteratorsGiuseppe D'Angelo2021-07-271-0/+46
| | | | | | | | | | | | | 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/QSet: fix squeeze() for default-constructed containerIvan Solovev2021-07-272-4/+6
| | | | | | | | | | | | | | | | | | | | | 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>
* QDuplicateTracker: bring back appendTo() &&Marc Mutz2021-07-271-7/+37
| | | | | | | | | | | | | | This reverts commit c19695ab953c979f15bbc72c4f4a453e9a114cf6. 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>
* QVarLengthArray: extend unit testsIvan Solovev2021-07-271-3/+341
| | | | | | | | | | | 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>
* QSet: extend testsIvan Solovev2021-07-221-5/+172
| | | | | | | | | | | 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>
* QHash, QMultiHash: extend testsIvan Solovev2021-07-201-12/+532
| | | | | | | | | | | | | | 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>
* QList: extend testsIvan Solovev2021-07-201-13/+428
| | | | | | | | | | | | | | 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>
* QMultiMap: extend unit testsIvan Solovev2021-07-161-143/+581
| | | | | | | | | | | | | 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>
* QCryptographicHash: use a std::array to hold result (was: QByteArray)Marc Mutz2021-07-151-6/+6
| | | | | | | | | | | | | | | | | | | | | | 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>
* QCryptographicHash test: remove the moreThan4GiBOfData(SHA512) check from the CIMarc Mutz2021-07-151-2/+5
| | | | | | | | | | 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>
* QMap: extend unit testsIvan Solovev2021-07-151-4/+301
| | | | | | | | | | | | 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>
* QDuplicateTracker: accept the number of elements to reserve as a ctor argumentMarc Mutz2021-07-141-2/+1
| | | | | | | | | | | | 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>
* CMake: Remove the usage of QT_SOURCE_TREE from testsJoerg Bornemann2021-07-121-1/+1
| | | | | | | | | | | | | | 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>
* tst_QSharedPointer: fix -Wsuggest-override warningsMarc Mutz2021-07-091-7/+7
| | | | | Change-Id: I1aec8d342e8e5e16b39a62c8a0c885e2915feaf9 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Fix QMultiHash::keys(const T&) overloadIvan Solovev2021-07-081-8/+57
| | | | | | | | | | | | 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>
* QMultiHash::find - prevent detaching shared nullIvan Solovev2021-07-081-0/+15
| | | | | | | | | | | | | 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>
* tst_QCryptographicHash: simplify the creation of a large QBAMarc Mutz2021-07-071-4/+1
| | | | | | | | | 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>
* QCryptographicHash: port addData() to QByteArrayViewMarc Mutz2021-07-061-7/+7
| | | | | | | | | | | | | 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>
* QCryptographicHash: don't present the same data over and over againMarc Mutz2021-07-061-0/+84
| | | | | | | | | | | | | | | | | | 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 e12577b56396cca0df05f88f8787706a3a12c82d. [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>
* tst_QCryptographicHash: make hashLength() data-drivenMarc Mutz2021-07-051-3/+12
| | | | | | | Pick-to: 6.1 6.2 Change-Id: I44bf73e15b53b8d93d116f4114bc667c4c94b7b4 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* QHash: Fix erase() edge-caseMårten Nordheim2021-06-181-0/+19
| | | | | | | | | | | | | | | | | | | | | 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>
* String API Symmetry: test for indexOf with large negative offsetMårten Nordheim2021-06-111-1/+1
| | | | | | | | | | | | | | 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>
* QHash: fix qHash(std::pair)Thiago Macieira2021-05-231-0/+40
| | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-02 01:55:27 +0000