This has to be done from all places where we deref it. Otherwise we leak
memory.
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-116086
Change-Id: I57307ac746205578a920d2bb1e159b66ebd9b2cc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The relational operators were removed in
8652c79df0 with the argument that they
do not have a total order. Back than it was a valid argument, because Qt
did not support any of the C++20 ordering types.
Now Qt has its own implementation for all three ordering types, so we
could technically add relational operators and claim that QVariant
provides partial ordering.
However, that could potentially lead to many bugs and/or unexpected
results, if people start using QVariant as a key in std::map/QMap
containers.
We do not want that to happen, so we only use the helper macros to
implement (in)equality operators.
This commit also extends the unit tests, providing more extensive
testing of (in)equality operators and the pre-existing
QVariant::compare() method.
Fixes: QTBUG-113234
Change-Id: I783f3b5df552da782627f4ed0a5bb1b577753a23
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The variadic templates are supposed to be removed from the
overload set when any of the parameters is a literal string type,
as otherwise we get conflicts with the legacy overload taking
class names and signatures as const char *. The detection of
a literal string types was missing a few specializations, so that
we ended up with the wrong overload being called, and class
names getting interpreted as method names instead.
Add the missing specializations, and add more test coverage
for using the old overloads.
Task-number: QTBUG-122235
Pick-to: 6.7
Change-Id: I5488f2009c8f62d74fac6754844f57cf64011414
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Lauri Pohjanheimo <lauri.pohjanheimo@qt.io>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Task-number: QTBUG-121787
Change-Id: Iee9f4fca676e77ab9d8ed485a28ce5ea8803be15
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Which will be used to represent timer IDs. Thanks to Marc for the idea
to use "a strongly typed int".
QTimer got a new id() method that returns Qt::TimerId (can't overload
timerId()). Various classes in qtbase have a member named timerId(), but
a new method is needed anyway in QTimer so id() it is (this is the
reason QChronoTimer only has id() and no timerId()). Besides
timer.timerId() has an extra "timer".
This commit fixes the inconsistency between QObject using `0` timer id
to indicate "failed to start", while QTimer::timerId() returned `-1` to
indicate "timer is inactive". QTimer::id(), being a new method and all,
now returns Qt::TimerId::Invalid, which has value `0`, so that the
values match between the two classes. Extend the unittests to ensure
QTimer::timerId()'s behavior is preserved.
[ChangeLog][Core][QObject] Added Qt::TimerId enum class, that is used to
represent timer IDs.
Change-Id: I0e8564c1461884106d8a797cc980a669035d480a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The interval in QTimer is a QProperty of type int, which means it's
limited to the number of milliseconds that would fit in an int (~24
days), this could cause overflow if a user constructs a QTimer with an
interval > INT_MAX milliseconds. And it can't be easily changed to use
qint64/std::chrono::nanoseconds:
- changing the getters to return qint64 means user code would have
narrowing conversions
- the bindable QProperty interval can't be changed to qint64 during
Qt6's lifetime without the risk of breaking user code
- adding a new bindable QProperty that is qint64/nanoseconds is an
option, but it has the complication of what to do with the int
interval; set it when setInterval(milliseconds) is used by using
saturation arithmetic? and what about notifying observers of the
changed interval?
Thus the idea of creating a new stop-gap class, QChronoTimer, as a
cleaner solution. Both classes use QTimerPrivate.
During the lifetime of Qt6, QTimer's interval range is about 24 days,
whereas QChronoTimer's interval range is about 292 years
(duration_cast<years>nanoseconds::max()).
Currently the plan is to fold QChronotTimer back into QTimer in Qt7.
Mark all QPropertyS in the new class as FINAL since they aren't
intended to be overridden; this offers a performance boost for QML[1].
[1] https://lists.qt-project.org/pipermail/development/2024-February/044977.html
[ChangeLog][QtCore] Added QChronoTimer, which uses a
std::chrono::nanoseconds intervals, as a replacement for QTimer.
Fixes: QTBUG-113544
Change-Id: I71697f4a8b35452c6b5604b1322ee7f0b4453f04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Ultimately this is the best way to keep the log history of the code.
Change-Id: I3413deffdb093a3239d65b6ca939e744224e722a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add implict constructor, treat the list like any other container.
Simplify the test code, and explicitly constructor-initialize when
we want an array and might have an array, so that we don't end up
with constructing arrays of arrays.
Change-Id: I14615f897cf8a2188510cfe1085ffc70a2396d5d
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Since we support QString and QList specializations, we should also
support QStringList directly. That's a bit more involved as we need
to specialize the code path for QString, which is not convertible to
or from jobject. But once we have mapped the type to jstring it
follows the implementation for lists of objects.
We now need to generate temporary local references when
converting a QString to a jstring, so manage a local frame. We do
so explicitly in chunks of 100 local references.
Change-Id: I7ae5cf7d0ba0099992c36f3677980c346526804b
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This didn't work yet because the partial specialization of the
JNITypeForArgImpl factory was missing. Add a test case for
QJniArray<double> and QList<double>.
What doesn't work (yet) is QStringList for a native Java function
taking a String[]. That will be added in a follow-up commit.
Change-Id: I4d3fa0ecc04b98b9749f8358792f86c02ddbbc14
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
QObject::startTimer() returns 0 in case of failure, for example when
someone tries to register a timer with a negative interval.
However, QTimer internally uses -1 as an invalid timer id.
This could lead to a situation when the timer was not really started,
but QTimer::isActive() returned true.
This patch fixes it in two ways:
- check the return value of QObject::startTimer() and treat 0 as an
error.
- do not treat 0 as a valid timer id when calculating the active state.
As a drive-by: move the `using namespace std::chrono_literals;`
declaration to the top of tst_qtimer.cpp, so that we do not need to
repeat it in each test case.
Fixes: QTBUG-122087
Pick-to: 6.7 6.6 6.5
Change-Id: I0e21152b2173ebb5fb0dada1b99a903a321ca9c4
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Don't rely on timer precision and use int counter instead.
Amends 1fe88bf4cd
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: I057b4dd51014784ec9b244301b43583f3de6ddd1
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
installEventFilter() prepends new objects to the eventList, so that
events that are posted while processing events are left to the next
round of event processing.
This is a baseline test to check that subsequent commits preserve the
current behavior.
QCOMPARE_GT is available since Qt6.4, so make the check backportable to
older releases too.
Pick-to: 6.7 6.6 6.5 6.2 5.15
Task-number: QTBUG-120779
Change-Id: I5ed5e9c2917a9be62de4af19c3b72889399b4fe6
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Don't call the native function directly, call the Java function that
calls the native function.
Pick-to: 6.7
Change-Id: Icdcf250313a38f6e4bc2b90fb7b0adbfa5a890fb
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Add rbeing/rend overload, relevant typedefs, and decrement operators.
As a drive-by, add noexcept to begin/end functions.
Found during header review.
Pick-to: 6.7
Task-number: QTBUG-119952
Change-Id: I32d9a7d50a1f03550944c2247516c455d4822fe7
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Augment test case. Found during header review.
Pick-to: 6.7
Task-number: QTBUG-119952
Change-Id: I326395397167edb05ff1f45f7151614c02b7e7eb
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Add missing nested typedefs for both the QJniArray container and
the QJniArrayIterator. Expand test case to make sure that some standard
algorithms (such as std::distance and ranged for) work with those
types.
Found during header review.
Pick-to: 6.7
Task-number: QTBUG-119952
Change-Id: I96f348215c6f1e0e1ce777d9bdd2f172d7e52974
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The moc generated code does a sanity check that NOTIFY signals actually
exist in the parent class when they cannot be found in the class moc
currently runs on.
The logic there was however too simplistic, and couldn't deal with
signals taking a parameter.
Fix this, and take the opportunity to use a proper static_assert instead
of generating a "normal" compile error.
We do not do any checks for the presence of QPrivateSignal, as the whole
point of QPrivateSignal is that it should be private (and not e.g.
protected).
Moreover, we adjust QMetaProperty::notifySignalIndex to take
single-argument notify methods into consideration as well when
encontering an unresolved notify index.
Fixes: QTBUG-115989
Pick-to: 6.7
Change-Id: I8a056a15777f3132691e207b4b9ab6c2c9b2126d
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add bool QObjectPrivate::moveToThread() which returns the success state
of the attempt to move the object to the new thread. For Qt7 the public
signature of QObject::moveToThread() should be changed to directly
return this value.
[ChangeLog][QtCore][QObject] QObject::moveToThread() now returns a
boolean success state.
Pick-to: 6.7
Change-Id: I8441c8155a76b804b473ab9c45c2be6840ef1677
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Iterators are required to be default-constructible and
value-initialized iterators must compare equal.
In a const_iterator, the pointee should be const, not
the iterator itself.
Found during header review.
Pick-to: 6.7
Task-number: QTBUG-119952
Change-Id: I036c0a62ade8c59dc5d62c0823b375223719af3f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Fix build of the test by removing the reference from the
container type before accessing the nested typedef.
Pick-to: 6.7
Change-Id: Ic35f312bac70b8f8f80149a3432329070c8c8c7d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
An assert is harder to miss than a warning, which makes it more likely
to get fixed. Thanks to Mårten Nordheim for the idea.
Add the assert in inline code so that users compiling their code in
debug mode (or with -DQT_FORCE_ASSERTS) can hit the assert even when
built agaist a release build of Qt (not everyone compile their code with
a debug build of Qt). Thanks to Giuseppe D'Angelo for the idea.
Pick-to: 6.7 6.6 6.5
Task-number: QTBUG-115125
Change-Id: I2935d32ea5a2c288d7a836abbae66ac53cb5ab2f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Both the GUI and core version of that test is flaky on QNX.
Pick-to: 6.7 6.6
Task-number: QTBUG-119359
Change-Id: Ied7013e04bdd12270a84ab32d2bd4e45c52136c3
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Instead of introducing the nested class InheritsQUntypedPropertyData
as a sentinel class for inheritance check, we can use BinaryTypeTrait
to handle the check. By doing this, we no longer need to maintain the
nested class.
Change-Id: Ie3aae976015d5fae6b6d072cad6ee52cd30b769d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
GCC at some point decided that it wouldn't include the full namespace
expansion in __PRETTY_FUNCTION__ for any type that is in the same
namespace as the template function being expanded (that is, the
QtPrivate) namespace. I don't know how long this behavior has been in
place, but it can be seen with GCC 13, where the expansion of that macro
inside QtPrivate::typenameHelper<QtPrivate::ModelIndex>() is:
constexpr auto QtPrivate::typenameHelper() [with T = ModelIndex]
This can be easily worked around by using a different namespace.
Fixes: QTBUG-119650
Pick-to: 6.6 6.5 6.2
Change-Id: Ica7a43f6147b49c187ccfffd179df309e43a70cb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
For an unscoped enumerator, e.g.:
namespace N {
class C {
enum E { F };
};
};
N::C::F and N::C::E::F are equivalent and key(s)ToValue should match
both.
This already works for scoped enums because the name of the enum can't
be dropped.
Fixes: QTBUG-118240
Pick-to: 6.6
Change-Id: I84d7bbb7aa8f82b2a7c2bc7e4edd5d77d37335c4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There's no point to the file if it has no content.
Change-Id: Ie0deb59a63d5f7a654fcab1218e0a814710072ff
Reviewed-by: Jason McDonald <macadder1@gmail.com>
The same test code is compiled by two different modules' tests, which
won't be obvious to the reader of the code unless it's pointed out
explicitly.
Change-Id: I99dba6eb186939c372636c5c1fc29799003d32a7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The test log shows flaky failures of this test several times a day on
QNX, so blacklist it.
To do that, we need to be able to isolate the "GUI" mode of this test.
To do that, add a single data tag that depends on whether the test
project is built for GUI or Core, and blacklist only the "gui" data tag.
Task-number: QTBUG-119359
Pick-to: 6.6
Change-Id: I91c2380de0a3febedcf781f27fed4a1fa6aa5515
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add an overload of findChild() without a name argument to be able to
call the function with options value only.
[ChangeLog][QtCore][QObject] Added findChild() overload taking no name.
Task-number: QTBUG-103986
Change-Id: Id06b6041408fcf4cc1eeba975afce03f3a28f858
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
It's used to build different variations of the unittest,
linking against QtCore-only/QtGui, with/without GLib, that's four
individual tests.
Change-Id: Iaf0f37041dbb148134631f86be99feaa881a8ce8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change the object's name type in QObject::findChild/ren() to
QAnyStringView, because they are only used for comparison against
objectName property.
qt_qFindChild{,ren}_helper() functions taking an objectname as
QString have to stay in the ABI as they were exported in inline
methods before Qt 6.7.
Unlike QString, constructing a null QAnyStringView doesn't involve
any code-size overhead. So, get rid of the split in qt_qFindChildren_helper
that was introduced for QString. Remove unneeded
qt_qFindChildren_with_name helper function and qt_qFindChildren_helper
overload without a name.
findChildren(options) method used to call qt_qFindChildren_helper overload.
Instead, call findChildren overload with name argument and pass
QAnyStringView{} as the object name.
[ChangeLog][QtCore][QObject] Ported QObject::findChild/ren() and
their helper functions to QAnyStringView.
Task-number: QTBUG-103986
Change-Id: I68bda0e581f984ae48b7581ad86cc1b95008c1b0
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Add a template overload for the QJniEnvironment member function so that
a declared type can be used.
And add a static registerNativeMethods class member function to declared
types.
As a drive-by, document the initializer_list overloads. The
"template <typename Class>" convenience wrappers are currently all
undocumented, as we first need to document the QtJniTypes type system
and declaration macros.
Change-Id: I8ff9edc4e493694e6d2c26d4bc7b06bd8e05bf0c
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Expect a jstring on the va_list, and implicitly construct a QString from
that.
As a drive-by, allow native methods to take parameters by reference, and
move implementation details into a Detail namespace.
Add test coverage.
Change-Id: I31214938ccaea3f4d539b432e29d12434dd98377
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This patch provides the actual implementation to detect binding loops
in property setters.
These test will help to catch all the existing binding loops that were
introduced when migrating to new bindable properties.
The logic of the new tests is taken from
tst_QObject::objectNameBinding(), but generalized to be applicable to
all bindable properties.
The original code from tst_QObject can now be removed.
The patch effectively reverts f791570b86
because a lambda returning a nullptr now means that the binding loop
test should be skipped, which is not a good default behavior.
Now when all the existing bindable properties are fixed, it's fine to
give a compilation error when adding new tests, if the class is not
default-constructible.
Task-number: QTBUG-116345
Pick-to: 6.6 6.5
Change-Id: I059d444d4bb023c050a22e5b1974565e4f581b5c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
On Android, `long` has the width of the system, while `jlong` is always
64 bit. If we support `long` as a signature type equivalent to `jlong`,
then it becomes possible to write code that fails to compile, or in the
worst case crashes at runtime, on a 32bit system.
Instead, support quint64, which is always the same size as jlong.
Change-Id: I60432ec7411e697b5f6e1f153216ceee0af7e0f1
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
- Show warning messages for malformed keys string
- Use QBAV instead of QL1SV, some methods in the public API may get
QU8SV overloads in later commits
- Extend unittests; also rename the unittest, it's really testing
key(s)ToValue()
Change-Id: Iec944ef4c2c5d18ab038cb933e954cf50c912523
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Remove qt_poll_msecs() since the "forever" state can be simply expressed
with a QDeadlineTimer::Forever arg, instead of passing a nullptr
timespec, and the negative timeouts treated as "run forever" is also
encapsulated by QDealineTimer.
Use the QDealineTimer(qint64) constructor in the call sites where
the timeout could be negative, so that it creates a Forever timer (the
QDeadlineTimer(chrono::duration) constructor uses
setRemainingTime(duration) which handles negative timeouts by creating
expired timers).
Remove qt_gettime() (and do_gettime()).
Drive-by changes:
- Fix a narrowing conversion warning, qt_make_pollfd() takes an int
- Remove an unused include
Change-Id: I096319af5e191e28c3d39295fb1aafe9d69841e6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When the array type is QJniObject or a subclass, then we need to
explicitly release the local reference returned by GetObjectArrayElement
in the QJniArray::at implementation. Do this by constructing the
QJniObject via fromLocalRef, which does exactly that.
Amends 80d4d55e25.
Add a test case that stresses the local reference pool, and fix the old
test case (which operates on a QJniArray<jobject>) to also release the
local references.
Change-Id: Ie293b1db9f1b6825376bbf12338b22dfc3f8c6e9
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
... adding a bit of test coverage of keysToValue().
This is not intended as a reproducer for QTBUG-118240, because that
is concerned with inputs valueToKeys() cannot produce.
Task-number: QTBUG-118240
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I5d772be4231717cdbb5d033b1f11ae31e4c57c0b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Almost all operations on a QJniObject require a QJniEnvironment,
including the construction and destruction of a QJniObject. Instead of
instantiating a temporary QJniEnvironment object in each call, store the
one from the constructor in the private, and reuse it.
Pass the stored environment through to other functions needing it, and
add a checkAndClearExceptions() wrapper.
Static class members still need their own QJniEnvironment, but we can
reuse the one we have to get both jclass and jmethodID rather than
creating new QJniEnvironments in several wrappers.
As a drive-by, clean up nullptr usage in the test that failed when
shortcutting isSameObject for the trivial cases.
Change-Id: Ibadbd2be8a0ec9ab62daf285608ee7fe0a3c8852
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Our signature mapping treats both e.g. bool and jboolean as "Z", and it
is allowed to pass a bool variable as an argument to a function expecting
a jboolean. Except for fields and callMethod return values, where we only
allowed the JNI primitive types.
Fix this by comparing the signatures and size of the type we have with
the JNI types that there are explicit functions for. Cast from and to
the JNI type in both directions to address narrowing (e.g. jboolean is an
unsigned char and converting to bool would be narrowing, even though
both are 8bit types).
This way we can get boolean fields using getField<bool>, and int fields
using getField<int> etc.
Change-Id: I2f1ba855ee01423e79ba999dfb9d86f4b98b1402
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Implements an iterator API and other standard member access functions
for sequential containers so that we can use ranged-for over an object
that is a jarray. Provides read-only access to individual elements
(which is mostly relevant for arrays of objects), or the entire data()
as a contiguous memory block (which is useful for arrays of primitive
types).
QJniObject call functions can return QJniArray<T> when the return type
is either explicitly QJniArray<T> or T[], or their Qt equivalent (e.g.
a jbyteArray can be taken or returned as a QByteArray). If the return
type is a jarray type, then a QJniObject is returned as before.
Arrays can be created from a Qt container through a constructor or the
generic fromData named constructor in the QJniArrayBase class, which
implements the generic logic.
Not documented as public API yet.
Added a compile-time test to verify that types are mapped correctly.
The function test coverage is added to the QJniObject auto-test, as
that already provides the Java test class with functions taking and
returning arrays of different types.
Change-Id: I0750fc4f4cce7314df3b10e122eafbcfd68297b6
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This changes takes Qt for Android Java code away from the Delegate
classes that uses heavily Java reflection to invoke Activity/Service
calls and overrides. So instead of that, now, we have a QtActivityBase
and a QtServiceBase classes which handle the override logic needed for
Qt directly without reflection.
These Base classes extend Android's Activity and Service directly, and
are inside the internal Qt android package (under Qt6Android.jar).
For example, to handle onConfigurationChanged, instead of the current
way where we need this in QtActivityDelegate:
public void onConfigurationChanged(Configuration configuration)
{
try {
m_super_onConfigurationChanged.invoke(m_activity, configuration);
} catch (Exception e) {
e.printStackTrace();
}
handleUiModeChange(configuration.uiMode &
Configuration.UI_MODE_NIGHT_MASK);
}
And then this in QtActivity:
@Override
public void onConfigurationChanged(Configuration newConfig)
{
if (!QtLoader.invokeDelegate(newConfig).invoked)
super.onConfigurationChanged(newConfig);
}
public void super_onConfigurationChanged(Configuration newConfig)
{
super.onConfigurationChanged(newConfig);
}
And having to keep it's Method handles around and then use Java
reflection
to call the override behavior done by Qt and the superclass methods.
instead of that, we can do it now in QtActivityBase like:
@Override
public void onConfigurationChanged(Configuration newConfig)
{
super.onConfigurationChanged(newConfig);
handleUiModeChange(newConfig.uiMode &
Configuration.UI_MODE_NIGHT_MASK);
}
Then, we would still have our user facing QtActivity class which extends
QtActivityBase and benefit from the same implementation of Qt logic done
in the base class.
An additional benefit to this approach is that now QtActivity will be
very lightweight and doesn't need to have all the boilerplate code as
before.
[ChangeLog][Android] Simplify Qt for Android public bindings
(QActivity, QtService and QtApplication) by implementing base
classes which use the delegate implementions directly and avoid
reflection.
Task-number: QTBUG-115014
Task-number: QTBUG-114593
Change-Id: Ie1eca74f989627be4468786a27e30b16209fc521
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
qnativesocketengine_win.cpp: don't check if timeout is < 0, because
remainingTimeAsDuration() doesn't return negative values.
All the changes done in one go, not function by function, as that causes
the least churn. You can think of them as a couple of very similar
changes repeated various times.
Drive-by change: replace `forever {` with `for (;;)`
Task-number: QTBUG-113518
Change-Id: Ie9f20031bf0d4ff19e5b2da5034822ba61f9cbc3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Construction from nullptr wasn't, before, because it was using the
QPointer(T*) constructor, which cannot be constexpr. Add a constexpr
QPointer(std::nullptr_t) constructor to enable this use-case.
This requires to mark the (T*) constructor as Q_WEAK_OVERLOAD,
otherwise legacy construction from a literal 0 would be ambiguous.
No documentation changes needed, as the set of valid expressions
(apart from constinit'ing) has not changed. Mention the nullptr ctor,
though, without \since.
Add a test to confirm that contruction from derived still works.
Change-Id: If9d5281f6eca0c408a69f03fecba64a70a0c9cf0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Ignore expected warning messages when looking up classes, methods, or
field that don't exist. Make the test implicitly fail for any other
warning messages.
Change-Id: I79ec799102b1ab9424aa39c5255413931b8ad152
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Construction from nullptr isn't, because it's using the QPointer(T*)
constructor, which cannot be constexpr.
Pick-to: 6.6 6.5
Change-Id: I19129a0fca5873e83d20351a909a7994399bfcce
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The jbyte type is a signed char, which also promotes to int in variadic
argument functions.
Extend the test case to make sure that we don't get any warnings for
the most relevant parameter types.
Change-Id: I7811e1eebdbc989ab5989eb1a2c502acd0540bc7
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Now that QtJniTypes::Objects are no longer primitive types that are the
same as a jobject, using those types in registered native functions
breaks. JNI will call those function with a jobject on the function
pointer, and lacking any type safety, the call to the registered
function will proceed with a wrong type of object on the stack.
To fix that, register the native function via a proxy that is a variadic
argument function, and unpack the variadic arguments into a list of
typed arguments, using the types we know the user-code function wants.
Then call the function with a tuple of those types using std::apply,
which gives us type safety and implicit conversion for free.
Add a test that exercises this.
Change-Id: I9f980e55d3d13f8fc16c410dc0d17dbdc200cb47
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Instead of having a type that doesn't behave like a QJniObject, which
includes not holding a proper reference on the Java object, make the
QtJniTypes::Object type a QJniObject subclass that can be specialized
via CRTP to provide type-specific constructor and static functions.
QJniObject doesn't have a virtual destructor, but we subclass it only to
add a typed interface, without adding any additional data members.
Add versions of the static functions from QJniObjects to the
QtJniTypes::Object so that they can be called without explicitly
specifying the type or class name. This includes a constructor and named
constructors.
Constructing such objects means constructing a Java object of the class
the object type represents, as per the Q_DECLARE_JNI_CLASS declaration.
This is not without ambiguity, as constructing a type with a jobject
parameter can mean that a type wrapping an existing jobject should be
created, or that a Java object should be created with the provided
jobject as the parameter to the constructor (e.g. a copy constructor).
This ambiguity is for now inevitable; we need to be able to implicitly
convert jobject to such types. However, named constructors are provided
so that client code can avoid the ambiguity.
To prevent unnecessary default constructed QJniObjects that are then
replaced immediately with a properly constructed object, add a protected
QJniObject constructor that creates an uninitialized object (e.g. with
the d-pointer being nullptr), which we can then assign the constructed
jobject to using the available assignment operator. Add the special
copy and move constructor and assignment operators as explicit members
for clarity, even though the can all be defaulted.
Such QJniObject subclasses can then be transparently passed as arguments
into JNI call functions that expect a jobject representation, with the
QtJniTypes::Traits specialization from the type declaration providing the
correct signature.
QJniObject's API includes a lot of legacy overloads: with variadic
arguments, a explicit signature string, and jclass/jmethodID parameters
that are completely unused within Qt itself. In addition the explicit
"Object" member functions to explicitly call the version that returns a
jobject (and then a QJniObject). All this call-side complexity is taken
care of by the compile-time signature generation, implicit class type,
and template argument deduction. Overloads taking a jclass or jmethod
are not used anywhere in Qt, which is perhaps an indicator that they,
while nice to have, are too hard to use even for ourselves.
For the modern QtJniTypes class instantiations, remove all the overhead
and reduce the API to the small set of functions that are used all over
the place, and that don't require an explicit signature, or class/method
lookup.
This is a source incompatible change, as now QJniTypes::Object is no
longer a primitive type, and no longer binary equivalent to jobject.
However, this is acceptable as the API has so far been undocumented,
and is only used internally in Qt (and changes to adapt are largely
already merged).
Change-Id: I6d14c09c8165652095f30511f04dc17217245bf5
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
If we construct the QJniObject from a jobject, then we know the jclass,
but not the class's name. If className is called while the stored name
is empty, get the name of the jclass and updated the stored value.
Change-Id: Ic3332a6da2dac1eb6842f90da1b9264398a43155
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
currentCompatProperty should point to the compat property that's
currently being evaluated. As soon as we start evaluating a new compat
property, it's invalid by definition. Temporarily disable it then.
Pick-to: 6.6 6.5 6.2
Fixes: QTBUG-109465
Change-Id: I7baba9350ebf488370a63a71f0f8dbd7516bf578
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Fail the test when an unexpected warning message about a field, class,
or method not being found is generated from a JNI exception. Fix the
failure when trying to look-up a boolean field that is no longer
available, and ignore the one expected message from looking up an
unavailable class explicitly.
Change-Id: Ic5e4c003c64272f06a6d4da028e232abba75c4e4
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Support this both for parameters and return types, in all template
functions for calling methods or accessing fields.
To manage the life-time of the temporary objects, create a local stack
frame in the JVM around the calling function. Popping that implicilty
releases all local refernces, so that we don't have to worry about
doing so explicilty. Adding a local reference to the temporary jstring
objects is then enough for the object to live as long as it's needed.
The LocalFrame RAII-like type needs a QJniEnvironment to push and pop
the frame in the JVM, so we don't need a local QJniEnvironment anymore.
Reduce code duplication a bit as a drive-by, and add test coverage.
Change-Id: I801a1b006eea5af02f57d8bb7cca089508dadd1d
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Add compile-time testing to make sure that we can declare a JNI
class String that maps to java/lang/String.
Change-Id: I2b68b2b46112e56b279f3fcddc3d71847a005924
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
d026fad3d9 added converting constructors
for QPointer. This however made converting _assignments_ ambiguous,
introducing a regression for users coming from Qt < 6.6.
This code:
QPointer<Base> base;
QPointer<Derived> derived;
base = derived;
used to convert `derived` to `Derived *` (using the implicit conversion
operator from `QPointer<Derived>` to `Derived *`), and then the
assignment operator for `QPointer<Base>` that took a `Base *`.
The introduction of the conversion constructor in 6.6 makes it possible
to convert `QPointer<Derived>` to `QPointer<Base>`, and then fall back
to the compiler-generated assignment operator for `QPointer<Base>`.
The result is that the code above is now ambiguous and stops compiling.
Fix this by adding a converting assignment operator for QPointer.
I'm only adding the const-lvalue overload because the implementation
requires going through the private QWeakPointer::assign helper. We
cannot copy-assign or move-assign the inner QWeakPointer, as those
assignments require lock()ing the QWeakPointer and that's not possible
on a QObject-tracking QWeakPointer (but cf. QTBUG-117483).
Assigning from a rvalue QPointer would mean calling assign() on
the internal QWeakPointer _and_ clear the incoming QPointer,
and that's strictly worse than the lvalue overload (where we just call
assign()).
Change-Id: I33fb2a22b3d5110284d78e3d7c6cc79a5b73b67b
Pick-to: 6.6 6.6.0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Android APIs use integer constants like enum values, so they are mapped
to one of the integeral types (jint, jshort, jlong etc) on the C++ side.
Enable C++ code to declare an equivalent enum (scoped or unscoped), and
to use that enum as a type in JNI calls by treating it as the underlying
type in the signature() generator.
Add a helper type trait that maps enums to their underlying type and
other integral types to themselves (we can't use std::underlying_type_t
on a non-enum type). Add tests.
Note: Java Enums are special classes with fields; this change does not
add any special support for those.
Change-Id: Iec430a1553152dcf7a24209aaebbeceb1c6e38a8
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Equivalent to get/setStaticField.
Add a test, and tighten up the surrounding test code a bit.
Change-Id: Ic0993c5d6223f4de271cb01baf727459b5167f94
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Template functions don't permit partial specialization, e.g. we cannot
specialize typeSignature() to return an array signature for any
std::vector or QList type. We need to do that for better array support,
so move those functions as static members into a template class, which
then can be specialized.
Since submodules are both calling and specializing typeSignature and
className as template functions, keep and use those until the porting is
complete.
Change-Id: I74ec957fc41f78046cd9d0f803d8cc9d1e56672b
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
The type lives in the QtJniTypes namespace, which is where types end up
that are declared through the Q_DECLARE_JNI_CLASS/TYPE macros. Having a
String type in that namespace prevents us from declaring the Java String
class as a QtJniTypes type, which is silly.
Perhaps this type becomes obsolete at some point with std::string being
a constexpr type in C++23, but until then we need it. It has no ABI, so
renaming it us safe.
Until submodules are ported, leave a compatibility alias String type,
which also prevents us from declaring a String JNI class in tests until
the alias is removed in a later commit.
Change-Id: I489a40a9b9e94e6495cf54548238438e9220d5c1
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
The QVariant(QMetaType) constructor is a major anti-pattern: unlike
*every* other QVariant's constructor, it doesn't build a QVariant
holding the QMetaType object, but a QVariant of the specified type.
Introduce a named constructor for this use case instead.
In principle, this should lead to a deprecation of the QMetaType
constructor... except that it's used everywhere, so I can't do it at
this time.
Drive-by, improve the documentation of the QVariant(QMetaType)
constructor (since it's basically c&p for the new fromMetaType
function).
[ChangeLog][QtCore][QVariant] Added the QVariant::fromMetaType named
constructor, that builds a QVariant of a given QMetaType.
Change-Id: I4a499526bd0fe98eed0c1a3e91bcfc21efa9e352
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
That we have two macros to declare a C++ type to represent a Java class
is confusing. The TYPE macro as of now allows us to declare array types,
but with QJniArray we won't need that anymore, and can just use Class[]
as the type instead. Changing that will be a follow-up commit; for now,
get rid of TYPE-usages to declare regular classes.
Change-Id: Iea0a9548772ca701148442412cf6ad567583213f
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The bindable property tests were not using the QTestPrivate helpers, so
add a new test which uses them.
The new tests revealed a binding loop for the interval property.
Fix it in a usual way by explicitly removing the binding and using
{set}ValueBypassingBindings() in the setter.
Task-number: QTBUG-116346
Pick-to: 6.6 6.5
Change-Id: If94f57938da449a68e3527aead5ebd55ba410adb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The 6.5 versions of the overload not taking a context/receiver object
were constrained by requiring a functor to be free function or lambda.
207aae5560 removed that constraint, which
might be source incomaptible if wrapper functions in user code forward
the constraint using Expression SFINAE. Those wrappers would no longer
be removed from the overload set based on the same criteria as the
function they wrap.
We can't constrain the new functions based on the same predicate as
before, as after the simplification we have only one overload with, and
one without context object. But we can still remove overloads for
incompatible functors.
Add the respective scenario to the QPermission test as a compile-time
test.
Found during 6.6 header review.
Pick-to: 6.6
Change-Id: Id21391b4a6b78a29de2f8fa04374f4262e5fafa7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
...to set m_o to nullptr and prevent an existing QSignalBlocker from
touching the QObject, which it was created for.
Add documentation and implement an autotest.
Change-Id: Ic18e80af5a57df1928f9d36aa0ab7ad79b6525fd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QWidget already handles this, but it might be useful for non-Widget
object hierarchies as well, such as in Qt Quick.
The flag is opt in, and as QWidget already handles these events by
itself (without checking any flags), we assert that we don't end up
in this code path, instead of enabling it for QWidget. The latter
would mean refactoring the QWidget code, with possible regressions.
Docs and header comments have been updated to reflect that this
event is not widget specific. (This is an issue with other events
as well, that are documented to say "widget", since they came
from a time when there was only QWidget, but nowadays apply to
e.g. QWindow as well. That's something for another fix though).
Change-Id: Ib71962131d6011c17dcce8c01bd8adcdaa58d798
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Due to the pre-existing overload of invokeMethod that accepts a void-pointer there is
concern that the new overloads would not be preferred.
Here we add a test for this to verify all supported platforms work.
Change-Id: Ie5ac7bf16643599006ac57e0145feb6aace3fa87
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This was missing for a while, and there is nothing fundamentally
missing for it to work.
With the more recent work around slot objects and invokeMethod in
general, it is a good time to add support for this.
In this patch, when connecting to a functor, it automatically deduces
the overload to call based on the arguments passed to invokeMethod.
Sharing code with QObject::connect could be done, but they have a
key difference that makes it harder:
With signal emissions we throw away trailing arguments that are not
used: i.e. `signal(int, int)` can be connected to `slot(int)` or
`slot()`. With invokeMethod that's not a thing. So we will need a way
to toggle that behavior during resolution.
[ChangeLog][QtCore][QMetaObject] Added support for passing parameters
to the overload of QMetaObject::invokeMethod that takes a functor. These
new overloads must have the return-value passed through qReturnArg().
Change-Id: If4fcbb75515b19e72fab80115c109efa37e6626e
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The was introduced with the rewrite of QMetaObject::invokeMethod() in
commit 0f76e55bc4, because we have an
optimization for zero timers to avoid creating a temporary
QSingleShotTimer object. The old implementation did attempt to normalize
the target slot name, but did so because it looked metamethods up using
QMetaObject::indexOfMethod:
int idx = meta->indexOfMethod(sig.constData());
if (idx < 0) {
QByteArray norm =
QMetaObject::normalizedSignature(sig.constData());
idx = meta->indexOfMethod(norm.constData());
}
The new implementation does not use this method so it didn't need to
attempt to normalize.
I am fixing this only in QTimer and not in QMetaObject::invokeMethodImpl
(even though it is trivial to do so) because I don't believe spaces in a
pure string to invokeMethod were ever expected to work:
QMetaObject::invokeMethod(obj, "slotName ", Qt::QueuedConnection);
The Q_ARG and Q_RETURN_ARG (for code not recompiled) still does
normalization inside QMetaType::fromName().
Fixes: QTBUG-116060
Pick-to: 6.5 6.6
Change-Id: I964c2b1e6b834feb9710fffd177cac60c83ef413
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Unix dispatcher is not used and - as such - redundant on WASM.
Change-Id: Ia8789ef783b06ce9cfba2ce9d67159db2355b594
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Observers should only be registered when _reading_ the property.
Otherwise we get binding loops.
Pick-to: 6.6 6.5
Change-Id: I974f6ea444fa7a5d333ed79eea6f34e3d757d169
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The loop was iterating over a temporary container, so it couldn't have
changed it. Store the container in a const auto variable and use
ranged-for.
In files where Q_FOREACH isn't used any more, remove
"#undef QT_NO_FOREACH".
Task-number: QTBUG-115839
Change-Id: I402df5fa48f4287f3cc989ddae1524da43999049
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The density of Q_FOREACH uses in this and some other modules is still
extremely high, too high for anyone to tackle in a short amount of
time. Even if they're not concentrated in just a few TUs, we need to
make progress on a global QT_NO_FOREACH default, so grab the nettle
and stick to our strategy:
Mark the whole of Qt with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too).
In tst_qglobal.cpp and tst_qcollections.cpp change the comment on the
#undef QT_NO_FOREACH to indicate that these actually test the macro.
Task-number: QTBUG-115839
Change-Id: Iecc444eb7d43d7e4d037f6e155abe0e14a00a5d6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It has always returned dash-joined forms of the locale names, and
callers who need an underscore-joined form have been obliged to
replace('-', '_') before using them. Given that everything it adds to
the list comes from QLocaleId methods that accept a separator, it's
trivial to let it offer the same choice to its callers and save them
this hassle.
Amended code in QTranslater and QMimeType to save them that hassle.
[ChangeLog][CoreLib][QLocale] QLocale::uiLanguages() now lets the
caller choose what separator to use between the tags that make up each
locale-identifier in the list returned.
Change-Id: I91fcd0b988d9a64e0e9ad9e851f6cb8c1be8ae50
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Everyone must have this by now. This test was 1193 ms of CMake time.
Since this was a PUBLIC feature, I've left it around with a constant
condition.
Change-Id: Ifbf974a4d10745b099b1fffd177754538bbff245
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Commit ca54b741d6 used the internal
has_operator_equal (and commit 01d94760d8
copied that for has_operator_less_than) instead of using the recursive
expander that was being used here. That assumed that the contained type
in std::optional would always be the last final check, which is an
incorrect assumption.
Fixes: QTBUG-115646
Pick-to: 6.6 6.5
Change-Id: Ifbf974a4d10745b099b1fffd177702934bec27ff
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
There is no QT_CONFIG_thread.
Thanks to Alexey Edelev for spotting why I couldn't run the test.
Pick-to: 6.6 6.5
Change-Id: I11c99d9b1ff8fed67b118028b76fba8ee6db3c42
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The test was relying on the fact that, having written 1 byte to both
writeEnd1 and writeEnd2 (and ensured those bytes were written with
waitForBytesWritten()), both read ends would be activated by the next
event loop. It turns out that this was an unreliable assumption, because
the processing of that 1 byte on the second socket may not have happened
yet. So firm up by waiting that both read ends are readable before even
creating the QSocketNotifiers we will read on.
I'm not entirely sure what this test is attempting to test. Its
documentation says it's testing a QAbstractSocket condition, but the
read ends aren't QAbstractSocket (this test should have been in
tst_QAbstractSocket if so). It may be testing the condition that caused
that QAbstractSocket behavior, but that wouldn't be a good test.
Drive-by remove redundant flush()-after-waitForBytesWritten() calls.
Fixes: QTBUG-115154
Pick-to: 6.5 6.6
Change-Id: I61b74deaf2514644a24efffd17708f8071f707ed
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The test hasn't failed on Windows for a long time, but regularly fails
on macOS in CI, so replace the entry accordingly.
Task-number: QTBUG-115154
Pick-to: 6.6
Change-Id: Ib89d15cb9edafad5dd71f6e3f830d03aaeb16331
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Add the boilerplate standalone test prelude to each test, so that they
can be opened with an IDE without the qt-cmake-standalone-test script,
but directly with qt-cmake or cmake.
Boilerplate was added using the following scripts:
https://git.qt.io/alcroito/cmake_refactor
Manual adjustments were made where the code was inserted in the wrong
location.
Task-number: QTBUG-93020
Change-Id: I28b6d3815c5f43d2c33ea65764f6f3f8f129eaf3
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
`QVariant::convert` may lead to crash or produce garbage data when
attempting to convert a gadget between a pointer type and a value type,
for example from a variant holding a QLocale gadget to a QLocale*
pointer and vice versa. Similarly, `QVariant::view` may crash under the
same conditions.
The reason is that conversion is implemented through copy construction
assuming that both source and target types are either both pointers or
both values. If converting from pointer to value type, the result is
crash during destruction of the QVariant. If converting from value to
pointer type, the result is a QVariant holding a pointer to garbage
data (and possibly crash if pointer is dereferenced).
Similarly, if attempting to convert a pointer to a QObject derived type
to its value type, the system crashes, with a slightly different failure
mode. During `QVariant::convert`, a temporary `QVariant` of the target
type is created. Since objects that can not be copy constructed are
invalid for `QVariant`, the temporary is left empty without constructing
the target value. Then, when attempting to convert from a pointer type
to a value type, the temporary's destructor is incorrectly called on the
owned object. Since the owned object is never constructed, this leads to
a crash.
The proposed fix is to return false from `QMetaType::view`,
`QMetaType::canView`, `QMetaType::convert`, and `QMetaType::canConvert`
if the target type is of different 'pointedness' than the source type.
After this fix, converting and viewing gadgets and QObjects behaves the
same way as primitive types and core types, which already returned false
when converting between value type and pointer type.
Fixes: QTBUG-114797
Pick-to: 6.5 6.6
Change-Id: If5ad764a60f2f3c912070198073b28999d995f17
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Under some circumstances, MSVC seems to complain about SlotArgumentCount
being unused
qobject.h(210): warning C4189: 'SlotArgumentCount': local variable is
initialized but not referenced
note: see reference to function template instantiation
'QMetaObject::Connection QObject::connect<void(__cdecl QAction::* )(bool),
main::<lambda_1>>(const QAction *,Func1,
const QtPrivate::ContextTypeForFunctor<main::<lambda_1>,void>::ContextType *,
Func2 &&,Qt::ConnectionType)' being compiled
This is nonsense, as SlotArgumentCount is used in the next line, to
construct the list of signal arguments, but the workaround to declare
the variable as [[maybe_unused]] is trivial.
Add a connect statement to the test case that creates such a connection.
This does not produce any warning with or without the attribute (and if
it did, the build would fail for CI configuratinos setting -Werror).
Pick-to: 6.6
Fixes: QTBUG-114781
Change-Id: I4ee6f7d57c2836ef3dd9741d037d48181af2cdec
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This is in line with how QMetaType handles QMetaTypeInterface*. You can
retrieve a const pointer to it.
Pick-to: 6.6
Task-number: QTBUG-113690
Change-Id: Iaf3c10603dc6049a5553987c90006807867abc0d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QObjectPrivate::getPropertyAdaptorSlotObject called
connectionsForSignal.
Calling this function is only safe after it has been ensured beforehand that the vector has size > signalIndex. As getPropertyAdaptorSlotObject
is not supposed to modify the vector, it does not resize the vector and it could consequently end up with an out-of-bounds read.
To avoid that issue, we instead first check if the vector can
potentially contain an entry for the signal. If not, we simply return
nullptr, and avoid the call to connectionsForSignal.
The issue and its fix can be verified by running the modified
tst_qproperty test with ASAN enabled. The test is modified in the
following way:
- We first create a signal connection to a dummy slot. Otherwise,
connections.loadRelaxed() would return a nullptr, and the problematic
code would never be reached.
- We add enough signals to ensure that the fooChanged signal will
actually be out of reach (which means >= 8 signals, as the initial
capacity of the vector is 8)
Running the test without ASAN will most likely not result in a failure,
as then the out-of-bounds read will simply read garbage, and the most
likely result is that the cast below will fail.
Pick-to: 6.6 6.5
Change-Id: I18a3c4f52769c2b6491a685abb84f6fcfb44e4d8
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
If we have a rvalue reference to an unshared QVariant, we can avoid
potentially expensive copies, and use move semantics instead.
[ChangeLog][QtCore][QVariant] Added rvalue QVariant overloads of qvariant_cast<T>() and QVariant::value<T>().
[ChangeLog][Potentially Source-Incompatible Changes][QVariant] It is no
longer possible to take the address of a specialization of
qvariant_cast; consider using a lambda function instead.
Change-Id: Ifc74991eadcc31387b755c45484224a3200bb0ba
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QDeferredDeleteEvent has the loopLevel field, which is a sum of
scope and loop levels found at posting. In sendPostedEvents however,
it is impossible to only use this information to find delete events
posted before the outermost loop (which should be handled by any loop)
based solely on this information, as the scope level essentialy removes
the information on loop level.
Break the loopLevel in two, storing both loop and scope levels in
QDeferredDeleteEvent, so that we can check whether an event was posted
before the outermost event loop (for which we need to compare only the
loop level).
QDeferredDeleteEvent was also made private as it should - it is an
implementation detail that wasn't hidden properly.
Change-Id: I0a607a0bd3a2deb5024acad67f740dbf4338574c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Extract Method fromStdVariantImpl() to share the otherwise
more-or-less identical implementation between the two overloads.
Don't use a constrained template version of fromStdVariantImpl() as
fromStdVariant(), because the constraint would have to be very complex
to continue allowing subclasses of std::variant to be passed.
As a drive-by, mark the valueless_by_exception() path Q_UNLIKELY.
[ChangeLog][QtCore][QVariant] Added overload of fromStdVariant()
taking rvalue std::variant<>s.
Fixes: QTBUG-114134
Change-Id: Ia1c7ae93ab421e6689dc9f2d8d0c2295b23cbbf6
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When passing an rvalue-reference to QVariant, there is no reason to make
a copy if the type is moveable. Moreover, we know that the pointer which
we construct from the object passed to fromValue non-null. We make use
of both facts by parametrizing custom_construct on
non-nullness and availability of a move-ctor, and then dispatching to
the suitable template.
We need to keep the const T& overload, as otherwise code which
explicitly specializes fromValue and passes a const lvalue to it would
stop to compile.
[ChangeLog][QtCore][QVariant] Added fromValue() overload taking rvalues.
Change-Id: I44fb757d516ef364fe7967bc103b3f98278b4919
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
[ChangeLog][QtCore][QVariant] Implemented in-place construction for
QVariant. The constructor taking std::in_place_type<Type> constructs
an object of type Type directly inside QVariant's storage, without any
further copy or move operations. QVariant::emplace() does the same
when replacing the content of an existing QVariant and tries to reuse
previously-allocated memory.
Fixes: QTBUG-112187
Change-Id: I16614ad701fa3bb583976ed2001bb312f119a51f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Ulf Hermann
Thiago Macieira
Ivan Solovev
Volker Hilsheimer
Lucie Gérard
Ahmad Samir
Jarek Kobus
Fabian Kosmale
Christian Ehrlicher
Po-Hao Su
Edward Welbourne
Rym Bouabid
Marc Mutz
Assam Boudjelthia
Giuseppe D'Angelo
Axel Spoerl
Tor Arne Vestbø
Mårten Nordheim
Mikolaj Boc
Edward Welbourne
Alexandru Croitor
Jøger Hansegård