summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/tools
Commit message (Collapse)AuthorAgeFilesLines
* QEasingCurve: use comparison helper macrosIvan Solovev3 days2-9/+18
| | | | | | | | | | | | Like with the QLine(F) case, we have to use QT_CORE_REMOVED_SINCE to remove the old member operators, but also need to guard the new friend functions with !(QT_CORE_REMOVED_SINCE), because QEasingCurve is also one of the core types, and on Windows the metatype interface for it is instantiated in removed_api.cpp. Task-number: QTBUG-120308 Change-Id: I1bd66f7230afd3eba868d05fd496ab13a0331178 Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
* QMarginsF: add qFuzzyCompare and qFuzzyIsNull overloadsIvan Solovev3 days1-0/+45
| | | | | | | | | [ChangeLog][QtCore][QMarginsF] Added qFuzzyCompare and qFuzzyIsNull overloads for QMarginsF Task-number: QTBUG-120308 Change-Id: I7c1ceaa9ba544458738b71bf326395eef59e7a54 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMargins(F): use comparison helper macrosIvan Solovev3 days1-0/+8
| | | | | | | | | | | | Also explicitly add QMarginsF vs QMargins comparison. Previously such comparison was implicitly converting QMargins to QMarginsF, and doing the fuzzy comparison. We have to keep the old behavior to avoid breaking user code, so use fuzzy comparison in the new operators as well. Task-number: QTBUG-120308 Change-Id: Ic82f64078cd991859b851f24aa7017ef0b91a4e1 Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
* Fix QMarginsF::operator==() for zero marginsIvan Solovev3 days2-0/+48
| | | | | | | | | | | | | | | The (in)equality operators for QMarginsF are documented to use fuzzy comparison. However, the implementation unconditionally used qFuzzyCompare which is incorrect for the case of 0 margins. Update the implementation to use a combination of qFuzzyIsNull and qFuzzyCompare, like it's done for QPointF. [ChangeLog][QtCore][QMarginsF] Fixed a bug when equality comparison returned incorrect results if one of the margins was zero. Task-number: QTBUG-120308 Change-Id: I6e785fe8b523f6aa5f5317fb75877fdbf4e086c2 Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
* QRectF: add qFuzzyCompare and qFuzzyIsNull overloadsIvan Solovev3 days1-0/+25
| | | | | | | | | [ChangeLog][QtCore][QRectF] Added qFuzzyCompare and qFuzzyIsNull overloads for QRectF Task-number: QTBUG-120308 Change-Id: Ie2eee0a28b902bdfeb91be45a164be659aef1a20 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QRect(F): use comparison helper macrosIvan Solovev3 days2-0/+69
| | | | | | | | | | | | | | Also explicitly add QRectF vs QRect comparison. Previously such comparison was implicitly converting QRect to QRectF, and doing the fuzzy comparison. The new operators are directly calling operator==(QPointF, QPoint), which also does the fuzzy comparison, so the old behavior is preserved. As a drive-by: move the operators into the private section. Task-number: QTBUG-120308 Change-Id: I9b96ed4266e6a6c02a52c8cfff6ec1b2d036a7ca Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
* QLineF: add qFuzzyCompare and qFuzzyIsNull overloadsIvan Solovev3 days1-0/+27
| | | | | | | | | [ChangeLog][QtCore][QLineF] Added qFuzzyCompare and qFuzzyIsNull overloads for QLineF Task-number: QTBUG-120308 Change-Id: I3d032f47851d886adce95ac72109fde169892688 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix QLineF::isNull behavior when handling zero pointsIvan Solovev3 days1-2/+28
| | | | | | | | | | | | | | | | | QLineF::isNull was using qFuzzyCompare on the x and y components of its points, which was not working correctly if some of the components was equal to zero. The correct approach is to use qFuzzyIsNull togeter with qFuzzyCompare. This approach is already implemented in qFuzzyCompare() overload for QPointF, so just use it. Add unit-tests for QLine(F)::isNull. [ChangeLog][QtCore][QLineF] Fixed a bug when QLineF::isNull() returned incorrect result if the start or end point contained a zero component. Change-Id: I3cfe6406b1299de32fe82b1fcbfb0416f0eaac15 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QLine(F): use comparison helper macrosIvan Solovev3 days2-0/+74
| | | | | | | | | | | | | | | | | | | | | | | Also explicitly add QLineF vs QLine comparison. Previously such comparison was implicitly converting QLine to QLineF, and doing the fuzzy comparison. The new operators are directly calling operator==(QPointF, QPoint), which also does the fuzzy comparison, so the old behavior is preserved. Remove the old relational operators using QT_CORE_REMOVED_SINCE, but also wrap the new operators in !defined(QT_CORE_REMOVED_SINCE). That is required, because on Windows the instantiation of QMetaTypeInterface<QLine(F)> happens in removed_api.cpp (as both qline.h and qmetatype.h are already included there). If we just add removed member operators into removed_api.cpp, the metatype interface will not be able to create an equals() function, because of the ambiguity in equality operators (member vs friend). That's why we have to exclude the new friend operators from removed_api.cpp. Done-with: Fabian Kosmale <fabian.kosmale@qt.io> Task-number: QTBUG-120308 Change-Id: Ibbf5ec077f69c75da0d36a8be5596acd0fcd44d0 Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
* Add qFuzzyCompare() and qFuzzyIsNull() overloads for QPointFIvan Solovev3 days1-0/+21
| | | | | | | | | | | Use the new qFuzzyCompare() overload in op==(QPointF, QPointF). [ChangeLog][QtCore][QPointF] Added qFuzzyCompare() and qFuzzyIsNull() overloads for QPointF. Task-number: QTBUG-120308 Change-Id: I522164acb65432bf55c58b55575f25535d27e27a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QPoint(F): use comparison helper macrosIvan Solovev3 days4-17/+39
| | | | | | | | | | | | | | | Explicitly add QPointF vs QPoint comparison. Previously such comparison was implicitly converting QPoint to QPointF, and doing the fuzzy comparison. We have to keep the old behavior to avoid breaking user code, so explicitly use fuzzy comparison in the new operators. As a drive-by: move the friend functions into the private section, so that they are actually hidden friends. Task-number: QTBUG-120308 Change-Id: I471a890b8332455e8b2dc1b99e5fba4ada168a30 Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
* QVersionNumber: use new comparison helper macrosTatiana Borisova6 days2-154/+78
| | | | | | | | | | Replace public friend operators operator==(), operator!=(), operator<(), etc of QVersionNumber to friend methods comparesEqual() / compareThreeWay(). Task-number: QTBUG-120304 Change-Id: Ib94a1a28ca9843ca5d5a8d07f41c63de9fe584bb Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Fix test compilation issues with QtLite configurationJari Helaakoski7 days1-2/+2
| | | | | | | | | | Now developer build tests compile, but some are not working. Functional fix will come later via separate tasks. Task-number: QTBUG-122999 Change-Id: I70487b46c1b32ba4279cb02a4978e4f55ac0d310 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QBitArray: use new comparison helper macrosTatiana Borisova2024-04-262-83/+98
| | | | | | | | | | Replace public friend operators operator==(), operator!=() of QBitArray to friend method comparesEqual() and Q_DECLARE_EQUALITY_COMPARABLE macro. Task-number: QTBUG-120304 Change-Id: I6b47111c144016b3aa05f01c8035c32d164291ad Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Fix warning: remove unused parameterVolker Hilsheimer2024-04-041-1/+1
| | | | | | | | Pick-to: 6.7 6.6 6.5 Change-Id: I5794e38e1e9871f14c9a8df6483e57c1922dace2 Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io> Reviewed-by: Artem Dyomin <artem.dyomin@qt.io> Reviewed-by: Pavel Dubsky <pavel.dubsky@qt.io>
* QCommandLineParser: remove redundant #ifdef from unittestAhmad Samir2024-03-161-4/+0
| | | | | | | | C++11 has been required for a long time. Pick-to: 6.7 6.6 6.5 Change-Id: Ib6c1571b100dd4eb8194d515f2180ca26481b556 Reviewed-by: David Faure <david.faure@kdab.com>
* CMake: Make a few more auto tests standaloneAlexandru Croitor2024-03-141-0/+6
| | | | | | Pick-to: 6.7 Change-Id: I80988114bd906447a2ab712d5432a489e095a5c1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* QTypeRevision: use comparison helper macrosIvan Solovev2024-03-132-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | | QTypeRevision consists of two quint8 values: major and minor version. Each of the versions can be unknown. The rules for comparing with the unknown version are as follows: zero version < unknown version < non-zero version At the same time, two unknown versions are considered equal. This makes the comparison a bit tricky, but it still fits into the category of strong ordering. Replace the existing friend relational operators with helper functions and comparison helper macros, making this type strongly ordered. Update the unit-tests to use the new comparison helper test functions. As the test functions check the reversed arguments as well, we can reduce the number of rows for the data-driven comparison test. Fixes: QTBUG-120359 Change-Id: Ib6f1037fc7b5fed148e35ee48b56b05dcd36b3b4 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QTypeRevision: convert comparison test to data-drivenIvan Solovev2024-03-131-8/+39
| | | | | | | | | | This patch simplifies the checks when migrating the class to comparison helper macros. Task-number: QTBUG-120359 Change-Id: I47a6ba20d3b89c31edc2f432621eae9385fbd0a3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* qHash: make hashing of QLatin1StringView be the same as QStringThiago Macieira2024-03-121-1/+1
| | | | | | | Everywhere, except for ARM. Change-Id: I50e2158aeade4256ad1dfffd17b11ca2d57ad1fb Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* qHash: implement an AES hasher for QLatin1StringViewThiago Macieira2024-03-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's the same aeshash() as before, except we're passing a template parameter to indicate whether to read half and then zero-extend the data. That is, it will perform a conversion from Latin1 on the fly. When running in zero-extending mode, the length parameters are actually doubled (counting the number of UTF-16 code units) and we then divide again by 2 when advancing. The implementation should have the following performance characteristics: * QLatin1StringView now will be roughly half as fast as Qt 6.7 * QLatin1StringView now will be roughly as fast as QStringView For the aeshash128() in default builds of QtCore (will use SSE4.1), the long loop (32 characters or more) is: QStringView QLatin1StringView movdqu -0x20(%rax),%xmm4 | pmovzxbw -0x10(%rdx),%xmm2 movdqu -0x10(%rax),%xmm5 | pmovzxbw -0x8(%rdx),%xmm3 add $0x20,%rax | add $0x10,%rdx pxor %xmm4,%xmm0 | pxor %xmm2,%xmm0 pxor %xmm5,%xmm1 | pxor %xmm3,%xmm1 aesenc %xmm0,%xmm0 aesenc %xmm0,%xmm0 aesenc %xmm1,%xmm1 aesenc %xmm1,%xmm1 aesenc %xmm0,%xmm0 aesenc %xmm0,%xmm0 aesenc %xmm1,%xmm1 aesenc %xmm1,%xmm1 The number of instructions is identical, but there are actually 2 more uops per iteration. LLVM-MCA simulation shows this should execute in the same number of cycles on older CPUs that do not have support for VAES (see <https://analysis.godbolt.org/z/x95Mrfrf7>). For the VAES version in aeshash256() and the AVX10 version in aeshash256_256(): QStringView QLatin1StringView vpxor -0x40(%rax),%ymm1,%ym | vpmovzxbw -0x20(%rax),%ymm3 vpxor -0x20(%rax),%ymm0,%ym | vpmovzxbw -0x10(%rax),%ymm2 add $0x40,%rax | add $0x20,%rax | vpxor %ymm3,%ymm0,%ymm0 | vpxor %ymm2,%ymm1,%ymm1 vaesenc %ymm1,%ymm1,%ymm1 < vaesenc %ymm0,%ymm0,%ymm0 vaesenc %ymm0,%ymm0,%ymm0 vaesenc %ymm1,%ymm1,%ymm1 vaesenc %ymm1,%ymm1,%ymm1 vaesenc %ymm0,%ymm0,%ymm0 vaesenc %ymm0,%ymm0,%ymm0 > vaesenc %ymm1,%ymm1,%ymm1 In this case, the increase in number of instructions matches the increase in number of uops. The LLVM-MCA simulation says that the QLatin1StringView version is faster at 11 cycles/iteration vs 14 cyc/it (see <https://analysis.godbolt.org/z/1Gv1coz13>), but that can't be right. Measured performance of CPU cycles, on an Intel Core i9-7940X (Skylake, no VAES support), normalized on the QString performance (QByteArray is used as a stand-in for the performance in Qt 6.7): aeshash | siphash QByteArray QL1SV QString QByteArray QString dictionary 94.5% 79.7% 100.0% 150.5%* 159.8% paths-small 90.2% 93.2% 100.0% 202.8% 290.3% uuids 81.8% 100.7% 100.0% 215.2% 350.7% longstrings 42.5% 100.8% 100.0% 185.7% 353.2% numbers 95.5% 77.9% 100.0% 155.3%* 164.5% On an Intel Core i7-1165G7 (Tiger Lake, capable of VAES and AVX512VL): aeshash | siphash QByteArray QL1SV QString QByteArray QString dictionary 90.0% 91.1% 100.0% 103.3%* 157.1% paths-small 99.4% 104.8% 100.0% 237.5% 358.0% uuids 88.5% 117.6% 100.0% 274.5% 461.7% longstrings 57.4% 111.2% 100.0% 503.0% 974.3% numbers 90.6% 89.7% 100.0% 98.7%* 149.9% On an Intel 4th Generation Xeon Scalable Platinum (Sapphire Rapids, same Golden Cove core as Alder Lake): aeshash | siphash QByteArray QL1SV QString QByteArray QString dictionary 89.9% 102.1% 100.0% 158.1%* 172.7% paths-small 78.0% 89.4% 100.0% 159.4% 258.0% uuids 109.1% 107.9% 100.0% 279.0% 496.3% longstrings 52.1% 112.4% 100.0% 564.4% 1078.3% numbers 85.8% 98.9% 100.0% 152.6%* 190.4% * dictionary contains very short entries (6 characters) * paths-small contains strings of varying length, but very few over 32 * uuids-list contains fixed-length strings (38 characters) * longstrings is the same but 304 characters * numbers also a lot contains very short strings (1 to 6 chars) What this shows: * For short strings, the performance difference is negligible between all three * For longer strings, QLatin1StringView now costs between 7 and 17% more than QString on the tested machines instead of up to ~50% less, except on the older machine (where I think the main QString hashing is suffering from memory bandwidth limitations) * The AES hash implementation is anywhere from 1.6 to 11x faster than Siphash * Murmurhash (marked with asterisk) is much faster than Siphash, but it only managed to beat the AES hash in one test Change-Id: I664b9f014ffc48cbb49bfffd17b045c1811ac0ed Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* qHash: implement chunked hashing of QLatin1StringViewThiago Macieira2024-03-122-4/+50
| | | | | | | | | | | So that it hashes to the same value as QString{,View}. In order to test this, you must either run on a CPU other than ARM and x86, or disable the AES hasher. I did that and can confirm siphash and murmurhash do work with on-the-fly conversion from Latin-1. Change-Id: I664b9f014ffc48cbb49bfffd17b03e5e62ec4e89 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QHash: implement the heterogeneous non-const operator[]Thiago Macieira2024-03-121-1/+10
| | | | | | | | | | This complements the previous commit by adding the heterogeneous lookup in operator[]. Unlike the members of the previous commit, this one may insert into the hash, in which case it needs a way to cast from the heterogeneous type K to the actual Key type. Change-Id: I664b9f014ffc48cbb49bfffd17b037c1063dfb91 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QHash: add support for heterogeneous key lookupsThiago Macieira2024-03-121-0/+210
| | | | | | | | | | | | | | | | | | | | | | | This implements support in QHash and QMultiHash for lookups of heterogeneous key types that produce the same hash value. This is implemented by duplicating each of the following functions into an overload on Key and one a template that is enable_if-constrained to a key type that meets the requirement: * contains * count * equals_range * find * operator[] (const only) * remove * take * value * values (QMultiHash) The non-const operator[] may insert into the hash, so it's not part of this commit. Change-Id: I664b9f014ffc48cbb49bfffd17b037852f0fd192 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QSpan: add construction from initializer_listGiuseppe D'Angelo2024-03-061-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | P2447 has been merged in C++26, backport the same functionality. This makes QSpan<const T> a proper replacement for a const QList<T>& parameter, because now both can be built via a braced-init-list. // void f(const QList<int> &l); // old void f(QSpan<const int>); // new f({1, 2, 3}); // now OK This is, technically speaking, SiC: in the presence of both `f` overloads, the code above would have called the QList one. Now instead the call is ambiguous. We've been there already -- this is QString and QStringView all over again, and the solution is the same: get rid of the owning container overload. I'd rather have this construction *sooner* rather than *later* in order to minimize the fallout. And just like QString vs QStringView, there's nothing really doable to prevent instant-dangling situations: QStringView v = getString(); // dangles QSpan<const int> s = {1, 2, 3}; // ditto except for using QSpan (QStringView) as a *parameter type only*. Note that QSpan with dynamic extent was already convertible from std::initializer_list through its ranged constructor. However this fact alone doesn't unlock the above syntax. QSpan with a static extent was also convertible for the same reason. (This is non-standard: std::span's range constructor for static extents is explicit, but QSpan doesn't follow that design choice and makes the constructors implicit instead.) Found in API-review. Pick-to: 6.7 Change-Id: I160ab5b292b0c2568cd9a7ad1b4430085f475c29 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QList: add uninitialized resizesGiuseppe D'Angelo2024-02-161-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Creating a QList of a given size, or resizing it to a given size, will always value-initialize its elements. This commit adds support for uninitialized construction and resizes. The intended use case is using a QList as storage-to-be-overwritten: QList<int> list(size, Qt::Uninitialized); fillWithData(list.data(), list.size); How do we define "uninitialized": 1) if T is constructible using Qt::Uninitialized, use that; 2) otherwise, default-construct T. In detail: 1) covers (Qt-ish) datatypes that have a default constructor that initializes them, but also a dedicated constructor that doesn't initialize (e.g. QPoint, QQuaternion, ...). 2) covers everything else. Default initialization of scalars and trivially constructible datatypes will leave them uninitialized. A type which isn't trivially constructible will still get its default constructor called (and possibly actually gets initialized); we can't really do better than that, as we still have to construct objects and start their lifetimes. [ChangeLog][QtCore][QList] Added support for uninitialized construction and resizing. Change-Id: I32c285c7dddbf7e01475943f24e14e824bb13090 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QVarLengthArray: re-publish Prealloc as a nested PreallocatedSizeMarc Mutz2024-02-151-0/+10
| | | | | | | | | | | | | | | | | | This gives users of the class easy access to the Prealloc template argument, without having to write a pattern-matcher like template <typename T> constexpr qsizetype preallocated_size_v; template <typename T, qsizetype N> constexpr qsizetype preallocated_size_v<QVarLengthArray<T,N>> = N; first. [ChangeLog][QtCore][QVarLengthArray] Added PreallocatedSize nested constant, equal to the Prealloc template argument. Change-Id: I928eaa5e62967445cdd7b0c2759567483fdb8997 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* qHash: backport the q(u)int128-to-quint64 reduction trick to 32-bitThiago Macieira2024-02-121-1/+1
| | | | | | | | | | I didn't do it in a template because the 32-bit code requires a compatibility hack for Qt 6 and it's using an XOR of the high and low parts. Fixes: QTBUG-116080 Change-Id: I5dd50a1a7ca5424d9e7afffd17ae0ba5b9ff52f6 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Add missing qHash(qu/int128) overloadsMarc Mutz2024-02-121-0/+25
| | | | | | | | | | | | | | | | | | | | | | If we add the typedefs, we also need to add the qHash() overloads. See code comments for the explanation of how it works. I chose to use an addition to merge the upper and lower parts because of the comment in QHashCombineCommutative's operator(), introduced by commit 91b44afdcba3f4cb2ddc7a80c0cff723b408b447. Found in 6.6 API-review, but didn't make the cut and then was forgotten. Drive-by fix long line nearby. [ChangeLog][QtCore] Added qHash() overloads for quint128 and qint128. Fixes: QTBUG-116054 Task-number: QTBUG-116080 Change-Id: If484aed08ba476e0eace800b719f435203100f3e Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* tst_QHashFunctions: make the consistency check table-drivenThiago Macieira2024-02-121-72/+214
| | | | | | | | | | | So we can test more values. Because we are testing more values, we can't use QEXPECT_FAIL, because we can't guarantee a mismatch. Pick-to: 6.7 Task-number: QTBUG-116077 Task-number: QTBUG-116080 Change-Id: I664b9f014ffc48cbb49bfffd17b021719e6d612f Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QMap: add missing qHash() overloadMarc Mutz2024-02-091-0/+6
| | | | | | | | | | | | | | | | | | | Found in API review, but not deemed important enough to still get into 6.7. Not implementing it for QMultiMap, because there we need to mod out order of equivalent elements. The GHS compiler acted up and tried to compile the noexcept specification, hitting non-existing qHash(QVariant) for QVariantMap and producing a hard error instead of SFINAE'ing out. As a work-around, establish an artificial SFINAE-friendly context, but only for that compiler. [ChangeLog][QtCore][QMap/QHash] Added qHash() overload for QMap. Change-Id: Ia7dbf488e8e5490962118e40581b7c4cc8ed95e5 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QList: give the LWG 3346 #ifdef'ery a symbolic nameMarc Mutz2024-02-081-1/+1
| | | | | | | | | | | We'll need this in more places, so centralize its definition in qcompilerdetection.h. Amends 595b4e1a9b436a8190964dc41f79621400f5a6be. Pick-to: 6.7 6.6 6.5 Change-Id: I87f84cb9ff3ad339c000604423295180176f5799 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Remove extra semi-colonsTasuku Suzuki2024-02-061-1/+1
| | | | | Change-Id: I92fddb36cd136fd1bd627955f15d0559b9942d7e Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Change license for tests filesLucie Gérard2024-02-0458-58/+58
| | | | | | | | | | | | According to QUIP-18 [1], all tests file should be LicenseRef-Qt-Commercial OR GPL-3.0-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8 Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
* qHash: provide the long double overload on Darwin systemsThiago Macieira2024-02-031-2/+0
| | | | | | | | | | | | Commit c0791ac76ec7cfdc3945efa67a6f72ee3623413c didn't explain why it was #ifdef'ed out. It's just an alias for double. Maybe compilers at the time used to complain if you used it, but I can't make Apple's clang produce a warning now. Pick-to: 6.7 Change-Id: I664b9f014ffc48cbb49bfffd17b02293403e9571 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* QBitArray: use QDataStream::SizeLimitExeeded where applicableMarc Mutz2024-02-031-1/+1
| | | | | | | | | | | [ChangeLog][QtCore][QBitArray] Uses new QDataStream::Status::SizeLimitExceeded now, where applicable (was: WriteFailed, ReadCorruptData). Pick-to: 6.7 Change-Id: If5a8db9c6b2f104b40266784d88cf7cad0b0ce73 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QBitArray: don't create invalid Qt 5 streamsMarc Mutz2024-02-021-2/+10
| | | | | | | | | | | | | | | | | Qt 5 streams cannot handle QBitArrays with more than INT_MAX bits, even on 64-bit platforms, because of interface constraints (size_type int). Qt 6 can, so make sure to refuse serialization of oversized QBitArrays to Qt-5-compatible streams. [ChangeLog][QtCore][QBitArray] Now refuses to stream a QBitArray with size() > INT_MAX to a Qt-5-compatible QDataStream. Pick-to: 6.7 6.6 6.5 6.2 Change-Id: I263e27bd366757c8e0360dfd337948c44d00647a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QVersionNumber: make iterableMarc Mutz2024-01-311-0/+43
| | | | | | | | | | | Since QVersionNumber doesn't have an existing way to modify individual segments, provide only const_iterator. [ChangeLog][QtCore][QVersionNumber] Added (const) iterators over segments (begin()/end(), incl. c- and r- variants). Change-Id: Ia9af70c2a9c59f630123894ad2c9f38031ef5b8f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QBitArray: avoid overflow in size-to-storage calculationsMarc Mutz2024-01-301-0/+44
| | | | | | | | | | | | | | | | | | | | | | | Unlike other containers, a QBitArray's size() is not limited by storage, but, esp. on 32-bit platforms, its size_type: A INT_MAX size() QBitArray only requires 256MiB of storage. So we can't rely on "won't happen in practice" here and need to avoid the potential UB (signed overflow) in the (size + 7) / 8 logical-to-storage-size calculation by using unsigned arithmetic. Use the opportunity to Extract Methods storage_size() and allocation_size(), which differ by one (d[[0] contains the size() mod 8), making it clear what's what. [ChangeLog][QtCore][QBitArray] Fixed a bug with QBitArrays whose size() came within 7 of the size_type's maximum. Pick-to: 6.7 6.6 6.5 6.2 5.15 Change-Id: I5d94bae9c9c210ba1e36f8cf03609125c81bd15d Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QSpan: make adl_begin() etc SFINAE-friendlyMarc Mutz2024-01-261-0/+3
| | | | | | | | | | | | | | The definition of iterator_t, and, therefore, of is_compatible_range depends on this, otherwise say, 0, is being treated as a valid range and hits a hard error in adl_begin() when trying to call begin(int&). TIL: decltype(auto) does _not_ SFINAE. Fix by calculating the return type manually, re-enabing SFINAE. Pick-to: 6.7 6.6 Change-Id: Icacd70554f4050ecaeb396c9ae60bc4f21a220c9 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Optimize QSet::uniteAllan Sandfeld Jensen2024-01-201-1/+1
| | | | | | | Done similar to intersect. This also improves one test, as we get one less detach, and makes it consistent with other results. Change-Id: I4d08bf43e750c758b363f8e4fe1fe312a7a0cde4 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Dissociate QTypeRevision from QVersionNumberMarc Mutz2024-01-104-151/+187
| | | | | | | | | | | | | | | | They have nothing to do with each other, so give QTypeRevision its own header and implementation file instead of piggy-backing on QVersionNumber's. Picking back to current LTS to incur the merge conflict only once, not per (expected) follow-up change. Amends ed080c64ae21d22115d16780a5903d7cc4fd1546. Pick-to: 6.7 6.6 6.5 Change-Id: I2fa5d0e68f95864126bc95e3d8154134eee85553 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* tst_QHashFunctions: extend the consistency() test with mixed-signedness int ↵Marc Mutz2024-01-091-0/+19
| | | | | | | | | | | types Looking good, because all signed integral qHash overloads are implemented by casting to the unsigned type before hashing. Pick-to: 6.7 6.6 6.5 Change-Id: I8372eb6d4a57b40c2371db58d1b5aeabe9a3951a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QBitArray: add mutation operators taking rvalue QBitArraysThiago Macieira2023-12-141-6/+104
| | | | | | | | | | | | | | | | | Because we may be able to use the other side's storage and apply the operation in-place. We reuse the storage of the one that can be detached: even if we have to grow the buffer, QBitArrays are usually small so there's a good chance it's just to the extra space QArrayData usually overallocates or a simple, non-moving realloc(). Disassembly with GCC 13 and Clang 17 show the vectorisers did kick in for all four functions (inverted_inplace included). I think a hand-rolled version could squeeze a few more cycles, especially in the tail section, but I don't consider its maintenance cost to be worth it. Pick-to: 6.7 Change-Id: I85b3fc2dd45c4693be13fffd1795bfb1b296caa6 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QBitArray: add rvalue binary bitwise operatorsThiago Macieira2023-12-121-0/+52
| | | | | | | | | Now that the assignment-bitwise operators can reuse storage, we can make these operators also be capable of reusing storage. Pick-to: 6.7 Change-Id: I85b3fc2dd45c4693be13fffd1795b893de65a5b8 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QBitArray: improve memory allocation in the binary bitwise operatorsThiago Macieira2023-12-121-0/+66
| | | | | | | | | | | | Instead of creating a temporary copy of one of the two sides (which will share QByteArray), create one with the correct target size such that it is already detached. Drive-by move them to hidden friends. Pick-to: 6.7 Change-Id: I85b3fc2dd45c4693be13fffd1795b74eeaf3be71 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QDuplicateTracker: test with std::string, tooMarc Mutz2023-12-111-0/+23
| | | | | | | | | | | std::string is a nice value_type for when you want to track short strings (because of its SSO). Check that it works, incl. in case the implementation falls back to QSet in the absence of std::pmr support in the stdlib. Pick-to: 6.7 6.6 6.5 Change-Id: I2406258355295c2b1300c4ae8001cead59bb27d6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make QAtomicScopedValueRollback public APIRym Bouabid2023-12-083-4/+2
| | | | | | | | | | | Move the private header to public. Make documentation a part of public interface. [ChangeLog][QtCore][QAtomicScopedValueRollback] New class. Task-number: QTBUG-115107 Change-Id: I6c9f5448e74a5b62f4d97ee079944f4b1b731121 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* tst_containerapisymmetry: remove the extra push_backMarc Mutz2023-12-071-17/+17
| | | | | | | | | | | | ... and make sure it cannot happen again by using Extract Method to let the compiler do the counting between the resize and the sequence-of-push_back alternatives, because this author clearly can't. Amends 3c0fdd7341ed4bff9b5f041e9f4646265d142303. Pick-to: 6.6 6.5 Change-Id: If18f30d60f556e5e668876a38423f3e519fb79b0 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QBitArray: replace the member operator~ with a hidden friendThiago Macieira2023-12-071-0/+1
| | | | | | | | | | | | | | Which takes the array to be inverted by value, so we get free move semantics and allowing us to perform the negation in-place. [ChangeLog][Potentially Source-Incompatible Changes] The bitwise AND, OR, XOR, and NOT operator functions on QBitArray are now hidden friends. This may cause source-incompatibility in unusual coding styles (like 'array.operator~()') or with classes that have a casting 'operator QBitArray()'. Change-Id: I85b3fc2dd45c4693be13fffd1795ba1fbaf23769 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-13 06:49:21 +0000