If users have
CONFIG += qt
in their .pro file then the project won't link if the platform requires
the entrypoint module. This is because qt.prf is loaded before
entrypoint.prf in this situation.
Make the CONFIG values 'entrypoint' and 'qt' independent of their order
by embedding the content of entrypoint.prf into qt.prf.
Pick-to: 6.5 6.6
Fixes: QTBUG-117674
Change-Id: I72a3c9be023a73d70454533262544a4211cb6974
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
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>
This reverts commit 5e76a9569e.
The change's stated goal was to make shortcuts "stable",
i.e. work the same, regardless of which keyboard layout
the user has selected.
In doing so, it changed the semantics of shortcut handling
to depend on the order of the keyboard layouts reflected
by XKB, picking the first Latin layout in the list, instead
of prioritizing the currently selected/active keyboard
layout.
This change in semantics is a major behavior change, and
breaks common and valid setups such as having [en,fr] or
[en,de] layouts.
For example, the French layout uses an AZERTY layout,
where the Q and A keys are switched compared to QWERTY.
With the change in place, pressing the physical A key
on a French keyboard, with Control pressed, no longer
selects all text, but instead quits the application,
as the shortcut is interpreted based on the English
layout, which just happens to be first in the list.
Similar issues exist for German layouts, which use
QWERTZ, or more complex layouts such as the Neo layout.
The semantics of prioritizing the order of declared
layouts instead of the active one is inconsistent with
both macOS and Windows, as well as other toolkits on
Linux, including GTK and earlier versions of Qt.
It's also not discoverable by the user that the order
now matters. For example, there is no UX in the Gnome
setting that tells the user to ensure the order matches
their expectations for shortcut handling. And if there
was, this would only apply to Qt apps built with 6.6.0,
creating inconsistent behavior for users.
Worse, the X server is limited to four concurrent keyboard
layouts (groups), so if the user adds more layouts than
that, Gnome will replace the X server's view of layouts
only when switching to a layout beyond the first four.
And in that case, the X server's view of the layouts is
actually starting with the fifth layout declared in the
Gnome preferences. The logic in the reverted patch does
not take this into account, making it confusing for the
user which layout actually takes precedence.
Note that reverting this change does not affect our
fallback logic for layouts that do not produce Latin
symbols for the given key press, such as Greek or Russian.
Those layouts will continue to fall back to a Latin
layout for their QKeyEvent::key().
[ChangeLog][QtGui][X11/Wayland] A change in 6.6.0 that
resulted in keyboard shortcuts not respecting the user's
active layout has been reverted.
Pick-to: 6.6
Task-number: QTBUG-108761
Change-Id: Iec2897cd1541c0c125cc5b1078d0beec12b501c0
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
`QCoreApplicationPrivate::self` is set to nullptr in `~QCoreApplication`
without any synchronization. So it is not safe to access it from
instances of `QDaemonThread` that may outlive the application instance,
but are using the Qt event system. This patch moves some usages of
`self` behind other checks, so that the QtDBus management thread can
continue workoing without race conditions detected by Thread Sanitizer
while running tst_qdbusconnection.
Change-Id: Iece65e4126a59e3a1a41dfb6a99c84527b8d389c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When changing the selected index in a combo box,
also update the current index in the item view's
selection model right away, and don't delay this
until when the combobox popup gets shown in
QComboBox::showPopup.
This is needed to make sure that the selection
is properly exposed to the accessibility layer.
On the accessibility layer, QAccessibleComboBox,
the a11y implementation for the combobox, exposes
the entries in its list child
(s. QAccessibleComboBox::child) and Orca queries
the selected item when the combobox gets focus,
which didn't return the proper results earlier,
resulting in no or the wrong entry getting
announced.
Extend the existing combobox a11y tests
accordingly.
Pick-to: 6.6 6.5
Fixes: QTBUG-117644
Change-Id: Ia26de5eafd229f7686745a2fbe03fc1eb6a713f8
Reviewed-by: Liang Qi <liang.qi@qt.io>
Call QEvent::accept() when a key event has been acted on.
This prevents redundant event delivery and consumption.
Task-number: QTBUG-117644
Pick-to: 6.6 6.5
Change-Id: I069c61c14890577683894f165fd2585ba05c45ff
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Liang Qi <liang.qi@qt.io>
A helper method encasuplating the asserts related to index into the
container and length, modelled after the QVLA::verify().
`pos <= size` is OK because if pos == size, the e.g. sliced()'ed
container is just going to be empty.
Normalize how verify() is used, the first arg is an index and the second
a length.
This method is constexpr even in QString/QByteArray merely for
consistency with similar methods in other string classes (this
necessitates using `d.size` in verify() in QString/QBA because size()
isn't constexpr).
Change-Id: I90e3c56d76c802259297a06d11d46ee342a1daf2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Implement the missing overload to handle UTF-8 specific data types,
including char8_t (C++20), char, uchar and signed char.
Introduce the helper function 'assign_helper_char8' which handles the
non-contiguous_iterator case. The contiguous_iterator case is already
handled by the QAnyStringView overload.
Include 'qstringconverter.h' at the end of the file, since it can't
be included at the top due to diamond dependency conflicts.
QStringDecoder is an implementation detail we don't want users to
depend on when using assign(it, it). It would be unnatural to not
be able to use a function just because we didn't include an
apparently unrelated header.
[ChangeLog][QtCore][QString] Enabled assign() for UTF-8 data types.
Fixes: QTBUG-114208
Change-Id: Ia39bbb70ca105a6bbf1a131b2533f29a919ff66d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
For example when Ctrl+Home is sent by virtual keyboard on Wayland.
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I41f1d2a28c9091efa621d5826a3b9e3e0e481ceb
Reviewed-by: Liang Qi <liang.qi@qt.io>
Since https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8564 is
merged, the timestamp file for {target}_json_file.txt should be updated
for `Cross-Config` builds.
The actual error message before this commit when CMake 3.28 is used:
```
ninja: error: 'src/corelib/Core_autogen/timestamp', needed by 'src/corelib/meta_types/Core_json_file_list.txt', missing and no known rule to make it
```
Pick-to: 6.2 6.5 6.5.3 6.6 6.6.0
Change-Id: Ib544b18b67d2d4722f3801b1f46a0e0e18e59d48
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The setup of the input and output converters is fairly complex but was
made harder to read by nearly-duplicating its logic for input and for
output. Break out into a separate function to make clear what parts
differ between the two and what parts don't. In the process, allow the
search for a named converter to continue past a match that doesn't
support the needed direction, on the off chance of a name collision.
Make an error message more articulate in the process.
Pick-to: 6.6 6.5
Task-number: QTBUG-111228
Change-Id: I2a9de8b406c538098076f388fc8a1980b91fe16b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
I originally wrote dateNormalize() because I expected to need it more,
but it turns out to only be needed for two cases of getting the days
before and after a given one. So rename to adjacentDay(), pass the +1
or -1 step and simplify a little.
In the process, fix a mistake in the winding backwards across a year
boundary, where I'd incremented the year instead of decrementing it.
Change-Id: I1bb0a8323fec7c1caffa7f20879f08d3526ba7ea
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
CodeChecker tells me struct tm and even MkTimeResult are trivially
copyable, so std::move()ing them is fatuous.
Change-Id: Ic7328e588beabfd4a984b2b5e2ed17c065d00f01
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change the Qt version for future directions of
QCoreApplication::notify() to 7. The required changes were not
done in Qt 6 as planned. Add the code that is implementing those
changes for Qt 7.0.0.
This amends 4fe865ac7a.
[ChangeLog][Future direction notices] In Qt 7,
QCoreApplication::notify() will not be called for events being delivered
to objects outside the main thread. The reason for that is that the main
application object may begin destruction while those threads are still
delivering events, which is undefined behavior. Applications that
currently override notify() and use that function outside the main
thread are advised to find other solutions in the mean time.
Change-Id: I4dd2193092542474962cdcde4921f38b173f2f00
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This change can be described in the following 2 categories:
1. Support 3 ways to escape identifiers mentioned in SQLite Keywords
In SQLite Keywords (https://sqlite.org/lang_keywords.html), it shows
that there are 3 ways to escape identifiers, i.e., "", [], ``. So, I
have overridden "bool isIdentifierEscaped(const QString &,
IdentifierType)" to support it. In addition, there was a bug of
_q_escapeIdentifier. If there is a field name called length [cm],
which uses square brackets to show units, _q_escapeIdentifier will
not escape it to "length [cm]".
2. Identify identifiers correctly if identifiers have been escaped
There is a bug of QSQLiteDriver::record and
QSQLiteDriver::primaryIndex.
If we input escaped identifiers with separator, let's say
"databaseName"."tableName", both will change the input into
databaseName"."tableName, which is incorrect and causes
qGetTableInfo cannot get the right results. In addition, I overrode
stripDelimiters to strip "databaseName"."tableName" correctly.
There are still some assumptions for isIdentifierEscaped,
escapeIdentifier, and stripDelimiters, but I think this change it better
than what we have now.
1. For isIdentifierEscaped, if identifiers have a dot and the dot is a
separator, it is the users' responsibility to escape the pair of
schema and table name correctly. For example,
"aSchemaName"."aTableName", not "aSchemaName".a"TableName". That's
because we don't know whether the dot is just a dot of the name or a
separator.
2. For escapeIdentifier, if identifiers have a dot and the parts before
and after the dot are not escaped, escapeIdentifier will treat the
dot as part of the table name or field name. The same as the item
above, it is users' responsibility to do it right.
3. For stripDelimiters, the same as above, it is users' responsibility
to do escape if users want to use format schemaName.tableName or
tableName.fieldName.
Change-Id: I9d036a2a96180f8542436188f75a220a0fe58257
Reviewed-by: Po-Hao Su <supohaosu@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
qtypes.h defines qint128 and quint128 if __SIZEOF_128__ is defined.
VxWorks doesn't support 128bit ints (confirmed by the
WindRiver support team and by the fact that std::numeric_limits::is_specialized
returns false for those types), but clang defines that
symbol anyway.
-DQT_NO_INT128 is used to disable support for those types.
Task-number: QTBUG-115777
Change-Id: Iea024ad9e35734002ce516ebd8a7fa7f2352be62
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Amends 5743837a26, after which Qt
Positioning and Qt SCXML failed to build as some properties operate on
abstract classes.
Check whether we can instantiate the tested class before trying to do so,
otherwise return a default-constructed unique_ptr.
Pick-to: 6.6 6.5
Change-Id: Ida9d4375197a93438062b1e1473b4a2a22cc7054
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We want to test the traits even on nonsensical types.
Change-Id: I63ed022c9529d9de9d336157e6f025937321ca16
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Previous implementation of qt_safe_ioctl mentioned that vxworks defines
ioctl in a non-standard way.
As of VxWorks 23.03 ioctl is now properly defined so the comment and
check in the code are obsolete.
Task-number: QTBUG-115777
Change-Id: I0fdf614e45063b031e2c998339d6987ba69167ca
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The warning from the comment was probably caused by our noexcept
detection code. Now that we use std::is_nothrow_swappable, those
warnings should not longer happen.
Remove the warning suppression macros, and the #include that was
necessary for them.
Change-Id: Ib750cb1af4a8da3fb63b16d26ec51a9fb4a93ea1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
In some corner-cases the header files are passed by symlink path
if the source directory is symlink. Make sure that we resolve symlinks
when running headersclean check.
Fixes: QTBUG-117518
Pick-to: 6.5 6.6
Change-Id: Ifaffc9186e78fba86037cb50438021466903d210
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QtC is unable to find the deployment settigns if target uses custom
OUTPUT_NAME. There is no particular reason for using the target
OUTPUT_NAME property as the base name for android deployment settings.
[ChangeLog][General][Android] The target name is used as a base name of
android deployment settings, but not the OUTPUT_NAME property.
Pick-to: 6.2 6.5 6.6
Fixes: QTBUG-117509
Change-Id: I1ac3b0ad305dc55289bef39c6e946bcf684e772f
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
Move the shared code into a variadic template construct-function of
the private, which can do the rest.
Change-Id: I98a9a93b7c0452cc28769370e6a1499f1728a72d
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Functions that are not called by any of the inline code don't have to be
in the public header. Move them as static functions into the translation
unit. Remove some useless wrappers in the private, and move the code for
private and static functions together.
Some private helpers have to stay in the ABI as they used to be called
by at least one public inline function up to Qt 6.6. Remove them from
the API using QT_CORE_REMOVED_SINCE.
Change-Id: I7eb7b2ba994dfda9de11e2d090a70842dad17247
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
QtAndroidPrivate::findClass first tried the cache, then JNIEnv::FindClass.
Failing that, it tried QJniObject::loadClass which also checked the
cache before falling back to the ClassLoader.
Merge the implementations into QtAndroidPrivate::findClass. Loading a
class now always first tries the cache, then FindClass, then the
ClassLoader. Reduce the overhead from temporary QJniObject creations by
explicitly creating the class string, and avoid printing the exception
in case of failure twice by clearing the exception explicitly after the
first try.
Assert that the function receives a JNIEnv pointer, as any call without
is a programming error (and all call-sites in Qt pass in a valid pointer
anyway, so no need to test otherwise).
With both implementations merged we can centralize the binary encoding
of the class name strings to the single place where it's needed, which
is when calling the ClassLoader::loadClass method. FindClass takes a
fully qualified, slash-separated class name string, so in most cases we
never have to pay any overhead for re-encoding the class name string.
Change-Id: I5a3648763052cebdec69d7d77c503aebdebf5bee
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>
Testing for the binding loops requires a second instance of the
TestedClass. In general case, we cannot guarantee that the TestedClass
is default-constructible, so we introduce a new parameter - a function
that returns an std::unique_ptr holding the properly-constructed
instance of TestedClass. The default implementation simply creates
a unique_ptr using a default constructor, which is good enough for
most cases. The user needs to provide a custom function when
TestedClass has no default constructor (for now such usecase exists
at least in QtScxml and QtPositioning).
This patch introduces new signatures for the helper functions, but does
not actually provide new implementation.
This is an attempt to simplify the CI integration process.
The new arguments have default values, so the existing code will not
be affected.
The idea is that the merge process goes as follows:
* this patch gets merged into qtbase. It should not break leaf modules,
because the new parameters have default values -> existing tests are
unaffected.
* it unblocks all patches to the leaf modules that require the new
parameter for the test helper functions. These patches are also
supposed to fix all the problems with the binding loops.
* once these patches are merged, a follow-up patch to qtbase that
actually extends the test coverage can be merged. As it is supposed
that all problems in the leaf modules are already fixed, merging
this patch should not lead to new problems.
The actual implementation of the new tests is provided in a follow-up
patch.
Task-number: QTBUG-116345
Pick-to: 6.6 6.5
Change-Id: I0dd5c8c60de01aa960d63673b5d7de97950d9490
Reviewed-by: Ulf Hermann <ulf.hermann@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>
This partially reverts fcb548878b.
qnativesocketengine_unix.cpp:872:40: error: unknown type name
'sockaddr_dl'; did you mean 'sockaddr_in'?
Pick-to: 6.6
Change-Id: Ifeb6206a9fa04424964bfffd178844096ee7741b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The converting constructor of QWeakPointer<T> from a QWeakPointer<X>
needs to adjust the X* received by the "source" to a T*.
In case of non-virtual inheritance, this adjustment can be done
statically, by applying an offset to the pointer. In case of virtual
inheritance, we instead need to dereference the pointer (=access the
pointee), get its vtable, and from there find where (=the offset at
which) the T subobject is located.
This latter scenario requires the pointee to be alive throughout this
operation. Since QWeakPointer isn't an owning smart pointer, it's
perfectly possible that the pointee has already been deleted (the
"source" QWeakPointer<X> is dangling) or is being deleted (e.g. from
another thread that has just released the last QSharedPointer). For
this reason the converting constructor of QWeakPointer employs a
protection: it will lock() itself, and extract the raw pointer from the
QSharedPointer so obtained. This ensures that we won't access a dangling
pointer or a pointee about to be deleted.
We can however limit this (relatively expensive) protection only to the
case where there is virtual inheritance. In the other cases we don't
need it. This commit overloads the converting constructor for
QWeakPointer to deal with the two scenarios separately, and only lock()
in case of virtual inheritance.
Change-Id: I7194b90478cf35024e60cff542091308e4131ec2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
To be used in QWeakPointer.
Change-Id: I5ee9dd0862a0b23d316aaadf5d68bef1ce609e8b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Pretty sure this is a Clang bug because the promise member that it says
is getting shadowed shouldn't be in scope (`this` isn't being captured).
qfuture_impl.h:538:60: error: declaration shadows a field of 'Continuation<Function, ResultType, ParentResultType>' [-Werror,-Wshadow]
qfuture_impl.h:327:26: note: previous declaration is here
Pick-to: 6.5 6.6
Change-Id: Ifeb6206a9fa04424964bfffd17883e21cfec6d8e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Declare sendFortune() as a method because it's used in the connect()
overload taking a pointer-to-member-function, so it doesn't need help
from moc.
Q_OBJECT is not needed anymore as the "Server" class doesn't contain
signals and slots anymore.
Use Q_DECLARE_TR_FUNCTIONS Macro to allow tr() calls.
Task-number: QTBUG-117064
Pick-to: 6.6 6.5
Change-Id: Id197cb4c9f9df2102b769d028d8a0cae91e5c492
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Fix include order to respect the Coding Conventions.
Add needed includes to avoid Transitive includes.
Remove uneeded classes.
Remove QT_{BEGIN,END}_NAMESPACE because these are private Qt macros that
should not be used in the examples.
Task-number: QTBUG-117064
Pick-to: 6.6 6.5
Change-Id: Ie98d4fbddb18d5578e2651bdb4850527ff984582
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>
The data combined into keys for the various caches is either QByteArray
or plain const char *, so don't blow them up to QString.
Standardize cache-key generation using a fold expression instead of
QString::arg, which then makes use of QStringBuilder.
Change-Id: I12bb104b0d57156358d93deec8ecd37e10b4f864
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
