summaryrefslogtreecommitdiffstats
path: root/src/corelib/tools
Commit message (Collapse)AuthorAgeFilesLines
* QArrayDataOps: fix QList range ctors with mixed value_type in C++20 buildsMarc Mutz2021-11-061-3/+10
| | | | | | | | | | | | | | | | | | The QList<X> range ctor is supposed to accept iterators with value_types convertible to X, e.g. tst_qitemselectionrange passes iterator to a container of QModelIndex to the ctor of a QList<QPersistentModelIndex>. But copyAppend() is not a template, so trying to pass QModelIndex* when QPersistentModelIndex* is expected errors out. Fix by taking the copyAppend() path only if the types match. Amends 507be11303c8dd9709d903f8e5ec197be66209ce. Change-Id: I5e3ff84a80dc05dafde5572463b33df9002c8fe0 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* qlibraryinfo.cpp: use qOffsetStringArray for qtConfEntriesThiago Macieira2021-11-031-6/+14
| | | | | | | | | | 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>
* QMultiHash: Add forgotten documentationMårten Nordheim2021-11-031-6/+16
| | | | | | | | | | | After the split of QHash and QMultiHash this function was not documented since it was previously inherited from QHash. As a drive-by also update 'int' to 'qsizetype' in docs Pick-to: 6.2 Change-Id: I5d168886f13c2cdd4482038e66d0cf218789c847 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Match documentation of shared pointers to new definitionsAllan Sandfeld Jensen2021-11-011-4/+8
| | | | | | | | We also have move semantics and noexcept. Pick-to: 6.2 Change-Id: Idcb1d39f79ff45738c641f8dd07fb71cf32d9aca Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qconfig.cpp: use qOffsetStringArrayThiago Macieira2021-10-291-0/+7
| | | | | | | | | | It's been there for ages, we may as well use it and remove unnecessary complexity from CMake. Pick-to: 6.2 Change-Id: I2bbf422288924c198645fffd16a9742567a7e4af Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* QVarLengthArray: Add explicit assertions for implicit assumptionsRobert Löhning2021-10-291-0/+2
| | | | | | | Change-Id: I4dfbf6174483b4af91f31a05c18cfec2aaec6e1f Pick-to: 6.2 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QHash: avoid crashing when reserving on a shared hashMårten Nordheim2021-10-261-1/+2
| | | | | | | | 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: use the shadow seedThiago Macieira2021-10-261-21/+20
| | | | | | | | | | | | | [ChangeLog][Important Behavior Changes] The qHash functions operating on string-like types and the qHashBits function will now mix in a shadow seed (not available in any API) if the provided main seed is not 0. This means the hashing value for any particular input has an almost zero chance of being equal in two different processes, even if processes of the same application. This unpredictability makes QHash more strongly resist denial-of-service attacks through degenerate hashing tables. Change-Id: Id2983978ad544ff79911fffd167240196f7cd5c8 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QHash: double the size of the stored seedThiago Macieira2021-10-261-66/+114
| | | | | | | | | | | | | | | | 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-1/+2
| | | | | | | | | | | | | | | | 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>
* Fix metatype declaration for QHash/QMultiHash with no operator==Sona Kurazyan2021-10-201-6/+14
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix docs for comparison/debug/data stream operators of Qt containersSona Kurazyan2021-10-185-0/+34
| | | | | | | | | | | | | | Because of the constraints on comparison, debug and data stream operators, the return types for them look weird in docs. Conditionally use the actual return types, in case if Q_CLANG_QDOC is defined. Also add the docs of debug stream operators for types for which they were misssing. Task-number: QTBUG-97247 Pick-to: 6.2 Change-Id: I57f2c52bd3af805c7eeebb602c47de1e95ee09bd Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QList: deprecate iterator<->pointer implicit conversions (3/3)Giuseppe D'Angelo2021-10-161-2/+14
| | | | | | | | | | Follow-up of the previous commit: in case the implicit conversions between iterator and pointers are disabled, then reintroduce the non-template arithmetic operators for the iterator classes. Change-Id: I8cee60fe77ee3a47e189b4b53a08e39408f9db18 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QList: deprecate iterator<->pointer implicit conversions (2/3)Giuseppe D'Angelo2021-10-161-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The constructor from a raw pointer should be 1) constexpr, 2) explicit, and 3) *private*. We can do 1) without too much trouble. 2) is a (easy to fix) SIC in case of implicit conversions accidentally relied upon from somewhere. 3) cannot be "easily" fixed by user code (they have to refactor), and also, it's a BIC on Windows which encodes class members' access in symbols. Someone may have been exporting some QList subclass, in turn exporting the iterator classes, and therefore that someone now has the constructors' symbols with a given access. So, don't do 2+3 _just yet_ for user code, but set a deadline: Qt 6.5 is the last that will support this. On Qt 6.6, we switch. All of this on non-Windows, againt to avoid an ABI break. One can opt-in at any time via a suitable define. Given we have this define, use it to guard the other way around as well: conversions from an iterator to a raw pointer should never be explicit (there's std::to_address for this). [ChangeLog][QtCore][QList] Converting a QList's iterator from and to a raw pointer is deprecated, and will get removed in Qt 6.6. User code can prepare for the change by defining QT_STRICT_QLIST_ITERATORS. Change-Id: I0f34bfa3ac055c02af5a3ca159180304660dfc11 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QList: deprecate iterator<->pointer implicit conversions (1/3)Giuseppe D'Angelo2021-10-161-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | QList<T>::(const_)iterator both feature an implicit operator T*. This operator exists in order to keep compatibility with Qt 5 code, where QVector<T>::iterator _was_ indeed a T*. However, iterators are not proxy objects and should not convert to T* (at least, not implictly). In fact we've already seen compilers complain about ambiguous calls when e.g. moving an iterator through an arithmetic operation (say, operator+). For instance, if one does it + number and the numeric argument of that call is not precisely qsizetype (but, say, int), then the call is ambiguous between operator+(iterator, int promoted to qsizetype) operator+(pointer (converted from iterator), int) One can imagine similar failures in generic code. In short: let's deprecate (not remove) the implicit conversion, and let people use iterators for what they are. Task-number: QTBUG-96128 Change-Id: I008348beefe00e4449b2d95c21c842d676390a26 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QList: add mixed comparison operators between (const_)iteratorsGiuseppe D'Angelo2021-10-151-2/+15
| | | | | | | | | | | | | It is currently possible to compare a QList iterator with a const_iterator and viceversa, even though these operations aren't defined, because they are actually routed through the relational operators between iterators and raw pointers after a conversion (!). With the deprecation of iterator->pointer implicit conversions, this is going to break, so add the missig mixed comparison operators. Change-Id: Ic645ab0246f79f64b04334ecd02e9fe8fa46f0fa Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QList: remove yet another iterator->pointer implicit conversionGiuseppe D'Angelo2021-10-131-1/+5
| | | | | | | | | | | | | | The ranged constructor for QList has an optimization when the iterators are QList's own iterators. In that case, it uses a "contiguous append" shortcut by converting the iterators to pointers. Avoid that conversion by extracting the pointers from the iterators. Note that this is an optimization for C++17 only; in C++20 appendIteratorRange will deal with this case as well. Leave a note. Change-Id: I761c36ff500dee95b4ae1b0a4479d22db0c8e3de Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QArrayDataOps: improve appendIteratorRangeGiuseppe D'Angelo2021-10-131-4/+14
| | | | | | | | Handle contiguous iterators in there directly. Change-Id: I3b6d45f993f82d0de5edbfcd75856f43a7f1263b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QList: code tidiesGiuseppe D'Angelo2021-10-131-19/+19
| | | | | | | | Do not rely on implicit pointer->QList::(const_)iterator conversions. Amend QList's own code so to avoid them. Change-Id: Ia3e7a83631943e636831217cdad28b73c98c1dc7 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QList::iterator: use templates for advancing operatorsThiago Macieira2021-10-121-10/+22
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* corelib: Fix typos in documentationJonas Kvinge2021-10-124-4/+4
| | | | | | Pick-to: 5.15 6.2 Change-Id: I64d63af708bc6ddaabd12450eb3089e5077f849e Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* corelib: Fix typos in source code commentsJonas Kvinge2021-10-121-1/+1
| | | | | | Pick-to: 6.2 Change-Id: Ic78afb67143112468c6f84677ac88f27a74b53aa Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QOffsetStringArray: rewrite in modern C++17Thiago Macieira2021-10-111-116/+87
| | | | | | | | | 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 QWeakPointer::operator->Fabian Kosmale2021-10-051-4/+0
| | | | | | | | | | | | | operator-> was only defined if QWEAKPOINTER_ENABLE_ARROW is defined. However, even in that case it would call QWeakPointer<T>::data, which does not actually exist. Take this as an indicator that nobody actually uses operator->, and remove the code completely. Note that the QWEAKPOINTER_ENABLE_ARROW was not documented, and neither was operator->. Change-Id: I2f4aa961a64281542c8c1b248a993e83471c059d Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QHash: suppress annoying GCC warning about allocation size too bigThiago Macieira2021-10-041-20/+31
| | | | | | | | | | | GCC is right, the maximum memory allocation is half the VM size, not the full VM size or multiple times that. QHashPrivate::Span is big. qhash.h:552:17: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] Change-Id: Ie72b0dd0fbe84d2caae0fffd16a071ffb5d0c70f Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QRingBuffer: port internals from int to qsizetypeAlex Trotsenko2021-10-032-15/+16
| | | | | | | | | | Since Qt6, QByteArray uses qsizetype as an integral type for offsets and sizes. In order to support large blocks, we have to migrate to that as well. Change-Id: I2c2983129d6a2e0a1e8078cc41d446a26e27288c Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove checks for features available in C++17Ievgenii Meshcheriakov2021-10-024-8/+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>
* Purge Q_NO_TEMPLATE_FRIENDS and platforms lacking support for themFabian Kosmale2021-10-021-12/+0
| | | | | | | | | | Given that we rely on C++17, it should be safe to mandate that level of language support. Change-Id: If07ccb36bea2a5113a8f5aacf635be7d2590baf7 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove checks for C++ standard versions C++17 and belowIevgenii Meshcheriakov2021-10-011-1/+1
| | | | | | | | | | | Qt requires a compiler that support C++17 thus __cplusplus is always 201703L or higher. This patch removes checks for __cplusplus value that always succeed. Change-Id: I4b830683ecefab8f913d8b09604086d53209d2e3 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QScoped(Array)Pointer: use the rule of 5Giuseppe D'Angelo2021-09-201-2/+3
| | | | | | | | | | | | CodeChecker complains regarding the two classes not having all the special 5 declared, so do it. Change-Id: I76d562c52f89a24aec9f155c2be62f8844f1f4a7 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Plaster [[nodiscard]] on some RAII classesGiuseppe D'Angelo2021-09-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | The idea is to prevent silly mistakes such as QMutexLocker(mutex); doSomething(); where the locker is constructed and destroyed immediately. Compilers don't normally warn in these cases (as the constructor/destructor pairs involved do have side effects), but we can mark the type as [[nodiscard]] to encourage warnings. There is another couple of classes for which this would make sense (notably, the R/W lockers), but unfortunately those are exported classes, and GCC has a bug where one can't mix two different attribute syntaxes on the same entity [1], so I'm skipping those. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102399 Change-Id: I75a2443dc71e6b80613b8edd52a04d3379355728 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QVersionNumber: fix iterator/pointer mistakeGiuseppe D'Angelo2021-09-171-6/+6
| | | | | | | | | | | | The dataFitsInline and setInlineData functions take a pointer/size pair, not an iterator/size pair. The code was working because QList iterators implicitly convert to pointers -- but that's sloppy, just use the list's data() function instead. Do a similar change for the constructor taking an initializer_list, for symmetry. Change-Id: I2cec191620185b3b08169c4051296eb610f14ecf Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Fix compilation for recursive Qt containersSona Kurazyan2021-09-074-14/+14
| | | | | | | | | | | | | | | | | | | | 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>
* Doc: fix qdoc warning, function prototype missed return typeVolker Hilsheimer2021-09-051-4/+3
| | | | | | | Also missed the second set of template parameters. Change-Id: I81ab09ed77af79415ee72334db900bdb94db5739 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Doc: fix qdoc warning from wrong see-alsoVolker Hilsheimer2021-09-051-1/+1
| | | | | | | | | | | Only QByteArray has a toHex() member, QByteArrayView doesn't. Since toHex() is linked to from result() already, remove it here to avoid the wrong impression that there was a toHex() that doesn't require any memory allocation. Change-Id: I76f876aca90403baebf9328b794aeaf9be698c46 Reviewed-by: Luca Di Sera <luca.disera@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Doc: fix a bunch of qdoc warnings from wrong prototypesVolker Hilsheimer2021-09-031-2/+1
| | | | | | | | | * name method parameters consistently with their declaration * don't document parameters that are not there Pick-to: 6.2 Change-Id: I06ae9fdca357ed29eb7a72802f149eb4914181f4 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Convert various callers of strtou?ll() to call strntou?ll()Edward Welbourne2021-08-301-2/+2
| | | | | | | | Where size is known or can readily be determined. Change-Id: I442e7ebb3757fdbf7d021a15e19aeba533b590a5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Doc: Fix documentation issues for Qt CoreTopi Reinio2021-08-245-38/+56
| | | | | | | | | | | | | | * Tag deprecated Q(Multi)Map operators in the header to correctly match them with documentation \fn commands. * Add documentation for QByteArrayView comparison operators. * Add a dummy typedef 'jfieldID' for generating docs correctly on non-Android platforms * Fix other minor issues Pick-to: 6.2 Task-number: QTBUG-95860 Change-Id: I141d2f75d6aa10557aa374201f09ad74b4cd6e81 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Doc: Add missing links to methods to QSet documentation pageLuca Di Sera2021-08-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QVarLengthArray: add missing default-ctor documentationMarc Mutz2021-08-161-0/+5
| | | | | | | | | Was lost when we un-explicit'ed the default ctor in c34242c679aaea6ee1badf6c1e5f274f925f5f50. Pick-to: 6.2 6.1 5.15 Change-Id: Ifb4943b9e9647ae59c1cc6d5fc5076e8620b73ce Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QVarLengthArray: add support for emplacementMarc Mutz2021-08-162-5/+33
| | | | | | | | | | | | | 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>
* QtCore: clean up API removalsMarc Mutz2021-07-282-65/+2
| | | | | | | | | Use the same new pattern as in QtWidgets. Amends de18b3ff370543b5b99bd068b871a2cd677cf9f3. Change-Id: Ia1cbd40aa7a7efc9a954d22b599e13a19a6a9266 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QMap: add operator+ and - for iteratorsGiuseppe D'Angelo2021-07-273-0/+148
| | | | | | | | | | | | | 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-271-1/+5
| | | | | | | | | | | | | | | | | | | | | 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-1/+19
| | | | | | | | | | | | | | 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>
* Doc: Ensure deprecated APIs in Qt Core are documented as suchNico Vertriest2021-07-232-7/+7
| | | | | | | | | | Added \deprecated [version_since] when needed Remove references to deprecated functions in \sa statements Fixes: QTBUG-94534 Pick-to: 6.2 Change-Id: I3b3d4277d63fc5d6d207c28ff2484aed30b83247 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QSet::erase - extend docsIvan Solovev2021-07-211-0/+5
| | | | | | | | | | | | | 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>
* Fix quadratic performance hit in Q(Multi)Map::insert() with hintEdward Welbourne2021-07-201-9/+19
| | | | | | | | | | | | | | | | | | | | | | | 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>
* QCryptographicHash: use a std::array to hold result (was: QByteArray)Marc Mutz2021-07-153-27/+69
| | | | | | | | | | | | | | | | | | | | | | 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>
* QDuplicateTracker: accept the number of elements to reserve as a ctor argumentMarc Mutz2021-07-141-0/+8
| | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 20:25:51 +0000