lastIndexOf will convert the `needle` to unsigned char, which is then
'upcast' to int, before we search. But the string itself was searched
using signed char, meaning any values with the signed bit set would
mismatch.
Add tests for indexOf and lastIndexOf.
Amends 4c12ae7e67
Fixes: QTBUG-128199
Change-Id: I0ce7d7d9741f21650ef6f0f012a94e00d84a0f02
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 7b1f3bdc503ea7aceacc9fa8d388d843f1d7b131)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QtAbstractItemModel used to be a part of QtDeclarative
and is being moved to QtCore based on API reviews.
Task-number: QTBUG-126976
Task-number: QTBUG-127089
Change-Id: I28a921a113ec4f3ad298bf55b40aea334e7721cf
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit baed8a24d07de87da61e9d5e3dbffc8d8ca92918)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Iterators no longer provide it, because they may need to return a
temporary in some occasions.
Fixes: QTBUG-128102
Change-Id: Ide0a7a84f612fff73afffffd49889321cb70505f
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
(cherry picked from commit cb40a1fa7f4b06acced1d17e8333742084092f9e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It turns out that libstdc++ in -ansi mode defines __SIZEOF_INT128__,
but not the corresponding specializations of <type_traits> and
<limits>. This has caused numerous pain points over time, esp. since
is_signed doesn't work, so qt_saturate e.g. can't be used on qint128
inputs e.g.
After another such issue (cmp_equal()), we decided to require
<type_traits> and <limits> support for extended integer types in the
stdlib, or we will disable Qt's support for it, too.
So check that if QT_SUPPORTS_INT128 is defined, is_signed_v,
is_integral_v and numeric_limits work, too. Disable QT_SUPPORTS_INT128
when compiling with libstdc++ in __STRICT_ANSI__ mode (-ansi or
-std=c++NN instead of (the default) -std=gnu++NN).
[ChangeLog][Potentially Source-Incompatible Changes] Qt's support for
128-bit integers (qint128/quint128) is now conditional on support for
these types from the Standard Library, in particular <type_traits> and
<limits>. Qt no longer tries to work around missing Standard Library
support. As a consequence, e.g. GCC -ansi and GCC -std=c++NN (instead
of -std=gnu++NN, the default) builds will now no longer support these
types.
Task-number: QTBUG-119901
Change-Id: I8529e72a52a2f5da0f469bae543688e18220255f
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 9bb2ab5978625eee96f703871d5eca8e54b31386)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This is in preparation of adding some static assertions here that we
need to have evaluated in both "normal" and "strict" mode, namely
<type_traits> and <limits> support for qint128.
But this change is more general, so making it a separate change.
Turns out we already have (non-static) assertions here about <limits>
support for qint128. These force us to define precisely when
GCC/libstdc++ has gained <limits> support for __int128_t: the
timestamp of the __GLIBCXX__ macro is the Daily Bump immediately
preceding the gcc commit that fixed <limits>
(gcc/8eb9a45e87bdb81cb44948c651edee846c622a0f).
Let's hope no-one is running the prerelease version of GCC 10.3 from
that particular day, otherwise these might become XPASSes. But just
not testing is also wrong; we want to be informed about True Positives
and Negatives here.
Task-number: QTBUG-119901
Pick-to: 6.7 6.5
Change-Id: I6f9be047f846fff74133c466c5bed40d0039d60f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit e7c54248987d474cff9f49cad502822eb9dcb114)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Disable operator*() for void* type, because it otherwise causes
a compiler error:
qcomparehelpers.h:1103:18: error: forming reference to void
constexpr T& operator*() const noexcept { return *get(); }
^~~~~~~~
Use this as an opportunity to add more tests for operator*().
Amends ece36a7394.
Change-Id: I205b9989bd142ca9aa49f8f4d15854e591e3042b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 053b8ff7fedfe5aed29a91a82569c00cac466e9a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
According to QUIP-18 [1], all test files should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Task-number: QTBUG-121787
Change-Id: I0a35709284c4b6e7d080f41f361a9adea1415ca0
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
(cherry picked from commit 334a92ecb86fb89a65091bb4c230431eeb0fa587)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Some sub-classes have special handling of source model data changes,
they relied on disconnecting the connections to the _q_*layout* slots
in the private class using the SLOT macro. This isn't possible any more
after the recent port to PMF connects.
Sub-classes resorting to using private API is a clear sign some
functionality is missing from the public API, so a cleaner solution for
this issue is adding this setter which enables sub-classes to tell
QIdentityProxyModel to leave handling of the dataChanged signal to them.
Similar to commit 675b4f63fe (but
this should be the last one needed).
[ChangeLog][QtCore][QIdentityProxyModel] Added
setHandleSourceDataChanges(bool) method to allow sub-classes to
indicate to QIdentityProxyModel that they will handle source model
data changes on their own. Also added a getter,
isHandleSourceDataChanges().
Task-number: QTBUG-127959
Change-Id: Id8f567c330e4ee834940a62b6497d8cbb8ba4a46
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 5a31800d41273a14436c543438a142562f74f857)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The standard does not provide any details on implementing operator!=(),
because it relies on the fact that it will be synthesized by the
compiler.
Our C++17 implementation, however, has to provide operator!=(), and we
made the mistake of copy-pasting the implementation from other
operators.
However, the isOrdered() check does not make sense for operator!=(),
because an unordered value is never equal to literal zero.
Fix the implementation for both Qt::partial_ordering and legacy
QPartialOrdering.
Amends 405244fe30 (for QPartialOrdering)
and bdd41f491c (for Qt::partial_ordering).
[ChangeLog][QtCore][QtCompare] Fixed a bug where
partial_ordering::unordered != 0 comparison produced an incorrect
result.
Fixes: QTBUG-127759
Pick-to: 6.7 6.5 6.2 5.15
Change-Id: I5008f72831c17dc7fa4ae181bfc8115198a691f0
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit d39441a2eb5658f3d4a01046c592adb827525118)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
... and figure out that it does not match the std implementation.
Fix will be provided in a follow-up commit.
Task-number: QTBUG-127759
Pick-to: 6.7 6.5 6.2 5.15
Change-Id: I51c4f086af531a81a6aae03f3462972437d41f97
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit fed1099ad2909cb8e75477e60e0a8b41db3f58d0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The date-time parser, unless it hits a fixed-width numeric field
that's unfilled, leaves checking the date against its configured range
until it's parsed all fields. This means it can be out of range due to
a full-width field when it hits an unfilled one and tries to take the
range into account when deciding whether to zero-pad or expect more
input into the field. So asserting the current partially-parsed
datetime is in range at that point is not justified.
Thanks to Albert Astals Cid for reporting this fiendish corner case,
found by oss-fuzzing of KDE's image plugins, in IRC.
Pick-to: 6.7 6.5 6.2 5.15
Change-Id: Id7db7409a0b5afadafb6920a0785a4cec4c80b62
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Albert Astals Cid <aacid@kde.org>
(cherry picked from commit e0a4de17ddb924d9bf222fb3ea2d0526813edea6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This applies to the Q_ENUM/Q_FLAGS overload of the debugging functions.
This prevents the sign-extension of a signed QFlags field when
converting to quint64, which would have resulted in 0x8000'0000 becoming
0xffff'ffff'8000'0000.
Right now, this is a no-op change because the implementation in
qt_QMetaEnum_flagDebugOperator() calls QMetaEnum::valueToKey(), which is
limited to int (32 bits).
Change-Id: I8a96935cf6c742259c9dfffd17e998c3a0538146
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 232ad339ab14965b6207d04a45d8d37ec3139558)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This change fixes three problems in the non-Q_ENUM overload. First, the
printing of the sign bit for a signed flag. This is correct, but
unexpected:
QFlags(0x1|0x2|-0x80000000)
By using unsigned types, we'll print instead:
QFlags(0x1|0x2|0x80000000)
Second, shifting into the sign bit is UB, so we remove the problem by
not having a sign bit at all.
Third, this provides an out-of-line non-template overload of the
implementation for unsigned QFlags, thereby avoiding an unnecessary
instantiation of the template function qt_QMetaEnum_flagDebugOperator()
in user code.
Change-Id: I8a96935cf6c742259c9dfffd17e992caa315e1d3
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 91a27c1a516068b69ab62778a07c566ad22f3576)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The qsnprintf() function introduces even more platform variability
than std::snprintf(), so from now on, we're using only std::snprintf().
Task-number: QTBUG-127110
Change-Id: Ic81b2a760521d77442cc328d2cfa7659bba8b7e2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit b8a956c2d3f9c158594265eca89185bd2bc671e7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When converting a wildcard into a regexp, convert a series of
consecutive '*' tokens in just one '.*' (instead of a series of '.*').
The pattern matched is the same, but we reduce the effects of a
possible catastrophic backtracking. I'm not actually sure whether
PCRE optimizes this case out of its own or it doesn't; Perl appears
not to.
Change-Id: Ia83336391593d56cf6d8332c96649a034a83a15b
Fixes: QTBUG-127672
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit a041cd35214e57a189aaa1f1f77199ff42303f83)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The macro is defined or not, not defined to 1 or 0.
Amends 1d7950c946 (qhashfunctions.h),
0d85d0a72f (tst_qfloat16.cpp),
104a0a9ecd (tst_qglobal.cpp),
7a829eaf51 (tst_qtendian.cpp).
Pick-to: 6.7
Change-Id: I190e208f3c96f27100dae3eef512739afa8fadd9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit c78994a887f56f1bc77a5fa0db3b98196851db5e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Both issues reported in QTBUG-120396 came from the same dubious piece of
code, which predates the public Qt history
if (path->size() >= 2 && in[0].unicode() == '.' && in[1].unicode() == '/')
in += 2;
else if (path->size() >= 3 && in[0].unicode() == '.'
&& in[1].unicode() == '.' && in[2].unicode() == '/')
in += 3;
It makes no sense to check path->size() inside the loop, as the in
pointer will have advanced past the beginning and the remaining size of
the input will not be path->size().
It additionally had theoretical UB in expressions like
in <= end - 4
for paths that were less than 4 characters long (it cannot happen with
current QString because of the QArrayData header before the payload).
So this commit rewrites the function to fix those issues and some others
found during the unit-testing. It gives the function a major
simplification.
Fixes: QTBUG-120396
Pick-to: 6.7 6.5
Change-Id: I46feca3a447244a8ba19fffd17e012c27e410056
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit 4b1547adc9b195e6acc90471fc48dec7ee0c429d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They were lacking it since the start of the public history, and
porting to std::snprintf() (which has the warning) as part of making
Qt compile with QT_NO_SNPRINTF has turned up surprisingly many
-Wformat warnings, so enable the warning for the remaining (non-tree)
users.
Backporting aggressively, as this might unearth security bugs in user
code.
[ChangeLog][QtCore][q(v)snprintf] Added attributes for GCC-compatible
compilers to detect format/argument mismatches. If this throws warnings
for your calls now, don't ignore them. printf() format mistakes could
be security-relevant. You may also find that you relied on undocumented
behavior, such as that certain implementations (Windows, Android, WASM)
of qsnprintf() support char16_t* instead of wchar_t* for %ls. In that
case, you should port to qUtf16Printable() and QString::asprintf(), or
suppress the warning and port away from the platform dependence at your
earliest convenience.
Task-number: QTBUG-127110
Pick-to: 6.7 6.5 6.2 5.15
Change-Id: I5c1fd9b2d5d2d55c68773f33edfd76acacd2408c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
(cherry picked from commit 64416d3cf645187385d8ad90bc44d9c8e9ce864f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QKeyCombination comes with a few operators that combine a Qt::Modifier
and a Qt::Key. These operators are normally defined in Qt's own
namespace (which by default is the global namespace), but indeed the
arguments are declared in the (nested) namespace `Qt`. This is wrong,
as their lookup will fail if a user places an unrelated operator| in
a custom namespace U and then tries to use QKeyCombination's operators:
the overload in namespace U will hide the ones defined globally;
unqualified lookup (as per [over.match.oper]) will search in the
namespaces associated with the parameters (QtNamespace::Qt), but the
operators are *not* in there!
In other words:
namespace NS {
X operator|(Y, Z);
auto kc = Qt::Shift | Qt::Key_A;
}
fails to compile if QKeyCombination's operator| is *not* defined in the
`Qt` namespace.
Fix this by indeed defining the operator where it belongs. The functions
are all inline and non-exported so there should not be any ABI issues.
Change-Id: I6d7a4e976fb109b7bf514011142b9a9573e507c5
Pick-to: 6.7 6.5 6.2
Fixes: QTBUG-126820
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 1f77e8566f71d98f4bc6bbf5092594e67a32f268)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use std::snprintf() instead. Also use qToUnderlying() instead of
explicit cast to unsigned (so the compiler warns us should the
underlying type of he QNativeIpcKey::Type enum ever change) and
applyRAII to temporary toString() results.
Amends 32a06e9830.
Pick-to: 6.7
Change-Id: I4dd00672382d377285d722a47d998bdf12422eb4
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit ce7b8fc91d82402cbed230e83c00cab3a54f9916)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We cannot use memcmp() for that, as it incorrectly results in two
NaN values being equal.
Simply replace the whole self-written algorithm with std::equal(),
as it's doing the same thing, but lets the compiler decide when
to do the optimizations.
Amends db89349bdb.
[ChangeLog][QtCore][QList] Fixed a bug when two QLists holding NaN
values were considered to be equal.
Fixes: QTBUG-127473
Pick-to: 6.7 6.5 6.2
Change-Id: If7e77549b4cbeb96711893d14344b9e0a40c1a87
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit cb3faeba3d9411ba82c311751bd7de36d0fec939)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
For legacy reasons, the accessor class allows operator[] to go out of
bounds and just returns an empty string. However, we were returning a
pointer to the one-past-end of the array, which appears to have been a
null byte in the test.
Instead of adding branching code to load the length of the first string
in operator[], we can just add an extra null character at the position
we were returning anyway.
Pick-to: 6.5
Change-Id: I4878533dcb2d4b3e8efefffd17e4f876b43e9ee3
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit 8a768fe7db6ac5388fec6a68687817796b44439e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QDebug::toString intends to pass the input object's address to its
nested implementation, but was calling operator& which does not work
with types that has a custom overload. Calling std::addressof fixes this
problem.
Fixes: QTBUG-127510
Change-Id: Ie608f7b1a63c4032246b6ff98a3651695f0536ca
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 6cd6c3d6d70f8e76059153dd58ed2c61af2889b3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Also store the version in one variable and reuse it, to make it easier
to update in the future.
Change-Id: Ib843a1cfa5c53233f9daa6c373d238f756eb4853
Reviewed-by: David Faure <david.faure@kdab.com>
(cherry picked from commit 922e197bd3468d4c10b8fcd6377cd7b67f2541f2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The second value (like the first) has type qint64 (aka long long), so
%d is wrong; need to use %lld instead.
Found while porting to std::snprintf() (qsnprintf() never actually got
the __attribute__((printf)), so compilers didn't warn).
Drive-by replace qAbs() with std::abs().
Amends 13c3558fe9.
Pick-to: 6.7 6.5
Change-Id: I9082a1aceefe8a5b04ad0d5725ab666e23483b29
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 61e4be2b62f9b6556a145f226850bf5e62d53e9d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The file had no protection against multiple inclusions. While current
code doesn't include it multiply, prevent it from becoming a problem
in the future.
Pragma once is sufficient, as this header is not installed.
Amends 32a06e9830.
Pick-to: 6.7
Change-Id: I97bbbb80f46c0e587288e8ebb4fa06ddd2e892be
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 235bb0926a94a73655a266c0ac038fa3a0a982cd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We can populate a container with the contents of the Java array as long
as the element types are convertible without narrowing (taking various
special cases into account, such as jstring to QString). The container
has to be either support emplace_back, or be a contiguous container
if a primitive element type.
The template helpers need to be in QJniArrayBase in order for qdoc to
accept the input.
Add test coverage, including static compile time tests.
Change-Id: Id9372deed5cf33446ee1969dc284a88991db2aee
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 8f04defa1e3973faec19a9cb1ab9bbf1ea7fb031)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We can create a QJniArray from any container that has a forward
iterator. A contiguous container can be used to optimize the code path,
as long as the element type is primitive (i.e. not an object type).
Fixes: QTBUG-126151
Change-Id: I21915f944d226d6d4f1113a54e5602ddc9cd727e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 71be7834e67216010dc74ed855dc7b513e302f1a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Explicitly define (compiler-implemented) copy and move SMF's for
QJniArrayBase; we need to, as the destructor is declared, so without
them the compiler will implicitly convert an array to a QJniObject
and call that constructor.
Constrain the constructors and assignment operator from a QJniArray of
another type so that no narrowing conversion is allowed. Due to the
implicit conversion to QJniObject, we have to explicitly delete the
overload for narrowing conversions. Use the detector we have in
qobjectdefs_impl.h for that.
Make the detection helpers private, and add test coverage.
Change-Id: I1b2bb4435d52223567d20bb55ceb0d516e3b0b15
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit ebbf7b0fdf866190cd20e62d6b13c7c6808101da)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It doesn't make a lot of sense to pass QJniObject instances into APIs,
but to be able to consistently treat QJniObject as an object type we
have to register it with the java/lang/Object signature.
Change-Id: Ic40e2676186bf327fa92764da51404985f74b565
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 82254fa836a21b5ec450a4ec7635e72403dded18)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The QJniArray doesn't store values, so at() always returns a temporary.
As we cannot hand out a pointer to a temporary, use a wrapper reference
struct that stores the value and implements operator->. It's all inline,
so we can move it out in the future to return mutable references, if we
ever want to enable write access to QJniArray elements.
Change-Id: I3962df6160db8c5b573d47ebb7975864f8ea7a8b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 3d5af4b912e60beb791f874c2dbfef5597b9aad7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
... it is. Filed QTBUG-125730 to track this and discuss how to deal
with it.
Pick-to: 6.7 6.5 6.2
Task-number: QTBUG-125730
Change-Id: I2c680e1a9e8dda43700468a544ac645e1fa3aa53
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 3ff55648cee8365fb7825ca7a038596b63757ea3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This was in fact present in v44, but we overlooked it somehow. The new
version also fixes some inconsistencies in the data, that I reported
against v44.1; in particular, Tamil no longer claims to override the
root AM/PM markers (probably because it uses 24-hour time so doesn't
need them).
Add the test-file under util to the list of files containing generated
content.
Conflict at 6.8 resolved by regenerating the data; this only changed
the date of generation, not the data. Then hand-edited the date to
match the picked upstream commit, to avoid future conflicts.
[ChangeLog][Third-Party Code] Updated CLDR data, used by QLocale, to
v45.
Task-number: QTBUG-126060
Pick-to: 6.7 6.5 6.2
Change-Id: I81a5bcca49519b55091fc541de6b73b606661bb4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit f79548e268a496698d77d0e78365334d0e507212)
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The tests are needed for the next patch where we modernize comparisons
and wrap the pointer, which involves changing most of the functions.
Pick-to: 6.7 6.5 6.2
Change-Id: If635538bfca33e410e19472d32b9666d258f96a9
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit b44541d8a42b7fc0b24cde4086b0030623280cc0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The conditional noexcept in comparison operators is known to cause
problems in various cases.
For example, we had a problem in QBAV, where gcc and clang tried to
expand conditional noexcept before the class was complete, and, as a
result, discarded some of the QBAV constructors (see
fff6562f8c for a more detailed
explanation).
Other problem is related to the GHS compiler which tries to compile
the noexcept specification and provides a hard error instead of
SFINAE'ing out in case of failure
(see e1f45ad818 or
0ac0b412c754e53d167716f207be9d76a7fe16be as examples).
This patch reworks the macros to get rid of the conditional noexcept.
Instead, it demands that all operators are noexcept by default, and
adds another set of helper macros that can be used if it's not
possible to make the relational operators noexcept.
The new macros end with the _NON_NOEXCEPT suffix.
The patch also adds static_assert() to the generated operators to
verify that the proper macros are used. However, some platforms
(e.g. QNX and Integrity) fail to handle conditional noexcept on
lambdas, and so we have to use yet another macro to generate the
checks only on platforms that handle them properly.
This patch also applies the new approach to qtbase, adding noexcept
where possible, and falling back to the _NON_NOEXCEPT macros
otherwise.
As a drive-by: fix the macro implementation to use
QtOrderingPrivate::reversed() instead of manually reimplementing it.
I decided to pick the patch to 6.8, because it allows to fix some
questionable APIs (see QBAV story above).
Change-Id: I72f56778acb469f18b578b3418c0c41b4f6d62e7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit d292648d0bbac50388dae035dc34782accb3807f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
[ChangeLog][QtCore][QMimeDatabase] QMimeDatabase can now pick up XML
mimetype definitions from :/qt-project.org/mime/packages. GPL-compatible
projects which provide self-contained binaries can use this to provide
a copy of freedesktop.org.xml that will be used instead of the TIKA
mimetypes.
Change-Id: Id363317f920ae2cb1e054f32feb732e0e9168de3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit b12542c964c15d074393a7594c97a96d5c2b047d)
Instead of freedesktop.org.xml (which is GPL), use the tika mimetypes
definition (Apache licensed), as fallback on platforms where
shared-mime-info isn't installed.
[ChangeLog][QtCore][QMimeDatabase] For licensing reasons, QtCore
no longer ships a copy of the MIME database from freedesktop.org's
shared-mime-info project, but the one from the Apache Tika project.
The tika definitions don't have icons or translated descriptions, but
are sufficient for matching file types.
[ChangeLog][Third-Party Code] Added TIKA mimetypes and the corresponding
attribution file.
Change-Id: I360ed973f6d89a470dc2f17a21abdf5630c6d15d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 74ad4cbeef40b1f51a59b3168f8c0b62eb0b29c8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QJniObject is a value type with move semantics, but didn't provide swap,
so add it.
Make it safe to check a moved-from QJniObject for validity, and to
compare it with another QJniObject. As before, two invalid objects
compare as equal.
Change-Id: Ie08bb7c50da831f3e7e98e731e8ddbc0ebb3af78
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 3e0c21691dd2be6911c417f4cbfaf54d10b4d634)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The build on Android with clang results in a bunch of irrelevant
warnings. Disable them for the offending lines of test code.
Change-Id: Ica5d867e3a2b1215dc526cc5f945a39ac908ac23
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 8d523a098cc8068400a6138970c6382f8f56224c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The last requirement for making the iterator random-access, so
change category type.
Based on review comments.
Task-number: QTBUG-126150
Change-Id: I617f38f92d0f9279781e62ea3ab1929dbf6a07cd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit e4b2d7607c0243f2a7ca3f38f59e8532c543fcc7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Required for making the iterator random access.
Based on review comments.
Task-number: QTBUG-126150
Change-Id: I80ee8ed584747759acb17ee956551caba4d5bdaa
Reviewed-by: Soheil Armin <soheil.armin@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit c4e406e3792405cfc0b8cc97a29f136c0fd44a2e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Required for making the iterator random access.
Implement compareThreeWay, add tests. Comparing iterators operating
on different containers is undefined behavior, so assert if they don't
match (even if they are different QJniArrays referencing the same
Java array).
Based on review comments.
Task-number: QTBUG-126150
Change-Id: Ib3b94558fc66fb9cff19139d2110c6bbd4ac14b5
Reviewed-by: Soheil Armin <soheil.armin@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit d04f38f6f5e49a81211ab598ba23049dc4ef1507)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We implicitly support QString, QStringList, and QByteArray, as well as
C++ types that are equivalent to JNI primitive types (such as bool for
jboolean, or int for jint) in QJniObject and some QJniArray APIs. Make
this symmetrical for QJniArray::to/fromContainer.
Add more compile- and run-time time test coverage.
Change-Id: I8cc84e6181a93f889282d2d3f0a05207416c4dbe
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit d9dd8c4986373789b8bd250d0c2b36b660fe210f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Add a template parameter that is defaulted to what our logic would
select as the appropritate container type. If the type is contiguous
and the element is primitive, use the optimized implementation with
the JNI helpers for copying the entire array region.
Otherwise, use an emplace_back loop.
Change-Id: I669bc3261f111bc0c7e3dd2af8fd33293c083801
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit a6b1f80cd6c833f6eb2fbfb778254cd7fcbc000f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
glibc introduced the glibc-hwcaps/XXXX path in glibc 2.33 (2020) and
removed the old, legacy "haswell/" prefix in glibc 2.37 (2022). This
means anyone deploying HW-capable libraries must be deploying symlinks,
so we are not losing functionality.
Because it says "glibc-hwcaps", I am now making this dependent on glibc
for libraries.
Added unit testing for this feature. Tested on Linux, FreeBSD, macOS,
and Windows (the QLibrary test SKIPs everywhere except Linux). We do
create a "libtheplugin.dylib.avx2" on macOS with this change, but won't
attempt to load it (Darwin has fat binaries so lipo(1)ing the files
together would be the right thing to do).
Change-Id: Ic0adfa808d28487a8303fffd17d9e78ec87bbd9a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit a1db2959129cb4630adfffcaaece19bafe16db77)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The QThreadPrivate::finish() cleanup code is not prepared to be
subjected to POSIX cancellation: if, like on glibc, thread
cancellation is implemented by stack ununwinding, we get exceptions in
dtors and therefore std::terminate(), and otherwise, we leak
resources.
It would be very hard to make the code robust against this, as it
would require all cleanup to be wrapped in pthread_cleanup_push/pop,
with the added problem that these functions need to appear in the same
lexical scope. Another alternative would be to move all cleanup code
into a thread_local destructor, but it's not clear whether code
running as part of thread_local destruction would be exempt from
cancellation, and it would be a major rewrite.
The simplest method is to disable cancellation for the remainder of
the thread lifetime in the shutdown code, just like the startup code
only enables cancellation after initial setup, so do that.
[ChangeLog][Important Behavior Changes][QThread] On Unix,
fixed a race of QThread::terminate() with normal thread exit (running
off the end of run()) which could corrupt QThread's internal cleanup
code. The fix involves disabling thread cancellation for the remainder
of the thread's lifetime once control reaches QThread's cleanup
code. If you rely on a PTHREAD_CANCELED return status, be aware that
this change may mask late cancellations. Likewise, slots connected to
QThread::finished() using Qt::DirectConnection are now run in a regime
where thread cancellation is already disabled. If you need
cancellation in that situation to work, you need to define your own
finished()-like signal and emit that at the end of run().
Fixes: QTBUG-127008
Change-Id: I23030eefdfcebf0a6d6796db5cbbbf0812ae12c0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 01d4be4a8327458a3242804594b498f840480289)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Mårten Nordheim
Soheil Armin
Thiago Macieira
Jøger Hansegård
Marc Mutz
Ivan Solovev
Lucie Gérard
David Faure
Edward Welbourne
Giuseppe D'Angelo
Ahmad Samir
Volker Hilsheimer
Rym Bouabid