Issue introduced by commit 465701bb98.
[ChangeLog][QtCore][QMetaObjectBuilder] Fixed a bug that would cause
addProperty() to use the incorrect type for the property if the
property's name matched a valid type registered with QMetaType.
Pick-to: 6.2 6.3
Change-Id: Ic15405335d804bdea761fffd16d402f2c9611f30
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Inline the content to avoid a round-trip through qjsonarray.cpp and
qjsonobject.cpp.
This change revealed an inadviseable unit test check that dereferences
the end() iterator to get its type. I haven't changed it, but have
marked with ###. I also fixed a likely copy&paste mistake in that test.
Change-Id: I89446ea06b5742efb194fffd16bb774f3bfbe5f5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Commit 35adb74ddd ("Reimplement JSON
support on top of Cbor") accidentally forgot to multiply by 2 the index
stored in the QJsonObject::iterator. The same mistake was propagated
when QJsonObject::iterator was converted to QJsonValueRef. This had no
ill effects because the o->elements container would always contain more
elements, but it meant the check was ineffective and meant nothing.
So instead of doing nothing when the iterator does not point to this
container, simply assume it does. Bad things will happen if you try to
erase an iterator that points to another container, but that's true for
almost all container/iterator mechanisms.
Drive-by modernization of some of the surrounding lines.
Change-Id: I89446ea06b5742efb194fffd16bb7c322c2fc4f2
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The 0x10000 limit should not apply if the key is a valid index in the
array.
Change-Id: I5e52dc5b093c43a3b678fffd16b6a2a5a69acd61
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
I screwed up when I wrote QCborValueRef by not having the ConstRef
type. The code worked, but it wasn't const-correct, allowing you to
write:
const QCborArray &arr = something();
*arr.begin() = QCborArray();
This mistake was brought over to QJsonValue in Qt 6.0, so it has to be
fixed for QJsonValue too. The actual fixes are in the next couple of
commits.
This change is believed to be binary-compatible: the Q{Json,Cbor}ValueRef
classes continue to have the exact same size, except that they're now
empty and have a new base class. They weren't trivial before this commit
doesn't change that.
[ChangeLog][Potentially Source-Incompatible Changes] The iterator
classes for Qt's JSON and CBOR containers (array and map/object) had a
const correctness issue which allowed a const_iterator to mutate the
container being iterated on, even if that container was itself const. Qt
6.4 has a fix for this, but will cause compilation issues where
QCborValueRef and QJsonValueRef were used where the correctness could be
violated. To keep code compiling with both 6.3 and 6.4, either change to
non-const iteration or replace the QxxxValueRef with a const QxxxValue
reference. This change is binary-compatible.
Change-Id: I5e52dc5b093c43a3b678fffd16b6063333765ae0
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
The flag IsContainer was not set, causing the QCborContainerPrivate to
become confused.
This commit also expands and subsumes the existing test for QCborValue
(non-Ref).
Change-Id: I5e52dc5b093c43a3b678fffd16b6a17c6f4a0676
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This has found several missing const qualifications, a missing
QCborMap::Iterator method, and a missing one in QCborValue too.
The methods "### TEMPORARY" in this commit are actually removed in two
commits.
Change-Id: I5e52dc5b093c43a3b678fffd16b6939f62954dc4
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
- New testcase tst_eventdispatcher added under commit d292f0143f.
It shows that only glib implementation works correctly.
Task-number: QTBUG-99123
Pick-to: 6.2 6.3
Change-Id: I7b861a6207fcb319de362645fc8f00a8ab6cd4b9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The loop used an int counter that was initialized from a size_t,
provoking a warning from MSVC. Since the indexing is irrelevant in any
case, use a ranged-for loop. Since the loop was formerly in decreasing
index order, reverse the table being iterated so that entries remain
in their prior order.
Change-Id: I79b93c5a3f39a502b0cae83215b8e3665d0e17f5
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
tst_qcoreapplication.cpp is used both in tst_qcoreapplication and
tst_qguiapplication. To distinguish these two compilations,
the define QT_GUI_LIB was used. This led to an error on Android,
where Qt::Gui is always linked, because the Qt Android Platform
Plugin needs it.
This patch introduces the preprocessor define QT_QGUIAPPLICATIONTEST
which is to be used only in the compilation of tst_qguiapplication.
This is then used instead of QT_GUI_LIB.
Change-Id: Ifa5bfacb197d68365288c1da85573106515fc6c2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
tst_QFutureWatcher was deactivated for Android. This patch activates it.
Fixes: QTBUG-88136
Change-Id: Iead82e22d73eb15c9ecd2756eb33925910bbffc0
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
- current INTEGRITY development pack don't support denormals for float and double.
All values are rounded to 0.
Task-number: QTBUG-99123
Pick-to: 6.2 6.3
Change-Id: Iaaacdc4210c7ac2ec3ec337c61164a1ade0efb01
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
... which implements or assumes something about the
broken^Wnon-STL-compliant insertion behavior.
Once this has integrated into all module dependencies, we can
re-implement these APIs using STL-compatible semantics.
Task-number: QTBUG-100092
Change-Id: I54f4f5ce7addd9543866d2c399f48aff50983b88
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Even QtCore alone cannot be built without the properties feature since
Qt 5.5. While fixing this is easy, other modules like dbus,
networking are also using QObject::property() and friends liberally.
All in all I doubt that anybody will miss the feature (otherwise it
would have been fixed in the last decade).
Change-Id: Iaf3cc20bda54ee2ff3b809fac8fa82b94ecc88c0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The macOS standard library doesn't have std::contiguous_iterator yet, and
it doesn't seem like libc++ has it either.
Checking __cpp_lib_concepts for the C++20 official version appears to work.
Pick-to: 6.3 6.2
Change-Id: I8c31cd64de24c03b3a3f37cb393bb2f9b55a834d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Remove Integrity and Android specific code that explicitly adds
test data to the resource files. qt_internal_add_test functions
implicitly adds test data to resources for Android and Integrity
platforms by default.
Change-Id: Ia1d58755b47442e1953462e38606f70fec262368
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Multiple tests use qt_internal_add_resource that copies the
functionality that is already implemented inside the
qt_internal_add_test function. Simplify these test by replacing
the qt_internal_add_resource call with the new BUILTIN_TESTDATA
option.
Change-Id: I18475b817d6f87264f0de53817d6c26c5ccab4e2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
[ChangeLog][Potentially Source-Incompatible Changes] The qtextstream
header no longer includes <QString>, <QStringEncoder> and
<QStringDecoder>. Code which relied on the implicit inclusion of those
classes might now need to include the headers explicitly.
Task-number: QTBUG-97601
Change-Id: Ifb8c8452026195a772c0588dbbbc53fb51cac548
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The offset fields for tst_QTimeZone::specificTransition() had a
comment claiming they are in minutes; they are in fact in seconds, so
fix that. At the same time, Moscow hasn't had a time-zone change since
2017, so the end-date for one of the test intervals can be nudged a
little closer to the present without harm.
Change-Id: I66822cb758f7e00d6added801466a6745be3e31a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Unless "." (or the empty string) is in $PATH, we're not supposed to find
executables in the current directory. This is how the Unix shells behave
and we match their behavior. It's also the behavior Qt had prior to 5.9
(commit 28666d167a). On Windows, searching
the current directory is the norm, so we keep that behavior.
This commit does not add an explicit check for an empty return from
QStandardPaths::findExecutable(). Instead, we allow that empty string to
go all the way to execve(2), which will fail with ENOENT. We could catch
it early, before fork(2), but why add code for the error case?
See https://kde.org/info/security/advisory-20220131-1.txt
[ChangeLog][Important Behavior Changes] When passed a simple program
name with no slashes, QProcess on Unix systems will now only search the
current directory if "." is one of the entries in the PATH environment
variable. This bug fix restores the behavior QProcess had before Qt 5.9.
If launching an executable in the directory set by setWorkingDirectory()
or inherited from the parent is intended, pass a program name starting
with "./". For more information and best practices about finding an
executable, see QProcess' documentation.
Pick-to: 5.15 6.2 6.3
Change-Id: I54f205f6b7314351b078fffd16cf7013c97ee9fb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In C++20, any given relational operator is also considered in its
reversed form, so e.g.
given op==(X, Y)
and X x, Y y, then y == x will compile, by using the reversed op(X, Y)
This, unfortunately, makes some existing asymmetric operator overload
sets ambiguous, and instead of applying tie-breaker rules, at least
Clang is warning about these.
For us, this means we need to make our overload set non-ambiguous. The
QJsonValue{,Ref} classes failed this, because they only provide the
following member-operators:
- QJsonValue::op==(const QJsonValue&) const
- QJsonValueRef::op==(const QJsonValue &) const
For member functions, there are no implicit conversions on the LHS. So
in C++17, we have a nice dichotomous overload set:
- LHS is QJsonValue -> use QJsonValue::op==(QJsonValue)
- LHS is QJsonValueRef -> use QJsonValueRef::op==(QJsonValue)
In both of these, it the RHS is a QJsonValueRef, it's implicitly
converted to QJsonValue for the call.
Enter C++20, and the reversed signatures are suddenly available, too,
which is a problem for QJsonValueRef <> QJsonValueRef, which could be
resolved, as in C++17, using
lhs.QJVR::op==(QJV(rhs))
or it could now be
rhs.QJVR::op==(QJV(lhs)); // reversed
Says Clang 10:
tst_qtjson.cpp:990:5: warning: ISO C++20 considers use of overloaded operator '==' (with operand types 'QJsonValueRef' and 'QJsonValueRef') to be ambiguous despite there being a unique best viable function [-Wambiguous-reversed-operator]
CHECK(r0, a0, r1);
^ ~~ ~~
qjsonvalue.h:189:17: note: ambiguity is between a regular call to this operator and a call with the argument order reversed
inline bool operator==(const QJsonValue &other) const { return toValue() == other; }
^
A similar argument makes op!= ambiguous.
Says Clang 10:
tst_qtjson.cpp:988:5: error: use of overloaded operator '!=' is ambiguous (with operand types 'QJsonValueRef' and 'QJsonValueRef')
CHECK(r0, r0, r1);
^ ~~ ~~
qjsonvalue.h:190:17: note: candidate function
inline bool operator!=(const QJsonValue &other) const { return toValue() != other; }
^
qjsonvalue.h:189:17: note: candidate function
inline bool operator==(const QJsonValue &other) const { return toValue() == other; }
^
qjsonvalue.h:189:17: note: candidate function (with reversed parameter order)
To fix, provide the missing operators as free inline functions (so Qt
6.2 and 5.15 don't get new symbols added) so there's always exactly
one best match.
This is a fix for 6.2 and 5.15. At the time of writing, 6.3 isn't
released, yet, so there, we could QT_REMOVED_SINCE the pre-existing
member operators in favor of hidden friends (as per QTBUG-87973).
Use C++17'isms to prevent an automatic merge to 5.15, which requires
contains(QT_CONFIG,c++2a):CONFIG += c++2a
added to tst_qtjson.pro.
[ChangeLog][QtCore][QJsonValue] Fixed relational operators to not
cause warnings/ambiguities when compiling in C++20.
Pick-to: 6.3 6.2 5.15
Change-Id: Ic70f3cad9987c87f7346d426c29cc2079d85ad13
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The value of __cplusplus has nothing to do with whether the library
implements wg21.link/P1115 (libstdc++ even before C++20) or not
(libc++, even in C++20).
Use the idiomatic check (#if defined(foo) && foo >= x) instead,
fixing the Android build.
Pick-to: 6.3 6.2
Change-Id: I11bcefe455a1f13865c15d4beecbd3fe32115328
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Use alternative method for finding searchPath since
QT_TESTCASE_SOURCEDIR did not point to a correct location on webOS
QEMU test environment.
Fixes: QTBUG-99954
Pick-to: 6.3
Change-Id: I05f95b4aa02027976036d0842ca564a602e01d0e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
When QCborValue referred to an empty array or map, toArray() and toMap()
would respectively return the default value instead of the empty object,
as expected.
Pick-to: 6.2 6.3
Change-Id: I5e52dc5b093c43a3b678fffd16b60456d0037ad7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Switched to use runtime path instead of compile time path for the
helper executable. Some tests cases were failing on webOS because of
wrong path.
Fixes: QTBUG-99846
Pick-to: 6.3
Change-Id: I566bc04bdb96ac6e7dd0a875eadb50685aef8282
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
A default-constructed QPluginLoader erroneously reports that the
load hints are empty. However, setting a filename would then
automatically set the PreventUnload hint, surprising the user.
Return the correct flags instead.
Amends 494376f980
Change-Id: I7a95964cb680afd3adf2f71ed73d2f93023238f2
Fixes: QTBUG-100416
Pick-to: 5.15 6.2 6.3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
While investigating an assertion failure I noticed that the existing
tests didn't even exercise these methods for local time or zone time.
Of course, we can't robustly test these time-specs, due to vagueries
of offset details and zone availability, but we can at least verify
that they return date-times on the specified date. Add a test-case for
the start of 1900, on which the assertions were first seen; it is the
earliest moment representable with tm_year >= 0, after all.
One of these tests fails on 6.2 but the fix for that (as opposed to
the the assertion) requires 6.3's improvements to the handling of
time_t's fuller range - too risky a change to pick back to 6.2.
Pick-to: 6.3
Task-number: QTBUG-99747
Change-Id: I98f5d7850a701972b2d8ea2ce203a2b3e7071354
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qt_internal_undefine_global_definition disables an internal global
definition that is defined by the qt_internal_add_global_definition
function for a specific target.
Remove the ability to set the custom "undefine" flag for the
definitions since it's hard to control it using the introduced
function.
Pick-to: 6.2 6.3
Task-number: QTBUG-100334
Change-Id: Ic1637d97aa51bbdd06c5b191c57a941aa208d4dc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Not MSVC, but pretends to be.
Pick-to: 6.3 6.2
Change-Id: I5c201dd917e79a22d6ef15715bf1d3a7010d123e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The code was trying to avoid a detach in the case no element needed to
be removed, by first running find_if() on const_iterators, and then,
after converting its result to (mutable) iterators, start the
remove_if() algorithm where find_if() left off.
But this applies the predicate to the element found by find_if() (if
any) _twice_: first just before we exit the first find_if() and then
just as we enter remove_if(), which will start by running find_if()
again, with the result of the initial find_if as 'first'.
Apart from being needlessly inefficient, this violates the
specification of Uniform Erasure, which defines sequential erase_if()
as being equivalent to remove_if() + container erase(), with the
former being specified to apply the predicate exactly once per
element.
Fix by writing the remove_if() part by hand.
Instead of doing the dance with the loop invariant documentation
twice, simply implement erase() via erase_if() (complicated a bit by
the weird passing of predicates by lvalue reference instead of by
value, as would be idiomatic). This exposes users to:
[ChangeLog][QtCore][Potentially Source-Incompatible Changes] A fix in
the implementation of the erase-like algorithms of sequential Qt
container may re-enable signed/unsigned comparison warnings previously
suppressed by having occurred in std library code. To fix, cast the
value to look for such that it has the same signedness as the
container's elements.
... but the issue would be the same had we inlined std::remove()
instead of passing a lambda to sequential_erase_if(), so it's nothing
we can, nor should, work around.
[ChangeLog][QtCore][Containers] Fixed a bug in the implementation of
most sequential Qt container's erase-like algorithms (member
removeAll()/removeIf() and free erase()/erase_if()) where the equality
operator or the predicate, respectively, was applied to the first
matching element twice. Each element is now tested exactly once.
Pick-to: 6.3 6.2
Change-Id: Ib6d24b01b40866c125406f1cd6042d4cd083ea0d
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Restore the 'QT_NO_JAVA_STYLE_ITERATORS' and
'QT_NO_NARROWING_CONVERSIONS_IN_CONNECT' definitions for Qt
targets.
Add the function that adds global definitions for Qt targets according
to the provided scope and the target property-based switch to disable
the definition for a specific target.
Pick-to: 6.2 6.3
Task-number: QTBUG-100295
Change-Id: I28697e81f9aabc45c48d79aae1e5caea141e04e1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If the signal passed to QtFuture::connect() takes multiple arguments,
we need to wrap the arguments in a std::tuple when reporting the result.
To detect this case we were checking if the result type of a QFuture
returned by QtFuture::connect() is a std::tuple, but this was not
correct: the result type could be a std::tuple also if the passed
signal takes a single std::tuple argument. Instead, check if the signal
takes more than one argument.
As a drive-by modified the tst_QFuture::signalConnect to use const
values for tuples used in multiple test-cases, to avoid repetition.
Fixes: QTBUG-100071
Pick-to: 6.2 6.3
Change-Id: I1ce39cf87028f36ef94a9d1a4423b0c51473afd4
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The test was already blacklisted for Windows 10 and Windows 7. Now it
is flaky on Windows 11 as well.
Blacklist it for all windows platforms.
Task-number: QTBUG-98478
Pick-to: 6.2 6.3 5.15
Change-Id: I870fb6ce80cfe244a76d08bf40677fdb6becab97
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
Add a level of indirection via void_t such that
struct is_transparent {};
works, and not just
using is_transparent = <unspecified>;
Pick-to: 6.3
Change-Id: I3ca2af6a07e6989dc95abc10fb2d0078a5269e5b
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
577d698b8e changed QString::isUpper /
isLower behaviors to match Unicode semantics: a string is uppercase
if it's identical to its own toLower/toUpper folding. These semantics
come from Unicode so they're not up for debate.
That commit however left QByteArray untouched. Generally speaking, we
want to move away from QByteArray as "text storage" -- this has
partially happened between Qt 5 and Qt 6, where QByteArray went from
Latin-1 semantics to ASCII semantics. Still, QByteArray offers
toUpper/toLower and isUpper/isLower and all this family of functions
should be consistent in behavior.
Apply the same fix that was applied to QString.
[ChangeLog][Important Behavior Changes] The semantics of
QByteArray::isLower() and QByteArray::isUpper() have been changed. Now
lowercase (resp. uppercase) byte arrays are allowed to contain any
character; a byte array is considered lowercase (resp. uppercase) if
it's equal to its own toLower() (resp. toUpper()) folding. For instance,
the "abc123" byte array is now considered to be lowercase.
Previously, the isLower() (resp. isUpper()) functions checked whether
the byte array only contained ASCII lowercase (resp. uppercase)
characters, and was at least 1 character long. This had the side effect
that byte array containing ASCII non-letters (e.g. numbers, symbols,
etc.) were not lowercase nor uppercase.
[ChangeLog][QtCore][QByteArray] QByteArray::isLower() and
QByteArray::isUpper() now work correctly with empty byte arrays. The
semantics of these functions have been changed.
Pick-to: 6.3 6.2
Fixes: QTBUG-100107
Change-Id: Id56a42f01b2d1af5387bf0e6ccff0f824f757155
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The class is not intended for inheriting from it (see also
e502906305), so we can mark it as final
to explicitly forbid this. The tests were still using it as a base
class to clean the results during destruction, so fix them accordingly.
Task-number: QTBUG-99883
Pick-to: 6.3
Change-Id: I4a7ee3e2b462bd704e4b5a95ed733144805d6e5b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Unlike QString and QStringView, QByteArrayView and QByteArray don't
overload well.
Solve the overload issue the usual way: by making the QByteArray one a
Q_WEAK_OVERLOAD. This is trivial for QStaticByteArrayMatcher, which
isn't exported, but require QT_REMOVED_SINCE magic for
QByteArrayMatcher, which is.
The additional const char* overload has shielded us from the worst
fall-out so far, it seems, but it makes for a truly horrible overload
set:
matcher.indexIn(str, 3);
Q: Is the 3 here the length of the haystack or the value of the from
parameter?
A: It depends on decltype(str)!
If the (const char*, qsizetype, qsizetype=0) overload is the better
match, then 3 limits the haystack's length.
If, otoh, the (QByteArray(View), qsizetype) overload is the better
match, then it's the value of the from parameter.
As if this wasn't bad enough, QByteArray implcitly converts to const
char* by default!
A follow-up patch will therefore deprecate the (ptr, size) overloads,
so we de-inline the QByteArrayView ones to avoid having to touch the
implementation once more.
Found during 6.3 API review.
Pick-to: 6.3
Change-Id: I9640e0bdd298d651511adebcc85f314db9221d34
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Add a test (same techniques as for the 4+GiB check in
tst_qcryptographichash).
Takes ~1s to build the 4GiB test data here, and skips
when RAM is too low:
$ qtbase/tests/auto/corelib/text/qbytearraymatcher/tst_qbytearraymatcher haystacksWithMoreThan4GiBWork
[...]
QDEBUG : tst_QByteArrayMatcher::haystacksWithMoreThan4GiBWork() created dataset in 891 ms
[...]
$ (ulimit -v 2000000; qtbase/tests/auto/corelib/text/qbytearraymatcher/tst_qbytearraymatcher haystacksWithMoreThan4GiBWork)
********* Start testing of tst_QByteArrayMatcher *********
[...]
SKIP : tst_QByteArrayMatcher::haystacksWithMoreThan4GiBWork() Could not allocate 4GiB plus a couple hundred bytes of RAM.
Loc: [/home/marc/Qt/qt5/qtbase/tests/auto/corelib/text/qbytearraymatcher/tst_qbytearraymatcher.cpp(242)]
[...]
Found during 6.3 API review.
[ChangeLog][QtCore][QStaticByteArrayMatcher] Fixed searching in
strings with size > 2GiB (on 64-bit platforms).
Fixes: QTBUG-100118
Pick-to: 6.3
Change-Id: I1df420965673b5555fef2b75e785954cc50b654f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When int is 32-bit, 0x80000000L is int-min, and (consequently)
negating it makes no difference, so MSVC warns about this. Instead of
using an L suffix, wrap the constant in Q_INT64_C(). Do the same for
similar large constants in the same block.
Pick-to: 6.2 6.3
Change-Id: Ib371b932792f170ab7db2e472a4283df3a205af3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Capturing a QFuture in the continuations attached to it results in
memory leaks. QFuture's ref-counted data can only be deleted when the
last copy referencing the data gets deleted. The saved continuation
that keeps a copy of the future (as in case of the lambda capture) will
prevent the data from being deleted. So we need to manually clean the
continuation after it is run. But this doesn't solve the problem if the
continuation isn't run. In that case, clean the continuation in the
destructor of the associated QPromise.
To avoid similar leaks, internally we should always create futures via
QPromise, instead of the ref-counted QFutureInterface, so that the
continuation is always cleaned in the destructor. Currently QFuture
continuations and QtFuture::when* methods use QFutureInterface directly,
which will be fixed by the follow-up commits.
Fixes: QTBUG-99534
Pick-to: 6.3 6.2
Change-Id: Ic13e7dffd8cb25bd6b87e5416fe4d1a97af74c9b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Avoid some unnecessary comparisons and add more tests.
Task-number: QTBUG-99799
Change-Id: I3aee9f0b62461d38dadbe8e969444e1cd1f94e68
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
This is added specifically for the QPA platform and theme plugins, to
honor the QT_QPA_PLATFORM_PLUGIN_PATH environment variable and the
(inadvisable) -platformpluginpath command-line argument.
This removes the last QFactoryLoader used with an empty path (also the
only two that could be reached), which were causing a scan of the
application's binary directory whenever the platform plugin path was
set. In case of applications installed to /usr/bin, the entire /usr/bin
was scanned, which can be qualified as "not good".
Fixes: QTBUG-97950
Pick-to: 6.3
Change-Id: Ice04365c72984d07a64dfffd16b47fe1d22f26d3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Commit 289f909621 ("Test conversion of
ulonglong variant to JSON") was trying to ensure the result becomes a
double. So there's no reason to make a test in the _data() function.
Drive-by fix the UB condition on Windows (ulong is 32-bit, so 1ul << 63
is UB).
Change-Id: I0e5f6bec596a4a78bd3bfffd16ca4f8f5219f785
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
