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 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>
Amends 65093a84c2b94b1543fd4593bc45d491951d28d4, which changed how we
destroyed the main thread's QThreadData. This merges the call to
destroy_current_thread_data() for both types of Unix systems: those with
broken thread_local destructors and those with working ones. It turns
out that the function got called too early for us in those working
systems (see updated comment).
The clean up of the QThreadData is split into two different mechanisms:
* for any auxiliary thread, when it exits, PThread will call back to
destroy_current_thread_data()
* for the thread that called ::exit(), PThread won't, but ::exit() will
invoke set_thread_data()::TlsKey's destructor
This is different from the situation that existed prior to commit
65093a84c2b94b1543fd4593bc45d491951d28d4: first, there's no code in
qcoreapplication.cpp for this (all in qthread_unix.cpp). Second one may
call ::exit() from any thread, whether that is the thread that called
main(), the thread Qt thinks is theMainThread, or any other.
This commit moves the tst_QCoreApplication check for no extant objects
to a new test. I've chosen to add a new test instead of running a helper
binary via QProcess because we do have a couple of !QT_CONFIG(process)
platforms in the CI, and this is too important.
Credit to OSS-Fuzz for finding this, though it is not itself a fuzzying
problem (all tests of a given structure were crashing on exit).
Fixes: QTBUG-132381
Task-number: QTBUG-130895
Task-number: QTBUG-129927
Task-number: QTBUG-129846
Task-number: QTBUG-130341
Task-number: QTBUG-117996
Change-Id: Ie294dce7263b4189f89ffffd9155ec71d31b89d9
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 1da7558bfd7626bcc40a214a90ae5027f32f6c7f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 6dc19b55fc6d6dd3198b744f713101cf3b77c0c8)
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Android 15 (at least) seems to have changed how float arguments are
passed to native functions, breaking our (conceptually correct) code for
processing the va_arg list into a list of static argument types of the
function implementation.
To fix this, we have to move away from using a va_arg function, and
register a function with statically typed arguments instead.
Use a template function that we instantiate with variadic arguments
deduced from the actual function, using a factory-helper that generates
a JNINativeMethod struct with that template instantiation as the
function pointer. Move all of that into a struct where we can also
declare the signature string as compile-time constant without cluttering
the namespace with static objects.
We can now remove the helpers that took care of type promotion in va_arg
functions, and of the tuple-construction from a va_list.
As a drive-by, don't cast function pointers to void *; it's strictly
speaking undefined behavior in C and should have generated a compiler
warning, if not a hard error [1]. We must initialize the
JNINativeMethod::fnPtr member with the address of the function pointer
instead.
[1] https://port70.net/~nsz/c/c11/n1570.html#6.3.2.3p8
Also, declare the native method as the JNICALL calling convention. That
is only defined on Windows, so makes no difference in practice, but it's
the correct thing to do anyway.
Fixes: QTBUG-132410
Change-Id: I190b95fcbcd07cf99c6765fa426c3c351f91994a
Reviewed-by: Volker Krause <vkrause@kde.org>
(cherry picked from commit e91a17873ee4ae58d369b8eb70029cf895b31d03)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 103aa5afb2d95f883daea41715c97455550285b2)
Demonstrates the problem described in the bug report on Android
15/x86_64. QEXPECT_FAIL the relevant test cases until the next
commit fixes the problem.
Task-number: QTBUG-132410
Change-Id: I065fd29282ef42ed75a2ed8177ded183c92aa6e3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 749367da8c3309c98b3285836c2bd8abcd7274b1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit e342a5261332c2ef2c3b0d4d14f22dbdbd4a99c3)
Commit 1ed0dd88a3 ("QThread/Unix: make
QThreadPrivate::finish() be called much later") introduced this problem.
Commit 4fabde349f16b59f37568da2a4c050c6dd53a34e split the thread
termination in two phases, but did not fix this.
This re-applies commit 950b35cf97 ("Clear
the current thread data for the main thread"), which was reverted in
commit 7dc622290b ("Make sure QThreadData
and QAdoptedThread object is destroyed at app exit"), both from Qt 5.1.
Between Qt 5.1 and 6.7, the responsibility of clearing the
QAdoptedThread for the main thread was split: it could occur either in
~QCoreApplicationData if exit() was called in that thread or in
~QThreadData() if it wasn't (e.g., when the Qt "main thread" is not
main()'s thread):
* frame #0: 0x0000000101db8a28 QtCore`QAdoptedThread::~QAdoptedThread(this=0x000060000176c070) at qthread.cpp:139:1
frame #1: 0x0000000101db81eb QtCore`QThreadData::~QThreadData(this=0x0000600002468000) at qthread.cpp:82:5
frame #2: 0x0000000101db8379 QtCore`QThreadData::~QThreadData(this=0x0000600002468000) at qthread.cpp:57:1
frame #3: 0x0000000101db841c QtCore`QThreadData::deref(this=0x0000600002468000) at qthread.cpp:108:9
frame #4: 0x0000000101f4ec79 QtCore`destroy_current_thread_data(p=0x0000600002468000) at qthread_unix.cpp:104:11
This commit centralizes and gives ~QThreadData() the exclusive
responsibility. That requires not resetting QThreadData::threadId so
~QThreadData can know it is theMainThread.
Fixes: QTBUG-130895
Task-number: QTBUG-129927
Task-number: QTBUG-129846
Task-number: QTBUG-130341
Task-number: QTBUG-117996
Change-Id: Ie3f3cbdc5523837b505cfffd95fba5e6498b5069
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 65093a84c2b94b1543fd4593bc45d491951d28d4)
QWinRegistryKey::value<T> returns an optional<T> which can make code a
bit more readable than the std::pair<DWORD, bool> return value from
QWinRegistryKey::dwordValue.
This implements part of the "TODO: Remove once all usages are migrated
to new interface." comment in QWinRegistry class because it allows us to
remove the QWinRegistryKey::dwordValue function.
Change-Id: If568de4e31778e91ce7aadadb4aac90e41222826
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 7a63a25ef71fbbe7b3eaa6ecb9a26c3e497e582a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Amends 7a7f2547f3, which added the triplet
including the script before the language_Territory name without it. The
truncate-from-the-end algorithm in QTranslator ended up trying the pure
language first, and - if found - ignored any more specific territory-
variant that might be present.
To fix this, replace the truncate-from-the-end algorithm when we try
to find files, and instead create a comprehensive list of fallbacks,
avoiding duplicates as we go along. Insert those fallbacks right after
their base-entry. We then try to find files for each entry, with and
without the prefix.
This fix is needed only in 6.8 and 6.5; from 6.9 onwards, the change to
QLocale::uiLanguages in 84afaafc9c6968dd76fcadc5392065d340543521 fixes
this on the correct level, making kludges in QTranslator unnecessary.
As a drive-by, replace int indices in for-loops with qsizetype.
Fixes: QTBUG-124898
Pick-to: 6.5
Change-Id: Ia3deceb4ed2c6ef5ca0a815cc7b8878bf29ef088
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When Q_PROPERTY is used to define a property with type (for example)
Qt::Alignment the name of the type stored in the meta-object is
"Qt::Alignment".
When QMetaObjectBuilder.addProperty() is used it will instead use the
name of the meta-type (ie. "QFlags<Qt::AlignmentFlag>") which it has
obtained from QMetaType::fromName("Qt::Alignment").name().
In the QMetaProperty ctor it tries to resolve the QMetaEnum for the
property and uses the internal parse_scope() to extract the scope and
qualified key from the name. However it does not handle template names
and so fails with dynamically created properties.
This change to parse_scope() removes the "QFlags<>" so that the
template type can then be parsed.
Another solution would be for addProperty() to always use the type name
it was given rather than use QMetaType::fromName(). That has the
advantage that the layout of the dynamic meta-object would match that
generated by moc.
Change-Id: Iac9e2db2f134029709158b4e500286922396501d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 5624060865e3ccd3c487f10355cb740b7322f93c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Add test coverage for the bug reported in QTBUG-124898 with
QEXPECT_FAIL to document the failure in our truncation logic in
QTranslator.
The attempted fix in 9a11273b745a30cebb5cd648c89eb224e9704492 then
introduced QTBUG-129434, as we ignored the order of languages reported
by the system locale. Add a test case for that, and use a QSystemLocale
subclass inspired by the QLocale unit test to override the system locale
with a specific one that supports multiple languages for this test.
Pick-to: 6.5
Task-number: QTBUG-124898
Task-number: QTBUG-129434
Change-Id: Iaae80d29e267fd3a2d14df0e73db27ba4c58b31a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit 1f2ab46745af12e4776695c1b1a2523ac170368e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We need to put metatypes in the correct place; this is especially vital
starting with Qt 6.9, given that we need it to query it to figure out
whether we have a 64bit value or not.
As a drive-by, replace some ugly casting when constructing the meta-type
array with a call to QMetaType::iface.
Change-Id: I4b1f42f974e9f7a21f6aa4c87c3f8919f6965d6e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit d392d3b22c94f86fea50f26284bc9ac8b35f6851)
The property observer reference used during binding evaluation can
become invalidated as the container used to maintain the
the observer would invalidate the existing observers during its
resize, leading to referring to invalid memory.
Recognize that we do not need to store the observer, but only its
binding - the observer itself is not used later.
Therefore, change the PendingBindingObserverList to become a list of
QPropertyBindingPrivatePtr to avoid the issue.
Fixes: QTBUG-127596
Original-patch-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Pick-to: 6.5 6.2
Change-Id: I8c97721ca563083d6280194175f8a915dac2ff04
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
(cherry picked from commit 275202215376238bf414d5008d3c727085e58a4c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This reverts commit 9a11273b745a30cebb5cd648c89eb224e9704492.
Reason for revert: The fix tried to find a sensible order if
the same language is listed multiple times in QLocale::uiLanguages().
Anyhow, it breaks for lists where entirely different languages are listed. This needs more thought.
Fixes: QTBUG-129434
Pick-to: 6.7 6.5
Change-Id: I8c074cbf1ddc2ddf223ec09aef38dfc1ef7fc85f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit f3fc7b210f79e5eb427b0ff49c45c5d6d390fb34)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit a30c1bcd3c8b8eb4befeb254840224ca7bb52497)
QObject::disconnect does not cancel pending events. This can cause hard
to find bugs in application code, so we explicitly document and unit
test this behavior.
Task-number: QTBUG-127675
Change-Id: I5e94d60c27b9ce2dd2bceb832eb817b7eaa9cdcd
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 0681e720a9851f1873ce5a5f99b5567d2b418261)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Make sure this works as it should. The bug report/support request wants
to have a String[] parameter on the Java side, but then the C++ side can
not use jobjectArray (as that has "[Ljava/lang/Object;" as signature),
so use Object[] instead (which is one solution; the other is to use
QList<jstring> or (in 6.8) QStringList on the C++ side.
What's easy to miss is that the jobjectArray that we get is a local ref,
so we have to extend its lifetime by creating a QJniObject holding it as
a global reference. We can then create a QJniArray from that QJniObject
(without any type safety).
Task-number: QTBUG-128456
Change-Id: I1e03b811165f9bc5106324d39fb58114ee8cf398
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
(cherry picked from commit f9fd5870f7379103005839bc03543bb8f6da94c3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They match what QTimer already provides these days, and we want to
minimize porting for users come Qt 7, so we don't want users to first
write QChronoTimer::singleShot() (because it exists) and then back to
QTimer::singleShot(); we want them to continue to use QTimer.
The only reason QChronoTimer is a separate class from QTimer is that
the latter has an int interval property and we can't just port it to
milli- or nanoseconds chrono types if we want users to actually access
the extra range or precision afforded by the chrono types. But that's
not an issue for the singleShot() static methods, as they never return
an object that could be asked for its timeout.
(No ChangeLog needed, as QChronoTimer is new in 6.8)
Found in API-review.
Fixes: QTBUG-128426
Change-Id: Ief8b7c8d25380c0e9e9c5c36c90ce34c147557ae
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 6e5eb082c934cb94c45f3e13b3f7c2deb2e7b2e6)
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>
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>
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>
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 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>
We cannot go from member function pointer to method index for slots (we
can for signals), so using string-based syntax to connect and PMF-syntax
to disconnect doesn't work, and vice versa.
Document this in a (partially failing) test, and add a warning to the
relevant QObject::disconnect documentation.
Task-number: QTBUG-126580
Task-number: QTBUG-126581
Change-Id: I4b17662aa9aa7b624049c5b0a3b046ed35230f05
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 27a3229626249a100d8e6fa495927715aba6963d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Sadly, inline namespaces are resulting in ambiguities. With two
declarations
QtJniTypes::android::io::File
and
QtJniTypes::org::qtproject::qt::android::QtWindow
referring to QtJniTypes::android already is ambiguous if `org`,
`qtproject`, and `qt` namespaces are all inline. This breaks the
idea behind Q_DECLARE_JNI_CLASS as a variadic macro that generates types
that we can transparently use as QtJniTypes.
So remove the inline keyword from the namespace declarations. The macro
might still be the way to go, but user code will to either fully qualify
the types, or use `using namespace QtJniTypes::java::lang` to use e.g.
the `String` type without ambiguities.
Types declared with the two-argument overload continue to live
directly in the QtJniTypes namespace anyway.
As a drive-by, break the excessively long lines.
Change-Id: Ie9303e6c9117fb96b3cff31c7df4df92237b5520
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit d1b89671de70ac9ffca52337058e976d86a367c1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A locale's UI language includes the script, e.g. the QLocale::uiLanguage
list for the Australian locale en_AU is {"en_Latn_AU", "en_AU", "en"}.
The old code iterated over each language in the outer loop, and for each
language tried several times, removing a segment from the back with each
try in the inner loop. The de-facto search order was then
en_Latn_AU
en_latn_au
en_Latn
en_latn
en
en_AU
en_au
en
Usually, translation files are provided for country_Territory, i.e.
en_AU. But if an en file (for a generic English translation) was also
present, then en_AU was never tried.
Fix this by breaking the logic into two loops: first, create a list of
candidates by removing segments from each UI Language. Then sort that
list of candidates so that entries with more segments come first. The
search order is now:
en_Latn_AU
en_latn_au
en_Latn
en_latn
en_AU
en_au
en
This way, en_AU gets loaded correctly, before en is tried.
Adjust the test, which was essentially duplicating the logic from
QTranslator to generate files. This only tested that two identical loops
result in the same thing. Instead of using the system locale, make the
test data-driven, and explicitly try en_US and en_AU, with candidate
files generated based on a hardcoded list for each data row.
Pick-to: 6.7 6.5
Fixes: QTBUG-124898
Change-Id: I6bdcff289d2843e61c9053c116e955b79e09e95a
Reviewed-by: Mate Barany <mate.barany@qt.io>
(cherry picked from commit 9a11273b745a30cebb5cd648c89eb224e9704492)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When the Java array that we hold a reference to is changed on the Java
side, then our reference continues to be valid, and references a
different object than the new array in Java.
Change-Id: If8743cc1b2fabb254b9c0009f41377455719ec3e
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 37bb00d8507a4def05b5d85a6ef4ea23cca70ab6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This avoids that we or users have to declare e.g. String or Uri in
several places in Qt. This also prevents problems where multiple
declarations (possibly from different headers) cause build errors.
As a drive-by, remove some unnecessary type declarations (e.g.
UriType, which had the same class string as Uri).
To ease the submodule update process, define a preprocessor symbol
that submodules can use to conditionally declare the type locally.
Once the dependency update is through, the symbol can be removed
and submodules can use the declaration from qjnitypes.h.
Change-Id: I7d96edf644a54246302b5c5cb478e66fa615e73e
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 457a1c973d68e705f9cf72ac72b19fc26cdb2917)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Make the macro variadic. For N > 2 arguments, interpret the first
N-2 arguments as nested namespaces that are declared as inline
namespaces. We can then construct the signature string from those
namespaces, so
Q_DECLARE_JNI_CLASS(String, "java/lang/String")
is equivalent to
Q_DECLARE_JNI_CLASS(java, lang, String)
except that with the second overload, the C++ type will be in the
QtJniTypes::java::lang namespace. Since both the java and the lang
namespaces are made inline, QtJniTypes::String still works.
This helps with avoiding conflicts, as there might be Java classes
in different packages, but with the same name.
Change-Id: I0355239e7fc3c91cb26e041f19c4e0853d3678ac
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 2b1312bc954b72f59d0c1d7b1192e2f029016012)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This is expected behavior for default-constructed containers.
Also add the missing isEmpty() member function to QJniArrayBase.
Change-Id: I23111f6906ef5476567272cb23746fec962afa35
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit e5516191b25d70ee9d6e87246d932fa559ef0b59)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
tst_QCoreApplication test fails due to leaking object. Investigation
about the reason of this issues was started, but no conclusion was made
and reason for object leak is still unknown. To prevent this test from
crashing exclude this check for VxWorks as well.
Pick-to: 6.7
Task-number: QTBUG-115777
Change-Id: I2c543a3b8320e2d96b2e7cd7e14c1980e500ce0d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 92e420aefb373c2dc1dd39a05ff43037edb2a145)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Makes sense to collect the stuff in a similarly-named header, and it's
not like any of the QTypeTraits stuff was needed for QTypeInfo.
Makes #include <qtypeinfo.h> _much_ lighter again, at the expense of
qminmax.h now getting <variant>, <tuple> and <optional> instead, but
qminmax.h is much easier to avoid in Qt headers (just use the std
versions) than qtypeinfo.h.
[ChangeLog][QtCore][Potentially Source-Incompatible Changes] The
qtypeinfo.h header no longer transitively includes <optional>, <tuple>
and <variant>.
Task-number: QTBUG-97601
Change-Id: Ied96113f38c1232fef3ec79847ee62f06c68f268
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit b2eb422699118f4ae8370519b4c7bb3fe121beb2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Provide the new comparesEqual() helper function as an implementation of
(in)equality operators.
Use QT_DECLARE_EQUALITY_OPERATORS_HELPER macro instead of
Q_DECLARE_EQUALITY_COMPARABLE for the comparison between QPointer<T>
and QPointer<X> to avoid creating the reversed version of the
operators in C++17 mode.
Use new \compares command in the documentation to describe the
comparison operators provided by QPointer.
Task-number: QTBUG-120306
Change-Id: Iff24d3ef5c790de7f06ab825f853e06186fa1471
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Issue introduced by a68e4f3b96 ("Use the
new QMetaType API in QVariant") in 6.0, which removed the d.is_null
reset at the same time as it replaced the std::destroy_at /
std::construct_at pair with an assignment operation.
[ChangeLog][QtCore][QVariant] Fixed a bug that would allow the class to
keep returning isNull() = true even after calling setValue().
Fixes: QTBUG-125472
Pick-to: 6.5 6.7
Change-Id: If05cb740b64f42eba21efffd17d13f6b1e8113c2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use new term in examples, code comments, error messages and and mime types.
Task-number: QTBUG-122253
Change-Id: I355452d6eb02a7a0ffbb20acf82ddb8ebbfa4837
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Replace public friend operators operator==(), operator!=(),
of QElapsedTimer to the friend method comparesEqual().
Add compareThreeWay() for the <=> operator.
Save friend bool Q_CORE_EXPORT operator<() method and
add defined(__cpp_lib_three_way_comparison) condition for the C++20
spaceship operator.
Task-number: QTBUG-120304
Change-Id: I575865403f4e333578ff174e8e6879e8925d4b09
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Internal QPropertyBindingPrivatePtr, QArgumentType classes
also have been updated;
Replace class operators operator==(), operator!=() of
QRegularExpression to friend method comparesEqual() and
Q_DECLARE_EQUALITY_COMPARABLE macro.
Task-number: QTBUG-120304
Change-Id: I010617cbcb8bd6afb7c21ee4345398648821f72c
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Test more scenarios, like separate namespaces, free enums, etc.
And test that the enumerator() function returns a valid QMetaEnum when
expected.
Change-Id: Ie4fa816ffb66d6b6e1b4c7c50674c31eddbd642e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Now developer build tests compile, but some are not working.
Functional fix will come later via separate tasks.
Task-number: QTBUG-122999
Change-Id: I70487b46c1b32ba4279cb02a4978e4f55ac0d310
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace public friend operators operator==(), operator!=() of
QMetaMethod to friend method comparesEqual() and
Q_DECLARE_EQUALITY_COMPARABLE macro.
Task-number: QTBUG-120304
Change-Id: Idb3f880a1db4850d73a58ed37f8cbd3454dd5ea2
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Thiago Macieira
Edward Welbourne
Volker Hilsheimer
Volker Krause
Jøger Hansegård
Phil Thompson
Fabian Kosmale
Santhosh Kumar
Kai Köhne
Tim Blechmann
Marc Mutz
Michał Łoś
Rym Bouabid
Tatiana Borisova
Mårten Nordheim
Jari Helaakoski