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>
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>
To be used in QWeakPointer.
Change-Id: I5ee9dd0862a0b23d316aaadf5d68bef1ce609e8b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
QlistWidgets with sorting enabled do not sort stable. A re-sort is
triggered when any Qt::ItemDataRole is changed and not only when
Qt::DisplayRole is changed. Due to an unstable optimization, the changed
element gets inserted at the beginning of their respective "equivalence
group".
This patch disables the optimization and ensures stable sorting
with std::stable_sort. Sorting is only performed, if the subset of
changed items in the range [begin, end] is not already sorted in the
whole list. For this purpose, it is assumed that the list has already been sorted before begin and after end. This assumption minimizes the subset to check.
Limits / side effect:
The patch focuses on the most common use case, which is a single item being changed. Replacing the optimization by std:stable_sort can potentially slow down the sorting performance of large data sets.
Task-number: QTBUG-113123
Pick-to: 6.5 6.6
Change-Id: Ib2bd08f21422eb7d6aeff7cdd6a91be7114ebcba
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When constructing a QWeakPointer<T> from a rvalue QWeakPointer<X>,
even if X* is convertible to T*, actually doing the conversion
requires access to the pointee's vtable in case of virtual inheritance.
For instance:
class Base { virtual ~Base(); };
class Derived : public virtual Base {};
Now given a `Derived *ptr`, then a conversion of `ptr` to `Base *` is
implicit (it's a public base), but the compiler needs to dereference
`ptr` to find out where the Base sub-object is.
This access to the pointee requires protection, because by the time we
attempt the cast the pointee may have already been destroyed, or it's
being destroyed by another thread. Do that by going through a shared
pointer. (This matches the existing code for the converting assignment.)
This requires changing the private assign() method, used by QPointer, to
avoid going through a converting move assignment/construction, because
one can't upgrade a QWeakPointer tracking a QObject to a QSharedPointer.
Given it's the caller's responsibility to guard the lifetime of the
pointee passed into assign(), I can simply build a QWeakPointer<T> and
use ordinary (i.e. non-converting) move assignment instead.
Change-Id: I7743b334d479de7cefa6999395a33df06814c8f1
Pick-to: 6.5 6.6
Fixes: QTBUG-117483
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QAbstractItemView installs the delegate as an event filter on the
editor, so the delegate will get the focusOut event (and other
events) before the editor does. QAbstractItemDelegate will then
emit commitData, signaling that the "updated" data should be
written back to the model.
In the case where the editor of a delegate (QAbstractItemDelegate)
is a QSpinBox with keyboardTracking set to false, the value of
the spinbox won't be updated while typing, but only when the
spinbox's text edit focus is lost. In this case, the delegate's
commitData will be emitted before the spinbox has had a chance
to update the value in its handling of the focusOut event.
To fix, make sure to update the value before the data is
committed to the model in the delegate's tryFixup method.
Fixes: QTBUG-116926
Pick-to: 6.5 6.6
Change-Id: I68540964342407d23387e4404a0fe3f00d80eb5f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If a move-to-trash operation failed, e.g. because the file was opened by
another process (or QFile), then the moveToTrash function would still
return true.
MSDN documents the IFileOperation::PerformOperations to return whether
the operation succeeded, but evidently this is only a statement about
the execution of queued up operations, not a statement about any of the
operations' success.
If the operation succeeded is reported by an HRESULT parameter
of the IFileOperationProgressSink::PostDeleteItem implementation,
and we ignored that parameter so far.
Check it via the SUCCEEDED macro, and set a boolean sink variable based
on that, which we can inspect to return the correct value.
Augment the test case by opening those files we create ourselves, and
if that fails (which it will on Windows, but not necessarily on other
platforms), then try again after closing the file. If the first attempt
succeeded, then the source file must also be gone.
Pick-to: 6.6 6.5 6.2 5.15
Fixes: QTBUG-117383
Done-With: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: Icb82a0c9d3b337585dded622d6656e07dee33d84
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
Makes it easier to locate later which test may be leaking stuff.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd178713f869752761
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The moveToTrash tests, on XDG platforms, would be trashing to
~/.local/share/Trash. Unlike Windows and Apple systems, the XDG trash
spec creates two files and these tests weren't deleting both of them, so
we had a slow increase of left-over files in ~/.local/share/Trash/info.
Cleaning up ~/.qttest is left as an exercise for the users. For example,
$ cat ~/.config/user-tmpfiles.d/qttest.conf
#Type Path Mode User Group Age Argument
e %h/.qttest 0700 - - 1w
Pick-to: 6.6 6.5 6.2
Change-Id: I9d43e5b91eb142d6945cfffd1786aeff91d34fde
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
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>
Don't get a QModelIndex out of a temporary QPersistentModelIndex.
Pick-to: 6.6
Change-Id: Ida9e25f1a17130e19b75221e1189e6f2fccd3f27
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@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>
Amends 4f4a8e75ab, after which
QItemSelectionModel printed a warning when destroying the model.
We reset the selection model in response to the model getting destroyed,
and since the model is already set to be nullptr at this point the
select() function complains about changing the selection with no model
set being a no-op.
Fix this by not calling reset() when the model gets destroyed - the
stored selection and currentIndex are already reset at this point -
and instead only call reset() when a new model is set in initModel.
Fixes: QTBUG-117200
Pick-to: 6.6.0 6.6 6.5 6.2
Change-Id: I12fc6b3fb2f2ff2a34b46988d5f58151123f9976
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
If the QCommandLineOption doesn't have a valueName, the parser won't
read the argument, therefore returning an empty value. If the developers
are calling ::value on the option, they clearly think it's expected to
get a value but won't ever be getting one, so we better warn them about
it.
Change-Id: I434b94c0b817b5d9d137c17f32b92af363f93eb8
Reviewed-by: David Faure <david.faure@kdab.com>
Use recursive descent to handle parentheses in config condition
expressions. This fixes cases like 'NOT (A AND B)'.
Fixes: QTBUG-117053
Change-Id: Iab1b6173abe00d763808bb972a9a5443ffa0938d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
[ChangeLog][QtWidgets][QDockWidget] A floating dockwidget that doesn't
have the DockWidgetClosable feature flag set can no longer be closed by
a call to QWidget::close or a corresponding keyboard shortcut (such as
Alt+F4).
Fixes: QTBUG-116752
Pick-to: 6.6 6.5
Change-Id: I7859a2eed11f0e4ee013f7f56611e282e9bcae9a
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This serves as regression test for future fixes of the config condition
evaluator.
Task-number: QTBUG-117053
Change-Id: Ib05fe5f5fb6aa2d440ecbc8affaf99b040553c06
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
When loading the fonts, we go through all the named instances
and register these as subfamilies. In addition to exposing these
variants by style name, we also register them with the according
weights, italic style and stretch. This adds a field to FontFile
to allow piping the instance index through to when we instantiate
the face.
[ChangeLog][Fonts] Added support for selecting named instances in
variable application fonts when using the Freetype backend.
Task-number: QTBUG-108624
Change-Id: I57ef6b4802756dd408c3aae1f8a6c792a89bee6a
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The XML stream writer previously added namespace declarations with the
same URL as existing ones, but new names, and renamed the XML elements
to use the new namespaces instead of the existing ones.
[ChangeLog] Fix renamed and duplicated namespaces in QXmlStreamWriter.
Pick-to: 6.5 6.6
Fixes: QTBUG-75456
Change-Id: I90706e067ac9991e9e6cd79ccb2373e4c6210b7b
Done-With: Philip Allgaier <philip.allgaier@bpcompass.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Not only are we subject to Q and P defines, we're also included in the
unnamed namespace now.
Amends df030e06a8.
Pick-to: 6.6
Change-Id: Ie2f4c9f45d9845d8a26140e0e1214e87b615ff02
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
This is needed to support passing it to other processes so they can
enable legacy, compatibility mode. Right now, there's no such code, but
I am 90% certain we'll need it soon in 6.6.x, if not for compatibility
changes in the future.
There's a bug in passing a QNativeIpcKey to another process that causes
QSharedMemory to use the wrong QSystemSemaphore for control (a feature
that should never have existed in the first place, but we're 15 years
too late on that). I have not yet investigated a fix for this, but it
will likely involve knowing the original legacy key.
Pick-to: 6.6 6.6.0
Change-Id: Idd5e1bb52be047d7b4fffffd1750b547013cb336
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
So we can add them in the future but cause older versions of Qt to
reject them if they don't know what they are.
Pick-to: 6.6 6.6.0
Change-Id: I512648fd617741199e67fffd1782b85935bb832a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Also move some docs from asBackendZone() to systemTimeZone(), making
clear that the system zone object is current at the time of creation
and won't be updated if the system is reconfigured. Adapt some tests
to fail and make clear that the system is misconfigured if no valid
system zone is found.
[ChangeLog][QtCore][QTimeZone] If systemTimeZone() is unable to
identify a valid system time zone, it now produces a warning the first
time it encounters the problem.
Task-number: QTBUG-116017
Change-Id: Ia437d8a03ff3cbf2b2cd98e8a8c3aebe50c1ee32
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
whenAll() and whenAny() create a shared context object which is
referenced by the continuation lambda. The refcount of context is only
correctly managed when it is copied non-const to the lambda's
capture list.
Fixes: QTBUG-116731
Pick-to: 6.6 6.6.0
Change-Id: I8e79e1a0dc867f69bbacf1ed873f353a18f6ad38
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
There's no need for atomic semantics for a simple "scope value
rollback" (not sure why the code doesn't use the real thing).
There's also no semantics that make sense.
Extract the integer out of the atomic and store it back.
Change-Id: I8ba89216d1931a73ff22a8af7fd656c3f6948793
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Compilers that support 128-bit integer types usually don't have
support for 128-bit literals, so provide Q_(U)INT128_C macros and back
them with UDLs. This, of course, only works in C++, so until compilers
provide built-in literals that support C, too, that's all we get.
[ChangeLog][QtCore] Added Q_INT128_C() and Q_UINT128_C() macros to
create qint128 and quint128 literals in a platform-independent way.
Pick-to: 6.6 6.6.0
Fixes: QTBUG-116822
Change-Id: I4be645baf2e007ee1aa1a27f9b5166671806dc49
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is part of our testing effort where we try enabling more tests for
Web Assembly platform on CI. Not all tests work out of box, so some of
them will require followup work.
This commmit also introduces a new mechanism of automatically renaming
files when they are added many times with the same filename to single
translation unit.
Change-Id: I620536494ea83aeb9b294c4a35ef72b51e85a38b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This fixes the recently added QEXPECT_FAIL about glob-deleteall
in a local directory (with a binary cache). Before adding a glob match
we ask the more-local (higher-precedence) directories if they have
a glob-deleteall for that mimetype, and skip it then. This "asking"
is a virtual method, implemented for both XML and binary providers.
Change-Id: I6e4baf0120749f3331fd2d9254bea750a322b72d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The old name Asia/Calcutta is being phased out. We can't assign
QTzTZP, so select between new name and old using a reference variable.
In the process, fix a QCOMPARE() against bool to a QVERIFY().
Pick-to: 6.6 6.5
Change-Id: I7cd8a813f8a88c8ae4ba07213f04f4ad0860cec0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A QMimeTypePrivate used to belong to a single provider, which would
provide the complete data for it.
But since the redesign in commit 7a5644d648, each provider
represents is a single mime directory, and the merging happens at the
QMimeDatabase level. So we need a QMimeType[Private] to be just a name
(a "request" for information about this mimetype) and the information
for that mimetype is retrieved on demand by querying the providers
and either stopping at the first one (e.g. for icons) or merging
the data from all of them (e.g. for glob patterns).
The XML provider was using QMimeTypePrivate as data storage,
give it its own struct QMimeTypeXMLData for that purpose instead.
Task-number: QTBUG-116905
Change-Id: Ia0e0d94aa899720dc0b908f40c25317473005af4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When running tst_qmimedatabase with the full shared-mime-info test suite
(which unfortunately requires local setup so this is easy to overlook),
we need *.webm to still be associated with video/webm.
So to test glob-deleteall, do that in installNewLocalMimeType(), with
other similar tests.
This however unearthed the following bug: the handling of glob-deleteall
is only correct when the local dir has no binary cache. It's broken
when using a binary cache. Added a QEXPECT_FAIL for now because this is
going to be fixed as part of a major redesign, coming up.
I also found out that neither xdgmime nor gio do this correctly...
Change-Id: Ib075fcdb792f60a859f23db8c2d7e1c6524f9050
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For historic reasons, the test had a single list of override xml files
to copy first into the global dir, and then into the local dir.
But glob-deleteall only makes sense in the local dir (as per the MIME
spec). Having two definitions for the same mimetype in the same dir
is undefined behavior, so the test was working by chance only, and
my upcoming refactoring/fixes caught that.
Change-Id: I4717683b4b3f9ba69f1fd815669460789700e877
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since compilers don't provide such macros, do it ourselves.
In order to test these macros, add ad-hoc specializations of
QTest::toString() for qint128 and quint128 locally to the test. Turns
out it's not too hard to write them, so we might move them to a public
header, yet.
Pick-to: 6.6
Change-Id: I1483f3af2ccec6038e1c780649f9ffe413bb59ef
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Check that QIntegerForSize<16> and std::numeric_limits<quint128> work
and that q(u)int128 are available in C mode, too.
Pick-to: 6.6
Change-Id: I44af8282399c78f6e74a8268af53bad64407ca34
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There were two problems:
- On platforms where QFLOAT16_IS_NATIVE == true, a qHash(qfloat16{})
call has become ambiguous between the three FP qHash() overloads
(float, double, long double), where it was unambiguously calling the
float one in Qt 6.4. This SiC was caused by the replacement of
operator float() by operator __fp16() in
99c7f0419e, which is in Qt 6.5.
- On platforms where QFLOAT16_IS_NATIVE == false, qHash(qfloat16{})
would produce a different value from qHash(float{}), and therefore
Qt 6.4, when the seed was != 0, because the former would go via the
one-arg-to-two-arg qHash adapter while the latter one would
not. Since participating functions are inline, this causes old and
new code to produce different hash values for the same qfloat16,
leading to a BiC possibly corrupting QHash etc.
Fix both by adding an explicit qHash(qfloat16). This function is
inline, so it doesn't add a new symbol to 6.5.x.
[ChangeLog][QtCore] Fixed qHash(qfloat16) which was broken from 6.5.0
to 6.5.3, inclusive. If you compiled against one of the affected Qt
versions, you need to recompile against either Qt 6.4 or earlier or
6.5.4 or later, because the problematic code is inline.
Pick-to: 6.6 6.5
Fixes: QTBUG-116064
Fixes: QTBUG-116076
Change-Id: Id02bc29a6c3ec463352f4bef314c040369081e9b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
