summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/kernel
Commit message (Collapse)AuthorAgeFilesLines
...
* Blacklist tst_QGuiEventLoop::processEvents on QNXVolker Hilsheimer2023-11-222-0/+16
| | | | | | | | | | | | | 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>
* QObject: allow calling findChild() without a nameRym Bouabid2023-11-221-0/+19
| | | | | | | | | | | 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>
* tst_QTimer: refactor CMake codeAhmad Samir2023-11-222-19/+14
| | | | | | | | | 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>
* QObject: port findChild/ren() to QAnyStringViewRym Bouabid2023-11-221-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* tst_qtimer: remove extra `;` after Q_DISABLE_COPYAhmad Samir2023-11-191-1/+1
| | | | | | | Fixes warning from sanitize-commit. Change-Id: Ie52de4e34fce903d898619bc8e2338a15b7b7e68 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* JNI: Add convenience overloads for registerNativeMethodsVolker Hilsheimer2023-11-131-8/+7
| | | | | | | | | | | | | | | | 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>
* JNI: allow QString as a parameter to native methodsVolker Hilsheimer2023-11-073-27/+74
| | | | | | | | | | | | | | 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>
* Extend QTestPrivate property tests - actual implementation [2/2]Ivan Solovev2023-11-011-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 f791570b86ce4a0da45bb6e617701a48ee8189b7 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>
* JNI: don't implement a signature for 'long' C++ typeVolker Hilsheimer2023-11-011-2/+2
| | | | | | | | | | | | 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>
* QMetaEnum: refactor keysToValueAhmad Samir2023-10-311-4/+26
| | | | | | | | | | | - 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>
* qcore_unix: port qt_safe_poll to QDeadlineTimerAhmad Samir2023-10-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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>
* JNI: Fix reference leak in QJniArrayVolker Hilsheimer2023-10-231-3/+24
| | | | | | | | | | | | | | | 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 80d4d55e250af1d643805bde3821987112cf09c1. 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>
* tst_QMetaEnum: add round-trip testing to valueToKeys()Marc Mutz2023-10-191-0/+3
| | | | | | | | | | | | ... 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>
* JNI: Reduce amount of temporary QJniEnvironment instantiationsVolker Hilsheimer2023-10-181-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* JNI: treat equivalent C++ types as the same JNI types as wellVolker Hilsheimer2023-10-181-0/+10
| | | | | | | | | | | | | | | | | | | | 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>
* JNI: add QJniArray class for easier working with arraysVolker Hilsheimer2023-10-166-2/+359
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Android: Simplify Qt for Android hierarchy, less Java reflection!Assam Boudjelthia2023-10-122-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QAbstractSocketEngine: port to QDeadlineTimerAhmad Samir2023-10-071-2/+2
| | | | | | | | | | | | | | | | 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>
* QPointer: ensure construction from nullptr is constinit'ableMarc Mutz2023-10-051-0/+7
| | | | | | | | | | | | | | | | | | 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>
* JNI: Silence and harden QJniEnvironment testVolker Hilsheimer2023-10-051-0/+17
| | | | | | | | | | 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>
* tst_QPointer: ensure default-constructed objects are constinit'ableMarc Mutz2023-10-041-0/+4
| | | | | | | | | 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>
* tst_QPointer: add checks for CTADMarc Mutz2023-10-041-0/+42
| | | | | | | | No pathological findings :) Pick-to: 6.6 6.5 6.2 Change-Id: Ifbbca223a5e612e7abb67c0364d4354a9d8174e3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* JNI: Add promotion for signed char and extend test caseVolker Hilsheimer2023-09-292-11/+132
| | | | | | | | | | | | 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>
* JNI: Fix native functions that take a declared QtJniTypes classVolker Hilsheimer2023-09-273-6/+63
| | | | | | | | | | | | | | | | | | | 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>
* JNI: Make declared QtJniTypes classes proper QJniObjectsVolker Hilsheimer2023-09-272-5/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* JNI: Implement QJniObject::className to get the name of the class if not setVolker Hilsheimer2023-09-271-0/+17
| | | | | | | | | 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>
* QProperty: Steal currentCompatProperty while evaluating a different oneUlf Hermann2023-09-271-0/+105
| | | | | | | | | | | | | 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>
* JNI: harden QJniObject test caseVolker Hilsheimer2023-09-261-1/+11
| | | | | | | | | | | | 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>
* JNI: Implicitly convert QString to jstring in API callsVolker Hilsheimer2023-09-261-4/+33
| | | | | | | | | | | | | | | | | | 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>
* JNI: remove compatibility alias for CTStringVolker Hilsheimer2023-09-261-0/+6
| | | | | | | | | | 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>
* QPointer: also provide a converting assignment operatorGiuseppe D'Angelo2023-09-231-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | d026fad3d962eed0119351cd37f34490e09153fd 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>
* JNI: treat enums as their underlying typesVolker Hilsheimer2023-09-232-4/+60
| | | | | | | | | | | | | | | | | | | | 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>
* QJniObject: add callStaticMethod overload that takes class as typeVolker Hilsheimer2023-09-221-11/+13
| | | | | | | | | | | 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>
* JNI: move signature/className template functions into a template classVolker Hilsheimer2023-09-221-15/+25
| | | | | | | | | | | | | | | | | 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>
* JNI: rename our compile-time String type to CTStringVolker Hilsheimer2023-09-221-20/+18
| | | | | | | | | | | | | | | | | | | | 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>
* QVariant: add fromMetaTypeGiuseppe D'Angelo2023-09-201-0/+18
| | | | | | | | | | | | | | | | | | | | | | 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>
* JNI: replace TYPE declarations with CLASS declarationsVolker Hilsheimer2023-09-201-1/+1
| | | | | | | | | | | | | 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>
* tst_qeventdispatcher: port to QDeadlineTimerAhmad Samir2023-09-041-8/+9
| | | | | | | Easier logic for these use-cases. Change-Id: I97a18c45d9bd8cfcfee5d379d271366276d5a435 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QTimer: extend property tests and fix binding loopIvan Solovev2023-09-032-0/+40
| | | | | | | | | | | | | | | 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>
* Constrain QCoreApplication::requestPermission to compatible functorsVolker Hilsheimer2023-09-011-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | 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. 207aae5560aa2865ec55ddb9ecbb50048060c0c0 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>
* Implement QSignalBlocker::dismiss()Axel Spoerl2023-08-311-0/+11
| | | | | | | | | ...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>
* Allow QObjects to opt in to receiving ParentAboutToChange/ParentChangeTor Arne Vestbø2023-08-301-0/+73
| | | | | | | | | | | | | | | | | | | 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>
* invokeMethod: Try invoking functor and member function accepting pointer, ↵Mårten Nordheim2023-08-241-0/+20
| | | | | | | | | | | returning void 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>
* invokeMethod: enable passing parameters to overload taking functorsMårten Nordheim2023-08-241-0/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QTimer: fix regression on singleShot-invoking non-mormalized SLOT()sThiago Macieira2023-08-221-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The was introduced with the rewrite of QMetaObject::invokeMethod() in commit 0f76e55bc440a70f5d9530a192c9ce6334a8f06, 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>
* Remove the unix dispatcher from WASM buildsMikolaj Boc2023-08-221-2/+4
| | | | | | | Unix dispatcher is not used and - as such - redundant on WASM. Change-Id: Ia8789ef783b06ce9cfba2ce9d67159db2355b594 Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
* QObject: Do not register an observer when writing objectName propertyUlf Hermann2023-08-211-0/+10
| | | | | | | | | 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>
* tests/auto/*: port Q_FOREACH to ranged-forAhmad Samir2023-08-192-6/+4
| | | | | | | | | | | | | 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>
* Mark all of Qt as free of Q_FOREACH, except where it isn'tMarc Mutz2023-08-192-0/+4
| | | | | | | | | | | | | | | | | | | | | | 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>
* Give QLocale::uiLanguages() a separator parameterEdward Welbourne2023-08-161-1/+1
| | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-24 11:13:29 +0000