Amends 8e5ce9cd36, which introduced the
QtPrivate::equalStrings() call. At that time, equalStrings() had already
required equal lengths (see 1560e0161a),
so no excuse.
[ChangeLog][QtCore][QCborMap and QJsonObject] Fixed bug that could
result in a crash or failing to find a entry in the map/object with non-
ASCII keys.
Manual conflict resolution for 6.9:
- Port from keyView() to key(), because the former is a 6.10+ feature.
Fixes: QTBUG-133744
Change-Id: I6b0f8b0a2e47d3ef905afffda6c4c079814a0914
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 54daec43a041cb69cff31cbfd1dd0b7127e8ba87)
(cherry picked from commit 8e94b67ba11fecfee134950eaae5c5b29812e82c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit d4a90a3f3013eae4e837fbd2df63d5803f19608a)
This extends the test with a few more rows, and with delimiters that the
Apple APIs seem to encode differently. Rather, it's QUrl that deviates
slightly from the standard: we keep the delimiters unchanged,
regardless, like browsers do.
Task-number: QTBUG-134073
Pick-to: 6.5
Change-Id: I20a7b66a9959b17597cffffdf3652b9167d00d07
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 31753e722cd441de371be8f1e11b3bf089b187e2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 6deb5098a10b8b3fdfab0aab51c6bf78c0dce7f4)
QUrl has an intentional deviation from RFC 3986 when it comes to those
characters, matching the behavior of major browsers: we distinguish the
forms '[' and ']' from their encoded forms. However, for local files,
they are definitely identical, because there's no such thing as a
percent-encoded file names.
[ChangeLog][QtCore][QUrl] QUrl::fromLocalFile() will now decode the
square bracket characters '[' and ']' to their percent-encoded forms.
This will be visible in calls to toString(), toEncoded(), or the encoded
form of path(). QUrl's comparison operator will consider the old
(created from an encoded URL string) and new forms to be different.
Fixes: QTBUG-134073
Change-Id: I9eae083007103e34f73cfffd59a618069eba0e19
Reviewed-by: David Faure <david.faure@kdab.com>
(cherry picked from commit 5e936b60fc921e21b8153a83113886a1de333b57)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit de3cf05b77e595a7cb8700e34b232c5dc0a4e76a)
Basically this should work exactly the same as constructing the
QUtcTimeZonePrivate directly. Follow-up performance optimizations
should not change any of this behavior.
Pick-to: 6.5 5.15
Change-Id: I2a3e78965f3a553b8b70cb12f7772b9fdfbf7bf7
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 7a79ce13a93aab724e8943d83fc903c88466d053)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 9cba61e5eb7cbbfb197f2b90d33b294e43291065)
Some time ago, we spent a lot of time fine-tuning the behavior of
indexOf() and split() w.r.t. matching of empty needles, or in empty
haystacks. Make sure that (QByteArray) replace() is behaving
consistently.
It isn't. Filed QTBUG-134079 to track the issue.
Pick-to: 6.5
Task-number: QTBUG-134079
Change-Id: I16af5d2bb5b309a56e81854be434fa9430ae284f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 5fc1e9fa0c1925654412af5bf46ff95da99bc190)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit c653cf1171d6ccf8a8036d8b396e57465b9a7d4e)
We were accidentally closing it along with all the other file
descriptors if the CloseFileDescriptors flag was active. That meant we
were unable to report start problems back to the parent process.
So instead of closing everything immediately, we simply mark everything
as FD_CLOEXEC so they'll be closed by execve()'s success. Because we're
using CLOSE_RANGE_CLOEXEC now to detect the system call, we don't need
the configure-time test.
[ChangeLog][QtCore][QProcess] Fixed a bug that caused QProcess not to
report start failures if the UnixProcessFlag::CloseFileDescriptors flag
was active.
Change-Id: I4d81d763281354e886d9fffd56ef6ab8b6115715
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
(cherry picked from commit 3d007ff2e9caf328f92d65f71a94fd869552b1b6)
(cherry picked from commit 01010851cb61f5d7964ba2317defb67cdfcb72f5)
Coverity complains that qCountLeadingZeroBits() may return 64 and then
the RHS will be out-of-range for int. Of course, 64 leading zero bits
means that the argument is 0, which we excluded in the first `if` of
the if-else chain.
I can only guess (because it doesn't tell me which value of `bytes` it
is using for the analysis) that Coverity assumes bytes ==
numeric_limits<qint64>::min() and considers the overflow in qAbs() to
yield a 0, because, it being UB, it may yield anything.
Be that as it may, the fact remains that formattedDataSize() invokes
UB when passed numeric_limits<qint64>::min(), as confirmed by ubsan:
global/qnumeric.h:479:26: runtime error: negation of -9223372036854775808 cannot be represented in type 'long long int'; cast to an unsigned type to negate this value to itself
text/qlocale.cpp:5062:82: runtime error: signed integer overflow: -2147483648 * 3 cannot be represented in type 'int'
text/qlocale.cpp:5062:26: runtime error: division by zero
FAIL! : tst_QLocale::formattedDataSize(English-Decimal-min) Compared values are not the same
Actual (QLocale(language).formattedDataSize(bytes, decimalPlaces, units)): "-inf bytes"
Expected ("output") : "-9.22 EB"
So fix the overflow by using the new QtPrivate::qUnsignedAbs(). Then
sit back and await Coverity's verdict on the next run.
[ChangeLog][QtCore][QLocale] Fix issue when calling
formattedDataSize() with numeric_limits<qint64>::min().
Amends 9d23aebb27.
Pick-to: 6.5 6.2 5.15
Coverity-Id: 474294
Change-Id: I9a5a5acbdcf881a624bb827ca1dd970771f1bb6e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit b93575de01760ff2ab0d817557a642c71cdb4414)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 6cefb8be965759cc022ce3ef1ae7a722f0566ce7)
The ensureLargeData() and 'large' members were only used in BigData
tests that have since moved to a different executable.
Amends fff217824b532da7306af1ac755581e76e098a27.
Pick-to: 6.5 6.2 5.15
Change-Id: Idc99a868e082098dda4e1bee62470370c7e20f62
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 5cd046f154a0a31635c935bf6c9f1abd27837b80)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 9479f9bbfc24d603df66993388a50200641fabd2)
The SHA-1 test has started to time out in CI ASAN builds recently, so
skip it there. Keep it on non-CI or non-ASAN builds, though.
Amends c6e092a5f8.
Pick-to: 6.5 6.2
Change-Id: I8d653c2a8304cfae290befafda570d5c49dd4536
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 929466ba64c503cc1a7c6205f0a424350a9a201f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 76783a4487b8b8fbe6b7e8b066bccfefef7ba912)
With those tests split, tst_QCryptographicHash takes about 4ms.
When FEATURE_openssl_hash is enabled those tests take about 15s on
their own, but when openssl_hash is disabled they take about 2 minutes.
That makes running the tests locally a bit of a hassle when hacking
code ... test ... hack ... test.
This is with a debug build, GCC, `-O0 -g` flags.
Pick-to: 6.5 6.2
Change-Id: I8b8f5d1954feb1f9eb8115e27635610a41b42f47
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit fff217824b532da7306af1ac755581e76e098a27)
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
... not just int, and not just non-negative values.
Reveals a problem with bytes == numeric_limit<qint64>::min(), says
ubsan (example; all min64 fail):
global/qnumeric.h:479:26: runtime error: negation of -9223372036854775808 cannot be represented in type 'long long int'; cast to an unsigned type to negate this value to itself
text/qlocale.cpp:5062:82: runtime error: signed integer overflow: -2147483648 * 3 cannot be represented in type 'int'
text/qlocale.cpp:5062:26: runtime error: division by zero
FAIL! : tst_QLocale::formattedDataSize(English-Decimal-min) Compared values are not the same
Actual (QLocale(language).formattedDataSize(bytes, decimalPlaces, units)): "-inf bytes"
Expected ("output") : "-9.22 EB"
So exclude that from testing, for now.
Pick-to: 6.5 6.2 5.15
Coverity-Id: 474294
Change-Id: Ia1f8e87c58a9fdc2668b6745956e913384cff4c7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit 562cb8e4d9c5e6482b8c6b85fbb6f735d3000ad2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 173eebbd968e55fbce6833d4c0699dd71aacf6bc)
They added some new scripts.
There were a few changes to the line break algorithm,
most notably there is more rules that require more context than before.
While not major, there was some shuffling and additions to our
implementation to match the new rules.
IDNA test data now disallows the trailing dot/empty root label,
technically to be toggled off by an option that controls a few things,
but we don't have options. For test-data they changed the format a
little - "" is used to mean empty string, while a blank segment is
null/no string, update the parser to read this.
Changes in this cherry-pick:
- Reran tool to resolve conflicts due to
emoji-data not being extracted in this branch
[ChangeLog][Third-Party Code] Updated the Unicode Character Database to
UCD revision 34/Unicode 16.
Fixes: QTBUG-132902
Task-number: QTBUG-132851
Pick-to: 6.5
Change-Id: I4569703659f6fd0f20943110a03301c1cf8cc1ed
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit 85899ff181984a1310cd1ad10cdb0824f1ca5118)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 5985c90d37a096f35b68546f916bec29a218e112)
Neater and more debuggable. This code was added in Qt 5.4, before we
could use C++11.
Pick-to: 6.5 6.2 5.15
Change-Id: Icd8acccb4a9ae1f500e7fffdc4d4fc7c310cbb89
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit b888bc09ce33a91800cb2119a52097897f3d62d1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit ddd0a084905bb0b52f941c151e84a40821527329)
This meant a string containing the octal form of INT_MIN (-020000000000)
would be just too long and getenv_s() would fail. This was never caught
because code that was meant to test different bases simply forgot to use
the base. Amends commit bb56586e32.
I've renamed the rows to be the text being parsed, so it matches the
previous rows and it makes clear what was being parsed just by reading
the test's output. That also revealed a duplicate row to be removed.
[ChangeLog][QtCore][QtEnvironment] Fixed a bug that caused
qEnvironmentVariableIntValue() to fail to parse octal values from
-020000000000 to -010000000000 with MSVC. Other compilers were not
affected.
Pick-to: 6.5
Change-Id: I9095d86cccd9e8001e85fffd6fbbcd6a9a1678c3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 83f2d1130aa49228a8a87547660791708735dd4b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit ff7675817d9e31c261ddaca81ca7f58a362d8295)
This is what QDir::isRelativePath() does, for better or worse. We've
used QDir::isRelativePath() before and we shouldn't change the behavior.
Amends commit c74cba1117355a6312b1f0cc815efa4cdea4bbfa
Change-Id: I03e3e921977af2b9c6ff2593535d846d6ce28fe2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit dd2dc8c70d0227ff235a8c7feaca7d7c4ead9c63)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 3fd08e19d4fe2b0299394ef6506d5263b67a57fa)
Otherwise we would traverse beyond bounds.
We calculate the delta in sizes between the haystack and the needle and
if this delta is smaller than the starting position
(the `from` argument) then we start from there.
The default value for `from` is size(). With the needle being longer
than the haystack, the delta is negative and we set our starting
position to be the delta, i.e. we start before the start of the
haystack.
[ChangeLog][QtCore][QByteArray/QByteArrayView] Fixed a bug in
lastIndexOf() that could lead to out-of-bounds access when the needle
is longer than the haystack.
Pick-to: 6.5 6.2 5.15
Change-Id: Id5cd772f00b0c3c50fbf61b4e888bba5587391ee
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit d25e5e2cb78a2e2f2a1791fed250421ce9eefc46)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 9a634a5c4b7e51bf1ae27e1f1111c41f019e3238)
That's not a valid type for the Standard's string, because the Standard
doesn't allow for std::char_traits<signed char> either.
Fixes: QTBUG-133689
Change-Id: Icd0d4928fa4cdc9d806bfffd4053f0eb1073e6b4
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 0cc41083c30c1474a862a34b59a4f755d4c51640)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 5b10a1e8b4137cd8031f100039c39a1cc93f5d4e)
On Windows, using a URL of "file:///c:/" as a base to be resolved with
"../" should not result in the Windows drive being removed.
[ChangeLog][QtCore][QUrl] Fixed a bug (regression from 6.7) where
resolving a base URL of an absolute file path containing a Windows drive
could result in said drive being removed (e.g., resolving "file:///c:/"
with "../" would result in "file:///").
Fixes: QTBUG-133402
Change-Id: I58286b9c5e5d02363f0efffdb06f983b560340df
Reviewed-by: David Faure <david.faure@kdab.com>
(cherry picked from commit 340c9d88ab353e201f117d64609fa5f7d2fa2b21)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 8c5736e68f9619a6f2f223c7363a820e528d089c)
We set it when manipulating full URLs. If you're creating them from
parts, you may end up with one without a host. We will still fix that up
in QUrl::toString() ("manipulates full URL").
This allows the path normalization code to avoid accidentally creating a
URL with no host/authority and with a path that starts with double
slash.
[ChangeLog][QtCore][QUrl] Fixed a bug (regression from 6.7) where
QUrl::resolved() could create invalid URLs when the relative URI being
resolved contained a path with double slashes (e.g., combining
"scheme:a" with "..//b.txt")
Fixes: QTBUG-133403
Change-Id: I3fe9d5fbd2efcaa66d66fffdc010e5a84066b641
Reviewed-by: David Faure <david.faure@kdab.com>
(cherry picked from commit 7d05f5ed7d3472028e28a09eeda175bb1b1eeb00)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 86597d289116789463e905d3fdcdb3850f4b5918)
AllowUncPaths (and the whole enum) is private API that is always enabled
only on Windows (build-time decision). So, remove it and change the
unittests to match reality. Now DefaultNormalization on Windows implies
handling UNC paths.
This was suggested in code review by Thiago; since this is a hot code
path, the goal is letting the compiler keep the flags parameter to
qt_normalizePathSegments() in a register, by keeping the
PathNormalization enum as small as possible.
Drive-by change: since those lines in the unittest are changed anyway,
take the chance and use u""_s syntax.
Change-Id: I3dcf30d888a0ea9f8898e260e65c5f85655296d5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 4f47ee4de46f1fa2df9fef163590807e2fae28d1)
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... for local URLs too.
For example normalizing "/Users/sam/troll/qt4.0/.." by following the
alogrithm at https://www.ietf.org/rfc/rfc3986.html#section-5.2.4:
- replace "/.." with a "/" in the input buffer, then remove the previous
path segment from the output buffer up to, and including, the
previous "/"
- next iteration will find the input buffer starting with a "/" which
is moved to the output buffer; the final result would be:
"/Users/sam/troll/"
Remove the KeepLocalTrailingSlash enumerator, it's become redundant with
this change.
De-duplicate a row in tst_QDir.
[ChangeLog][Important Behavior Change] Aligned how QDir and QUrl
normalize paths with respect to preserving a trailing slash. That is,
QDir::cleanPath("/b/.") and
QUrl("file:///b/.).toString(QUrl::NormalizePathSegments) will return
"/b/" and "file:///b/" respectively. For more details see:
https://www.ietf.org/rfc/rfc3986.html#section-5.2.4
Task-number: QTBUG-128940
Change-Id: Id5a4bdab14e7312a60b1b54de07e5d9f3e8aa40a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit ec894d694506fcce75fc9643f08dfb1c79f64c8b)
Introduce a helper function to silence this lengthy warning, and use
it consistently in all places where the warning was triggered.
Amends 502a7706b9 which introduced the
warning.
Pick-to: 6.5
Change-Id: Ifa5c7e0182a12885af4db42ef5d68b1f27a0c6bc
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit a30289ee0be41e8311aef6d8737885b354a9f047)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 08ef73f94f6428f8cefc0386980b2ba1f63bee84)
QAnyStringView is designed to replace overload sets containing QString
and QChar, among others, so it needs to accept types that merely
implicitly convert to QString and QChar. It achieves this by
maintaining a hidden container to hold the converted QString or QChar
for the duration of the full-expression, much like the compiler would
do if the function took QString/QChar.
This patch adds a check for the single-char ctors to determine whether
they convert or not, by comparing QASV::data() to the address of the
QASV's argument. While it would be interesting to have the same test
for QString, that is outside the scope of this patch.
Task-number: QTBUG-126054
Pick-to: 6.5 6.2
Change-Id: I30ac2d1199da5a03fe6fee4c9d5ea2a209a003d6
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit f31c37a1312fc4e21a58906e2b883099629fb9e1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 18b56bbae2cb1e775b5155f8fc019081780a9867)
It was using int for two flag columns; we can pass the relevant flag
types now, and we get better type-checking by doing so. Expand the
integral numeric column from int to qlonglong, since that's the type
we actually end up with by the time we're asking QLocale to do our
formatting for us. Add test-cases for things we've lately noticed
aren't right, notably including the min-qlonglong test (which passes
because compilers handle the UB straightforwardly), that needed the
integral numeric column's expansion. Sign-handling for negative values
in hex fails; a later commit shall fix and remove the QEXPECT_FAIL().
Pick-to: 6.5 5.15
Task-number: QTBUG-133269
Change-Id: I39c5339b144b40a30886d8253fa464828ed87629
Reviewed-by: Mate Barany <mate.barany@qt.io>
(cherry picked from commit 5a230596c8c1f63e662ce17e094e2ae187066d6d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 055b5a83b4b1fa224b075cbc35490e8e2db2225c)
The test is flaky every now and then on the CI, so increase the timeout from
5s to 20s (a previous TRY_VERIFY precheck reported just shy of 10s waiting
time, doubling should be™ sufficient).
Amends the start of the public history.
Pick-to: 6.5 6.2 5.15
Change-Id: I8e64bf8ac1576c0ac71790a03936635016b3b2b7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 40e65f029341a01e16dc88871eb7b24979aea9bf)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 267acbc534095b17b139fb819ee854baf3c0f24b)
When UUID definitions are placed within Qt namespace MinGW build fails because specializations of struct __mingw_uuidof_s are now defined in a different namespace.
Fixes: QTBUG-133516
Pick-to: 6.5
Change-Id: I49270aa2a892d407675dab7b90d3929d120c5224
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
(cherry picked from commit 84b7cef13913139b2ed7e506ace0fa6b97269829)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 775d56f01d39c438c48397bdd571a607fb03abc3)
The selection of which set to iterate over and which one to remove
from based on their relative size violates the function's
documentation, which clearly states that items are removed from *this,
and not from `other`, so the result must never contain any elements
from `other`.
Amends 4f2c96eaa8. Instead of reverting
to the gruesome old code with the forced detach-just-to-remove copies,
distinguish four cases:
- if the two sets are shallow copies of each other, then their
intersection is *this
- otherwise, if either set is empty, clear() *this. This is required
for one of the tests that 29017f1395
added to succeed.
- otherwise, if *this is detached, perform the operation in-place,
using removeIf()
- otherwise, create a new set and move-assign to *this to avoid
detaching just to remove something again. In this case, we can
continue to iterate over the smaller set, but we need to keep
picking elements from LHS into the result.
[ChangeLog][QtCore][QSet] Fixed a regression (introduced for Qt 5.2)
in intersect() that caused equivalent elements of `*this` to be
overwritten by elements of `other` if `other.size()` was larger than
`this->size()`.
Not picking to 5.15, as users will have likely adjusted their code to
the buggy behavior, and because removeIf() isn't available there.
Pick-to: 6.5
Fixes: QTBUG-132536
Task-number: QTBUG-106179
Change-Id: Idfa17c3b3589c4eacec27259fc01df6aeaa6c45f
Reviewed-by: Øystein Heskestad <oystein.heskestad@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
(cherry picked from commit 162015e9c6f469951d9212ef655cff16dcace071)
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit eb13efc4a606cdb0c6f785a6319c489ad53626f3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This reverts commit 92acc94fa9.
The change broke QSet ordering guarantees: The documentation clearly
states that each item from `other` that isn't already in `*this` is
inserted ("STL insertion behavior"). Swapping *this and other breaks
this.
Independent of STL vs. Qt insertion behavior, making the picking of
elements from containers "random" in the sense that the size of the
container is now important, and not merely LHS vs. RHS, is a bad idea.
[ChangeLog][QtCore][QSet] Fixed a regression in unite() that caused
equivalent elements of `*this` to be overwritten by elements of
`other` if `other.size()` was larger than `this->size()`.
Fixes: QTBUG-132500
Change-Id: Ia636b62325139d618b5467a643ff710716324296
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit 2d1b3028673493cb144060cbec49b1b95f4188d2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 3dff1a3f7b22bc623b3c326630bfd94d2bd35d08)
In Qt versions 5.0..6.7, at least, this used to be the implemented
behavior for unite(). For intersect(), it was implemented up to and
excl. 5.2. Even the documentation states as much:
intersect(): Removes all items from _this set_ that are not
contained in the other set.
unite(): Each item in the other set that isn't already in this set
is inserted into this set.
Add checks that the functions behave as documented (hint: they no
longer do, since 6.8 (unite()) and 5.2 (intersect()), resp.), this
being the only correct way to implement these functions (items in
sets may be equivalent, but not identical; it is important that the
set operations work in a manner consistent with insert(), to meet
user's expectation of how these functions work (unite() just
inserts() the rhs, intersect() removes if !rhs.contains). Note that
QSet, unlike other Qt associative containers, actually has STL-style
insertion behavior (insert() doesn't overwrite).
subtract() is the only one that's still true to its docs. A test for
this function will be added in a follow-up commit - eventually.
In anticipation of adding rvalue-other overloads of at least
unite(), add a test with that, too.
Pick-to: 6.5 6.2 5.15
Task-number: QTBUG-132500
Task-number: QTBUG-132536
Change-Id: Id309ab5192e6d1c9bbeef496cbd7116d306eaae8
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit 0d4fd5c545b47966c56ed0b9eb9b5c0a8f75c02a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 12f39bb2ab0e2bbf70c538af7b36014024b5901a)
It can't, pfew. Was wondering for a moment, but of course, even the
QSet::iterator is really a const_iterator.
Pick-to: 6.5 6.2
Change-Id: I85caa64c1caca6d77569aa2ceb868a4aa0e5578d
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Magdalena Stojek <magdalena.stojek@qt.io>
Reviewed-by: Lena Biliaieva <lena.biliaieva@qt.io>
(cherry picked from commit a4fd95c51a4347482d6d0a815657d0b5bdaf06db)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 9120bb9e0393bd10e73510d0103bc330f5b92696)
The pmr::monotonic_buffer_resource ("pmr::mbr") strategy can only
allocate buffers; deallocation is a no-op. I chose it for
QDuplicateTracker because the tool was only used one-off: build it,
then destroy it. There were no other operations.
That changed when 090c7e3262 added
clear().
Calling pmr::unordered_set::clear() will deallocate the nodes (but not
the bucket array), but due to pmr::mbr, nothing is actually
deallocated, so memory that was freed by the container isn't actually
reused by it, later. IOW: repeated grow-clear-grow-clear cycles would
forever grow the monotonic_muffer_resource, using more and more memory
and thus appear to be leaking it.
This isn't exactly optimal behavior, so try to shed the pmr::mbr's
extra memory with a call to mbr::release().
Unfortunately, C++17 originally failed to nail down the semantics of
pmr::mbr::release(), prompting LWG 3120 in response to observed
implementation divergence. In particular, MSSTL, at the time of LWG
3120 filing, didn't appear to allow to allocate() after release(). In
our tests, it does allow it, it just never falls back to the original
(stack) buffer, and, looking at the implementation, it doesn't look
like it can do so anytime soon (it doesn't remember the buffer, and
everything is inline, so they would seem to need a BC break to fix it.
We tried to work-around the problem by hard-resetting 'res' by going
through a destroy-recreate cycle. pmr::mbr is neither copy- nor
move-constructible, so that blunt instrument is, unfortunately,
necessary (std::optional would be an alternative, but has overhead
that affects all platforms). This crashed, though, so just call
release() and handle MSSTL's failure to reuse the initial buffer as a
QoI issue.
For all platforms, before release(), we also need to make sure that
`set` no longer holds any references into it, and, since clear()
doesn't shed capacity, we need to use the C++11 version of the
swap-trick (swap is actually UB here, because the allocators differ):
move-assign a default-constructed set.
Amends 090c7e3262.
Fixes: QTBUG-132945
Pick-to: 6.5 6.2
Change-Id: I4796806e427602255439dcb1518aa9b661c7933e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 9f4325e67354ce6c4c98e7a206f17729b378dc04)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit d2c4f6df21629495ce6fe32653037b35a989d6f4)
QSet::remove() calls QHash::remove(), which unconditionally detaches,
so fixing the detach there, by pulling the isUnused() check to before
detach(), fixes it for both.
For removeIf(), the old code used begin()/end() for iteration,
detaching unconditionally, even if nothing was removed in the end.
In this case, fix by using cbegin()/cend(). That delays the detach()
until the first erase(), where it belongs. The end() iterator of QHash
(and therefore QSet) are stateless sentinels in all but name, so we can
continue to cache end(). Add a code comment to that effect.
Amends 62dad9be9e (for removeIf()) and
5b7c3e31b5 (for remove()).
[ChangeLog][QtCore][QSet] remove() and removeIf() no longer
unconditionally detach, but only if something is actually being
removed.
[ChangeLog][QtCore][QHash] remove() no longer unconditionally
detaches, but only if something is actually being removed.
Pick-to: 6.5
Task-number: QTBUG-106179
Fixes: QTBUG-132831
Change-Id: I807577eafa1be478b0a2da45cf8c44936d5e48ed
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
(cherry picked from commit 3a284dc19d1c77692f2faddedc674cc293d51a00)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 605a20b2624dac1bfc4a4cb683700db5026bdbe8)
QTextStream's operator<<(number) uses qAbs to extract the "absolute
value" of number, and passes that and the number's sign to an internal
formatting function. However qAbs is unsuitable for the task, because it
will fail if `number` is minimal, as it returns the same type of
its input.
Since we can afford to change the type of the result, call the private
qUnsignedAbs() function instead.
Change-Id: Ib813a199503f2d07c78bb76862ab2e15d68d0ec2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 8f762b546fe6b2254029c4804a32d9ae6bbf4495)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit b50f026c5586bb31d0611ca570a40e77d5e4eb43)
Checking qAbs preconditions reveals that several places into Qt are
calling it with minimal values, causing UB. Those places do not actually
need that the absolute value is of the same type as the parameter.
Therefore, introduce qUnsignedAbs, which is like qAbs() but whose return
type is always unsigned, and therefore can accept everything.
This function is private; I don't want to encourage users to rely on our
extension.
Aggressively cherry picking because this will be needed in subsequent
bugfixes.
Change-Id: I2047768a5fd35f12bf898ca8c2008813434edd8d
Pick-to: 6.5 6.2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 83c812e1322a2b004bc604be3e6f61fb83246eb0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit ad867197cf02043f9ec67363b020ac08405b0ab1)
QRect::width() and height() may overflow: they're only safe to call
when right-left+1 (or bottom-top+1) is representable by an `int`.
Therefore, avoiding calling them from QDebug, which is supposed to
"always work" (otherwise, it's not of great debugging help...).
QRectF does not have this issue as it stores the width directly.
Change-Id: I438dbacae42c17730afb92f05d16e3eebb161255
Pick-to: 6.5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 0f336500a0add3e3a8bb31c5cc605e5e13e23833)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 8232c837b02885b6e143e6982bda3ef19e4017fa)
We were including, for each entry we got from CLDR or the system,
minimal and maximal additions from CLDR's likely-subtag rules, plus
versions with script omitted and possibly also territory added, when
likely-equivalent to the original. Include also the converse, with
territory omitted and possibly also script added when
likely-equivalent, so as to control order when these entries also show
up by truncation of others.
The pick to 6.8 was bound to get conflicts and is really a back-port
of reasonably future-compatible behavior to the 6.8 code-base. Results
from uiLanguages() itself are not the same as in 6.9 - truncations are
not included, because QTranslator takes care of those. It includes,
from commit cbf49f735e3cca85922a85d6548666816686db78 and earlier work
on 6.9, various test-cases adapted to this altered aim. It also fixes
some minor details that I'll now forward-port to dev and pick back to
6.9, that I worked out how to do while wrestling to make those
test-cases produce sensible results.
Task-number: QTBUG-131894
Change-Id: I363bfe31867be43807fe3b4942dafa186b8d2e94
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 7f9ee43de783105d8de0a0b614751eec639131f8)
(cherry picked from commit 45c9a35d359381419f529ba36a5381b1302bf0f4)
The code relies on -Wswitch, but lacked the Q_UNREACHABLE_RETURN() at
the end that compiler and code readers need to understand that we don't
accept values other than those enumerated, even though an enum variable
could hold other values, too.
Since the function is constexpr, can't use that macro directly, but
need to copy the usual GCC 8 magic incantation.
Amends 171ff57be1b8fd1c1b33cffbffa389790f239b5c.
Change-Id: I6c9dd0e4178211f57da61aa6df70f8036370f158
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 420ca3463ee8adf2d986af5802d8da4bb24ce14d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 760688cc754f7f84c10596345e488055ed511cfc)
This fixes an issue where comparing pointers to object is only defined
if both pointers point into the same array.
Task-number: QTBUG-132507
Change-Id: Ib7ccb30001add38ad25b62c848a01cd53566d8bf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 5dcdeeebbc08be8845cdb5a0e586b7a864b7f16f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 99d401220c3b200e76f00cb7457a5a3935379572)
When even some values I haven't seen may need to be left for later,
but values I have seen are definitely to be discarded, I need to know
if I've already processed them before doing the fiddly check for
whether to defer; but if I decide to defer, I haven't yet processed
and need the later check, to which I've deferred, to see the value as
still new, even though I did once ask about it before. So I need a way
to query without adding to the set.
Pick-to: 6.5
Change-Id: I712f1c400147210c149aeec6de1d15d2e095d6a9
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 09b77a8d07276e0b5e5fec596f957f8fc4a78869)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 007c0a1854e0bcf6bbe6965fbc24ff1ae6a43cc5)
This commit adds one unusual creation and three more unusual exits:
* creation of the Q*Application in a thread (QTBUG-130895)
* exits using ::exit() instead of returning from main():
* from the main thread's event loop
* from an auxiliary thread
* from inside an auxiliary thread's event loop
All of these exercise the moment the QAdoptedThread & QThreadData for
the main thread is destroyed, which are, respectively:
* thread exit time, running thread-specific destructors
* inside exit(), running atexit()-like callbacks (qthread_*.cpp)
* [tst_static_q*application] inside exit(), running static destructors
(added in commit 1da7558bfd7626bcc40a214a90ae5027f32f6c7f)
Unlike the tst_static_q*application tests, the calls to ::exit() cannot
be a regular QtTest because that would cause the log output to be
incomplete. The threaded Q*Application could be a test of its own, but
since I needed to add the helper anyway, I chose to add the test there.
For the majority of the tests, the failure mode is going to be a crash
on exit.
Task-number: QTBUG-12673
Task-number: QTBUG-132429
Change-Id: I1062ef500356bd97dd0cfffda4aeeda9afa138e8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit bfbd1a281dd00c47df315c06e895bf5d53cd8764)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit ea6d467c050c9e4ab58f970f6720b428ec43c8e2)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The code was duplicated in multiple places.
Pick-to: 6.5
Change-Id: If2ab30b7afbf6d2f99c9fffd999218802b734d5e
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit b119fee87d5579dc1c4bfc2f508b0e3a75d69fa3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit f9bdb80ef1f0d56d9585df61f0e209fe0b718443)
And remove NOLINT(clang-diagnostic-self-move), silencing the warning for
Clang seems to work for clang-tidy too (tested locally).
Amends 03bd9491491881529ad28cd6d672edfdda9a0065.
Change-Id: Ibdf982a728f2c6150f2911173dc3c9246f3662b8
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 6f0f39673f5ae9debd9ab59be60c32f00f40c41a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 55f8c072a301c55eda37c2b39dbcb0d579b3f414)
As we produce crash reporting via Swift on macOS 15 now.
Change-Id: Iab4777b29bcaa66eff9d2f1de63072f5744d56df
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit dbfc3c9c381aa1cc0ab3cf5b758b38fb4499cb39)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit ee97f24ef47594c97aaabe034169df7f78a5c884)
The bug, QTBUG-121418, was actually fixed earlier by commit
84afaafc9c6968dd76fcadc5392065d340543521 (or, for 6.8, commit
8c40e8cf12), but escaped our attention
at the time.
On picking to 6.8, where the issue is fixed in QTranslator rather than
QLocale::uiLanguages(), omit the truncated entries from tests of the
latter. Also add commit 84afaafc9c6968dd76fcadc5392065d340543521's new
tst_QTranslator::loadLocale_data() "System, mixed dialects" test-case,
which commit 8c40e8cf12 skipped, despite
actually making it work.
Fixes: QTBUG-121418
Change-Id: Ie24eb172674189079aede7a39584ea760aac1b0c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 12f8ebf5cbdc9089564a93001926d20908bd1785)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit ee65d651a4cda48a9ed9636aecd45306d0f737d0)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Thiago Macieira
Milian Wolff
Marc Mutz
Ahmad Samir
Mårten Nordheim
Ulf Hermann
Ivan Solovev
Volker Hilsheimer
Edward Welbourne
Pavel Dubsky
Giuseppe D'Angelo
Jøger Hansegård
Tor Arne Vestbø