There's no reason to be storing `int` in the array data header and
then using it as a QFlags. Just store the QFlags.
Change-Id: I78f489550d74d15a560dacf338110d80a7ddfdd2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QFlags was lacking a named function for testing whether a QFlags object
contains _any_ of the bits set by a given enumerator/other QFlags.
Drive-by, add testFlags taking a QFlags, not just an object of the
enumeration; and simplify the implementation of testFlags to more
closely follow what its documentation says it does.
[ChangeLog][QtCore][QFlags] The testFlags, testAnyFlag and
testAnyFlags functions have been added.
Change-Id: Ie8688c8b0dd393d34d32bc7786cdcee3eba24d1c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
While at it, move tst_android under corelib/platform/android.
Change-Id: Icf91cd75cb5e04d03fe6a81d52fba52a485ca41f
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Since we changed binding evaluation to be always eager, we notify and
evaluate all bindings as soon as any dependency changes. This includes
bindings which have been initially installed on a property, but which
were later removed.
With lazy evaluation, we would only notify those bindings and mark them
as dirty, which is unproblematic. With eager evalution, we attempt to
evaluate the binding, though. While that part is still fine, afterwards
we would attempt to write the new value into the property. However,
there is no property at that point, as the binding is not installed.
Instead of adding a check whether the propertydataptr is null, we skip
the reevaluation completely by removing the bindings observers - and
thus the cause for the binding function's reevaluation. As soon as the
binding is set, we reevaluate the function anyway, at which point we
also capture the observers again.
Task-number: QTBUG-89505
Change-Id: Ie1885ccd8be519fb96f6fde658275810b54f445a
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This removes traces of QPropertyAlias which is internal API which is
a) not really working even before this change (no compatibility with
QBindableInterface due to QPropertyAlias not being derived from
QUntypedPropertyData)
b) not used anywhere
For BIC reasons, we need to keep some methods still around until Qt 7,
though.
Change-Id: I5bb4735a4c88cba275dc2cc6e29a46ca09622059
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This takes care of the last two QSFPM properties. They were postponed
because of the tricky relation between them and some bugs in handling
the changes.
The bug was fixed in bcbbbdb2d6 and
now the behavior is well-determined: updating filter regexp does
trigger case sensitivity change and vice versa. However updating
only regexp pattern (via QString overload or setFilterFixedString
or setFilterWildcard) does not change case sensitivity.
Task-number: QTBUG-85520
Change-Id: Idc41cf817de9e6263ed65a80fa40fc8415c8c856
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
filterRegularExpression and filterCaseSensitivity
will be handled in a separate commit
Task-number: QTBUG-85520
Change-Id: I848c5c6cbe8642efa156f4f5d33467976bbf0351
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
The commit amends commit 3966b571 to take UNC prefix into account as
well. Fixes the weird file name output as reported in QTBUG-74291 and
QTBUG-83365. Replace manual separator normalizing in qt_cleanPath(),
this is another spot where UNC prefix handling needs to be applied.
Also make QTemporaryFile operate on '/' as file separators to fix
creating both file types with native path separators on network shares.
Fixes: QTBUG-74291
Fixes: QTBUG-76228
Fixes: QTBUG-83365
Pick-to: 5.15 6.0 6.1
Change-Id: Iff8d26b994bf4194c074cd5c996cda3934297fa5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QMetaMethod] It is now possible to query the
constness of a method with QMetaMethod::isConst.
Change-Id: I8a94480b8074ef5b30555aeccd64937c4c6d97d4
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The libs and symlinks are in the same directory, no need
to have absolute paths.
Change-Id: I22dab933b1f3bdf244b0953c6bb7caaeedef5697
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CLDR v39 has no locales for Abkhazian, so the locale_index[] entry for
it actually indexes the last entry before the next language up the
enum. This has m_language_id less than Abkhazian.
Change-Id: If8b88f30476a981b3ee00ff8760a46ede0b7aab7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The calls were trying to pass a JNIEnv* from a QJniEnvironment using
conversion operator which was removed, and weren't detected since they
are templates and were missing tests. This fix that and add test cases
for setField() and setStaticField() calls.
Pick-to: 6.1
Change-Id: I6e1e6b7f557bbc664248ad364c48d63f58b70756
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The API allows users to request and check the status of various
permissions. A predefined enum class of the common permission types
on different platforms is used to allow requesting permission with
a common code. Platform specific permissions are defined only on their
relevant platform. For permissions that are not predefined, they can
be requested via a string variant of this API.
This adds the Android implementation only.
[ChangeLog][QtCore] Add new API for handling app permissions with an
initial implementation for Android.
Task-number: QTBUG-90498
Change-Id: I3bc98c6ab2dceeea3ee8edec20a332ed8f56ad4f
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The biggest trick here is the getter (QAbstractProxyModel::sourceModel),
which is returning nullptr, while internally using a global
staticEmptyModel() instance.
This lead to inconsistency while binding to a proxy model without
source model. The bound object would point to staticEmptyModel()
instance, while sourceModel() getter returns nullptr.
To solve this issue a custom QBindableInterface is implemented.
Task-number: QTBUG-85520
Change-Id: I597df891c7e425d51b55f50ccbacabdfe935cbac
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Previously, if multiplication overflowed when trying to set the date
and time of a formerly short-form QDateTime, its status didn't get set
to reflect the failed validity check. Added a test that now correctly
detects that it's produced an invalid date-time on overflow, where
previously it produced a wrong valid date-time.
Change-Id: Id46ca34d1e32e9b9b0630f3723cefd1c13b5761e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QCOMPARE made dead code of a more verbose QVERIFY2 below
Change-Id: I26b8286f61534f88b649fffd166b67d8603280a7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Instead of silently failing, we now print an explanatory warning to aid
with debugging.
Task-number: QTBUG-89512
Change-Id: I36dd2ce452af12d0523c19286919095e366bd390
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch extends the QJniObject::callStatic[Object]Method functions
with the overload which accepts a jmethodID parameter. This can be
convenient when the method id is already cached and you do not want
to query the method by its name and signature.
Task-number: QTBUG-92952
Change-Id: Ib0852a5a27da2a244ac63112784751ef9e32cfa5
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This patch adds some convenience methods to QJniEnvironment API:
* an overload of registerNativeMethods() that accepts jclass instead
of const char *className.
* a findMethod() function is added to query a methodID of a static
or nonstatic method by its name and signature.
Task-number: QTBUG-92952
Change-Id: Ib1bc892decea97e625c4822888b6183af6edd6dc
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Skipped startValue/endValue properties, since they are computed and
writable, which is not supported at the moment.
Skipped currentValue, since its setter might be called inside the
getter, which is not recommended.
Task-number: QTBUG-85520
Change-Id: I1f872b4fcc7227ed91b6915891bbc66019151826
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch amends bcbbbdb2d6.
It fixes the logic of filterCaseSensitivityChanged signal emission.
The call to QRegularExpression overload of setFilterRegularExpression
could change the filterCaseSensitivity, but the signal was never
emitted.
[ChangeLog][QtCore][QSortFilterProxyModel] A call to QRegularExpression
overload of setFilterRegularExpression now emits a
filterCaseSensitivityChanged signal, if required.
Pick-to: 6.0
Pick-to: 6.1
Change-Id: Id4ef04227c1f8ed98153fa5107ec3fbe4c0c77fb
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Analysis of problems with the new test for qFuzzyIsNull() revealed
that, where its version for double uses approximately 4500 * epsilon
and for float used 84 * epsilon as threshold, the qfloat16 version's
value was barely more than epsilon, with the result that the test had
to use a different value than the threshold to pass. (Converting the
threshold from float to qfloat16 and back made it bigger; in effect,
the threshold value was not <= itself.)
Furthermore, comparison with qFuzzyCompare() implied a value of
1/102.5 should be used, roughly 10 * epsilon, for consistency. When
1/102.5 is rounded to three significant digits (the precision we use
in QTest::toString(), for example), to give 0.00976f as threshold, we
get a value that, after conversion to qfloat16 and back to float, does
give a result <= what we started with. So change qFuzzyIsNull() and
its test to use this as qfloat16's threshold value.
[ChangeLog][QtCore][QFloat16] The qfloat16 threshold value for
qFuzzyIsNull() has changed from 1e-3 to 9.76e-3, almost a factor of
ten increase, for consistency with qFuzzyCompare()'s tolerance. Values
between these would previously have had qFuzzyIsNull(f) false despite
qFuzzyCompre(f, 1+f) being true.
Change-Id: I35816dce78da34a3e2339c8bc42d5bd03714a3f6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They were missing.
I also wanted to verify that it's true for sub-normal values.
At the same time, relocate qfloat16's implementation of qFuzzyIsNull()
to between those of qFuzzyCompare() and qIsNull(), since its apparent
absence initially confused me.
Change-Id: I9637c0070e754d16744c76fc9f846596257c6a63
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This reverts commit ec8808c302 but
retains its test, as the problem it fixed is now solved by having the
TZ backend validate the ID it's passed, so that it now only accepts
valid POSIX zone-descriptions and valid IANA IDs. The former were
being excluded by this check.
Amended a POSIX test to fail with the check in place; it passes now.
Change-Id: I0d5e8c6e0a315ac2509f3d23bebb52aede8f79d0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
With C++20 standard, src/corelib/kernel/qproperty.h of Qt Base cannot be
compiled at line 100:
QPropertyBindingSourceLocation(
const std::experimental::source_location &cppLocation
)
The reason is that source_location has been merged into namespace std
since C++20, and the header file has also been change from
<experimental/source_location> to <source_location>.
The problem can be avoided by define a constant.
Fixes: QTBUG-93270
Change-Id: I46b4daac6ea20f9623b43746880500d41396afb2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Cast consistently to quint8, which is the type we are streaming out
in the test.
Change-Id: I44d360ca6b75f14e7a2b80962ad249a6f6b1cb31
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The comparison between nullptr and QWeakPointer was just bogus
and ill-formed. The INTEGRITY compiler catches that even if
nothing tries to use the comparison. It is an ill-formed, no
diagnostic required case of a function template never being
able to produce a valid specialization. And while we're at
it, this patch makes the result of comparing a nullptr to
a QWeakPointer or vice versa the same as asking .isNull() from
the weak pointer, because it seems mind-boggling if those
are not the same operation.
Task-number: QTBUG-93093
Change-Id: I0cc80e795c9af2be1b76de05157aa458ef260f2e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is one of the more complicated ports. The target object
was represented by two variables in the past: A raw pointer and a
QPointer. The QPointer is checked in some cases to check whether
the target object still exists.
This patch introduces a targetObjectDestroyed() slot and connects
it to the destroyed(QObject*) signal of the target object.
In this slot, the animation is stopped. The checks become
obsolete thereby and it is sufficient to represent the target
Object in one raw pointer.
This raw pointer becomes a bindable property.
Fixes: QTBUG-92992
Change-Id: I7e2ddb5d8aed007400fe74bea1becf7bdfbf2563
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Windows wants ISO C++ _fileno and _unlink instead of posix fileno and
unlink. For fileno we have the QT_FILENO macro in qplatformdefs.h, so use
it. For unlink we don't have a macro in Qt, so declare one in the test.
Change-Id: I56c5c3fb4e500769c744132c46107816f89bb2c3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The property 'model' is ported to a bindable property.
The properties hasSelection, selection, selectedIndexes,
and currentIndex are left for later patches.
Task-number: QTBUG-85520
Change-Id: Ia424ce99fc80c3d807c634c21d161a3ad94b27d2
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Previously, an apparent POSIX rule would be saved and any defects in
it would only be discovered when trying to use it to generate
transitions. Instead, check that it has the right form during the
initial parsing of its data.
In the process, since checking for DST in the process is trivial,
implement a long-standing TODO to cache hasDaylightTime()'s
answer. The array it scanned was in any case being scanned during
construction, so detecting DST in init()'s scan is trivial; and its
failure to check the POSIX rule mean it failed to notice when zones
entirely specified by a POSIX rule have DST.
Adapt a test using a POSIX-only rule to verify it does know the zone
has DST; it did not, before this change.
Change-Id: I690c013d3331600f7348dae61c35d41e5599da70
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The description necessarily has fake transitions at start and end of
the year, potentially outside the year. These transitions should not
be reported by QTzTimeZonePrivate as transitions, although its data()
must find a "transition" whose data it can use (as in the permanent
standard time case, which could potentially be represented the same
way, although there's a saner way to do so, that the code already
handles) to report the zone's properties.
In the process, fix (and make more straightforward) the convoluted
decision-making code that was deciding which transitions to include in
the returned list. It was assuming invalidMSecs() would be set as the
atMSecsSinceEpoch of a transition, although this is computed in a way
that makes that value most unlikely, even when the result is invalid.
It also rather confusingly mixed < 0 tests as tests for overflow with
the one < 0 test that's about ignoring DST before 1970. Also added
comments to clarify some of what's going on there.
Expanded a recently-added test of a permanent DST zone to verify this
now works correctly.
Change-Id: Ia8d98f433fb1e479dba5479220a62196c30f0244
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There are two formats for such fields: one with a J prefix on a number
in the range 1 to 365, the other with no prefix and a range from 0 to
365. The code mistakenly treated the latter as if its range were from
1 to 366. The J-form doesn't count Feb 29th, so March always starts on
day 60; the code tried to take that into account, but adjusted in the
wrong direction (and this mislead me, in a recent partial fix, into a
fence-post error).
Add a test-case based on the Africa/Casablanca POSIX rule seen on RHEL
8.2, which tripped over the off-by-one error without a J prefix. This
incidentally also tests the J case.
Change-Id: I692ca511e5c960f91a6c21073d3b2f037f5e445f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It usually fails the test with "corrupted size vs. prev_size" message
coming from malloc() or some other memory allocation routine (which
signals about memory corruption probably)
Task-number: QTBUG-93176
Change-Id: I5e34971267c52c63cda2489bef5b09bed739f532
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
(cherry picked from commit 6d52d86b999088ec07e58c14197bddda043ef0aa)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The major part is stability tests for QList operations,
Also added std::shared_ptr to the Custom type. shared_ptr
accesses the memory which does not directly belong to
QList, so using it inside a passed-to-qlist type is
beneficial (e.g. ASan could catch extra issues)
Basic prepend-aware cases added to QString/QBA tests
Task-number: QTBUG-93019
Change-Id: I50e742bdf10ea9de2de66539a7dbb9abc4352f82
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
(cherry picked from commit adb41bbe00b2b853d4dd26cd9ee77ae5ed541576)
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Test the relocation logic through the QADP::relocate() method which
basically calls q_relocate_overlap_n inside and then ensures that
the data pointers are in good state
Running these locally in fact revealed a bug in the implementation,
so these tests are definitely good to have
Task-number: QTBUG-93019
Change-Id: I353ed46a31c5c77cd0c5fcacd3dfce46e5cf3e67
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
(cherry picked from commit 65d0f6829cc124f6d0d4003a17bedcb74dddf33b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use the data moves to readjust the free space in the QList,
which ultimately fixes the out-of-memory issues caused by
cases like:
forever {
list.prepend(list.back());
list.removeLast();
}
Task-number: QTBUG-91801
Task-number: QTBUG-91360
Task-number: QTBUG-93019
Change-Id: Iacff69cbf36b8b5b176bb2663df635ec972c875c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
(cherry picked from commit a0253f5f0249024580050e4ec22d50cb139ef8d9)
The six properties duration, updateInterval, currentTime,
direction, loopCount and easingCurve have been ported to the
new property system and are now bindable.
Drive-by renamed a local variable to avoid shadowing.
Task-number: QTBUG-85520
Change-Id: Ibabf106f5200d2dd4329a1e1f96112eccc29d6b1
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Routine update with minor changes to locale data, no new languages,
territories or scripts. Various Spanish locales change m_grouping_top
from 1 to 2, reversing a change to a test of Costa Rica's currency
formatting made in commit bb6a73260e.
Includes updates to time-zone IDs.
Fixes: QTBUG-91478
Pick-to: 6.1 6.0 5.15
Change-Id: I78ee161275b3c456c5800a7317a96947c932cf8e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Qt defines some integral datatypes (qsizetype, qintptr, quintptr,
qptrdiff) not in terms of the corresponding language datatypes (resp.
make_signed_t<size_t>, intptr_t, uintptr_t, ptrdiff_t) but as "integer
types with the same bit size of the corresponding language type" (and of
course the corret correct signedness for the target type).
This makes the Qt datatypes not printable via printf-like formatted
output, incl. qDebug, qWarning, QString::asprintf and so on; that's
because there isn't a format modifier that would universally work
with the Qt definitions.
For instance, on a 32 bit platform, ptrdiff_t may be a typedef for long,
while qptrdiff is a typedef for _int_ instead. Both long and int would
indeed be 32 bits, but they still are different types, and this means
that the ptrdiff_t-specific 't' length modifier would be wrong for
qptrdiff:
qptrdiff p;
printf("%td", p); // WARNING: -Wformat: wanted long, got int
Similarly, not using 't' breaks on 64 bits, and so on and so forth.
There isn't a way out, short of inserting casts on every print
statement.
So, let's adopt the same solution C/C++ use for their own integer
typedefs: the PRIx macros. This allows one to always use the correct
formatting specifier without the need of a cast.
I'm not adding the macros for the qintXX datatypes, as they already
exist in the Standard Library.
[ChangeLog][QtCore][QtGlobal] A series of PRIxQTDATATYPE macros have
been added. They make it possible to print some Qt type aliases
(qsizetype, qintptr, etc.) via a formatted output facility such as
printf() or qDebug() without raising formatting warnings and without
the need of a type cast.
Change-Id: I473226a661868aed9514d793c8e6e4d391ab5055
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Even if the user (usually accidentally) sets a thread count of zero or
negative. The reporter in the bug report did
QThread::idealThreadCount() - 1 on a 1 CPU system...
Drive-by add to the documentation and the missing #include.
Pick-to: 6.1 6.0
Fixes: QTBUG-93007
Change-Id: I6cdea00671e8479b9c50fffd167807d14e030154
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Define the template calls in the header to allow for better type
handling and checking with constexpr and avoid overuse of macros.
Depending on the type provided in the QJniObject's call, the
signatures and the correct JNI function variant is used.
If a type is not supported a static_assert throws a compiler error.
Pick-to: 6.1 6.1.0
Change-Id: I8a4d3ce85e1ff76ef385633f2a68511fffd12e55
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
If the signal takes a value, we pass the current value of the property
to it.
As we now use eager evaluation, accessing the current value is now
possible.
Change-Id: I5e6947a6575bfa8ca5143f56620c645d4750a686
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This mirrors the functionality of QObjectCompatProperty::notify, and can
be useful to delay notifications until a class invariant has been
restored.
Change-Id: I1c16a0b1537a1b53d144c8abe48e546553edf877
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This patch fixes the breaking of case sensitivity handling. The removal
of QRegExp killed the wrong code paths which leads to inconsistencies
when changing the regular expression throuh methods like
setFilterWildCard or setFilterFixedString. Changing the case sensitivity
also nukes the original options that were set on the regular expression
if it was set through setFilterRegularExpression.
[ChangeLog][QtCore][QSortFilterProxyModel] Case sensitivity as well as
regular expression options handling have been fixed. The original value
is properly kept when using setFilterWildCard and setFilterFixedString.
The regular expression options are now also properly kept when changing
the case senstitivity through setFilterCaseSensitivity.
Fixes: QTBUG-92260
Pick-to: 6.1
Pick-to: 6.0
Change-Id: Ifb4732306f0c7d79ad0b18d3f5437c4523bb40e5
Reviewed-by: Igor Kushnir <igorkuo@gmail.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Extended QObjectPrivate::ExtraData to store a pointer
to its parent, and reimplemented qGetBindingStorage()
function for QObjectPrivate::ExtraData.
This allows to use Q_OBJECT_COMPAT_PROPERTY macro
for a property, stored in QObjectPrivate::ExtraData
and solves all the problems with calling a custom
setter.
Task-number: QTBUG-85520
Change-Id: I40e01c29430846359ef9160fa1ae97c702be9a18
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
A POSIX rule's transition time is allowed an hour in the range from
-137 to 137; in particular, a negative hour is allowed, and used by
some Greenland zones using Europe's time-of-transition which, as they
are more than two hours west of Greenwich, happens before midnight.
This means the time of transition can't be represented by a QTime(),
so propagate the int that represents it to the code that consumes it;
and treat parsing failure as an error rather than "correcting" it - if
the transition time is given, it must be valid.
Changed tst_QTimeZone::isTimeZoneIdAvailable()'s verification of
validity to report the name of the zone it thought was invalid.
(A later change, validating POSIX rules, caued this to fail for
America/Nuuk without the present fix.)
Change-Id: I5c9127ac34d878554dd0aca1c1c7338c7e0e1c28
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the ID isn't even valid, don't waste cycles trying to make sense of
it as identifying a time-zone.
Add test of an invalid ID that provoked an integer overflow on trying
to parse it as a POSIX zone specification.
Fixes: QTBUG-92842
Change-Id: Ib80bbb88c11c0484ce0358acabbdc25c5bd8e0b3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The test use aggregate initialization on some classes which however
are no longer aggregates in C++20 (the rules changed again; in C++20
having a user-*declared* constructor makes a class not an aggregate).
Just add a constructor so the code keeps compiling in both 17 and 20.
Fixes: QTBUG-92963
Pick-to: 6.0 6.1
Change-Id: I52371c5ee34c84358987b5ae8bee9ab9c49c8eab
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before this change, QXmlStreamReader prefix value was always an empty
string for EndElement when the documentation state : "Returns the prefix
of a StartElement or EndElement."
The error was a missing update of the prefix value when parsing
EndElement.
I updated the tests data which were also wrong because no prefix were
reported even for </a:foo>. No new test is necessary, I think, the test
data already cover the cases of EndElement with a prefix and without one
(unchanged here).
Fixes: QTBUG-86847
Pick-to: 5.15 6.0 6.1
Change-Id: I0ad38b9741d760f1ce688a36f969ec14e20a928c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is only one property in QSequentialAnimationGroup,
currentAnimation.
This patch ports this property to the new property system
Task-number: QTBUG-85520
Change-Id: Id528d30f551e88a6165bbb6a3c09d44e89257de5
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QList tests have mostly a scheme of:
void opInt() { op<int>(); }
void opMovable() { op<Movable>(); }
void opCustom() { op<Custom>(); }
As a drive by, move the leak checking into a separate struct/macro
Change-Id: I7cdda3a6c2aa324968aa26594da9f9eafbd49a0a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A sticky QPropertyBinding is a binding that does not get removed when a
write occurs. This is used in the QML engine to implement support for
the QQmlPropertyData::DontRemoveBinding flag.
Task-number: QTBUG-91689
Change-Id: Ib575b49abe634215318ccc7ba46212cc21eb4dad
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
UAX #29 in Unicode 11 changed the EGC algorithm to its current form.
Although Qt has upgraded the Unicode tables all the way up to
Unicode 13, the algorithm has never been adapted; in other words,
it has been working by chance for years. Luckily, MOST
of the cases were dealt with correctly, but emoji handling
actually manages to break it.
This commit:
* Adds parsing of emoji-data.txt into the unicode table generator.
That is necessary to extract the Extended_Pictographic property,
which is used by the EGC algorithm.
* Regenerates the tables.
* Removes some obsoleted grapheme cluster break properties, and
adds the ones added in the meanwhile.
* Rewrites the EGC algorithm according to Unicode 13. This is
done by simplifying a lot the lookup table. Some rules (GB11,
GB12, GB13) can't be done by the table alone so some hand-rolled
code is necessary in that case.
* Thanks to these fixes, the complete upstream GraphemeBreakTest
now passes. Remove the "edited" version that ignored some rows
(because they were failing).
Change-Id: Iaa07cb2e6d0ab9deac28397f46d9af189d2edf8b
Pick-to: 6.1 6.0 5.15
Fixes: QTBUG-92822
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
There isn't a QByteArray constructor taking a char8_t*. (I am not
sure if there should be one; QByteArray is not going to anything
special about that information anyways.)
Change such strings to be "ordinary" narrow string literals.
There should be no problems at doing so, as by default we build in
UTF-8 mode under all compilers.
Pick-to: 6.1 6.0
Change-Id: Ia200ec6e3b0453bad033d5d8ff34c013bb27abd1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add Qt::begin/endPropertyUpdateGroup() methods.
These methods will group a set of property updates together and delay
bindings evaluations or change notifications until the end of the update
group.
In cases where many properties get updated, this can avoid duplicated
recalculations and change notifications.
Change-Id: Ia78ae1d46abc6b7e5da5023442e081cb5c5ae67b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When a property value changes, first update all dependent bindings to
their new value. Only once that is done send out all the notifications
and changed signals.
This way, if a property depends on multiple other properties, which all
get changed, there will only be one notification; and (potentially
invalid) intermediate values will not be observed.
Fixes: QTBUG-89844
Change-Id: I086077934aee6dc940705f08a87bf8448708881f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Too much of the existing code in Qt requires eager evaluation without
large scale modifications. Combined with the fact that supporting both
eager and lazy evaluation has a high maintenance burden, keeping lazy
evaluation, at least in its current state, is not worth it.
This does not diminish other benefits of the new property system, which
include
- a C++ API to setup and modify bindings and
- faster execution compared to QML's existing bindings and the ability
to use them without having a QML engine.
We do no longer benefit from doing less work thanks to laziness. A later
commit will introduce grouping support to recapture some of this
benefit.
[ChangeLog][Import Behavior Change][QProperty] QProperty uses always
eager evaluation now when a dependency in a binding changes.
Change-Id: I34694fd5c7bcb1d31a0052d2e3da8b68d016671b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
At least some modern 64-bit systems have widened time_t to 64 bits
fixing the "Unix time" problem. (This is even the default on MS-Win,
although the system functions artificially limit the accepted range to
1970 through 3000.) Even the 32-bit range extends into January 2038
but the code was artificially cutting this off at the end of 2037.
This is a preparation for using the same also all the way back to the
start of time_t.
In the process, simplify and tidy up the logic of the existing code,
update the docs (this includes correcting some misinformation) and
revise some tests.
Fixes: QTBUG-73225
Change-Id: Ib8001b5a982386c747eda3dea2b5a26eedd499ad
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the backends run into an error in computing the offset, they return
INT_MIN; but they are valled via the front-end, which returns zero
when the zone is invalid. So treat INT_MIN returns from the backend
the same as the case of being invalid.
Change-Id: Ic3c4dfe964dbfba4030c770213eca8a63e84736d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For QProcess, there is no point in suppressing recursive
QWPR::readyRead() emission, as the former manages this logic itself. On
top of that, the non-recursive nature of QWPR::readyRead() indirectly
disallowed reading from the channels inside
QProcess::waitForReadyRead(), if that is called from a slot connected
to QProcess::readyRead().
QWPW had two signals, one allowing recursion and one not.
This commit allows recursion of QWPR::readyRead() and
QWPW::bytesWritten(), and moves recursion suppression to the higher-
level classes. This makes the code more uniform and efficient, at the
cost of a few duplicated lines.
Change-Id: Ib20017fff4d92403d0bf2335f1622de4aa1ddcef
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
pro2cmake did not take into account the
QT -= qt
bit of the .pro files.
Fixes: QTBUG-91676
Change-Id: If1373ee966312e4246490bd7389d75be9fa739cb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The use of "Country" is misleading as some entries in the enumeration
are not countries (eg, HongKong), for all that most are. The Unicode
Consortium's Common Locale Data Repository (CLDR, from which QLocale's
data is taken) calls these territories, so introduce territory-based
names and prepare to deprecate the country-based ones in due course.
[ChangeLog][QtCore][QLocale] QLocale now has Territory as an alias for
its Country enumeration, and associated territory-based names to match
its country-named methods, to better match the usage in relevant
standards. The country-based names shall in due course be deprecated
in favor of the territory-based names.
Fixes: QTBUG-91686
Change-Id: Ia1ae1ad7323867016186fb775c9600cd5113aa42
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since conversion operators do implicit conversion that might bring
some potential issues while using the API, let's stick to having
an operator* instead.
Pick-to: 6.1 6.1.0
Change-Id: Ie7ad5537958944b8d1c11d69fbd30284b4b0344d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
The POSIX rule parser used by QTzTimeZonePrivate recklessly assumed
that, if splitting the rule on a dot produced more than one part, it
necessarily produced at least three. That's true for well-formed POSIX
rules, but we should catch the case of malformed rules.
Likewise, when calculating the dates of transitions, splitting the
date rule on dots might produce too few fragments; and the fragments
might not parse as valid numbers, or might be out of range for their
respective fields in a date. Check all these cases, too.
Added a test that crashed previously. Changed
QTimeZone::offsetFromUtc() so that its "return zero on invalid"
applies also to the case where the backend returns invalid, in
support of this.
Fixes: QTBUG-92808
Pick-to: 6.1 6.1.0 6.0 5.15
Change-Id: Ica383a7a987465483341bdef8dcfd42edb6b43d6
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
A few methods in QBindable which do not modify anything were not marked
as const so far. This adds the missing const, and a test to verify that
they work.
As all methods are fully inline, this does not cause any binary
compatibility issues.
Fixes: QTBUG-89508
Change-Id: If06d33bc405232887b8c371c268840ba34dbadf6
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
During reportFinished we may call a continuation which might end up
triggering one of the signals.
Pick-to: 6.0 6.1
Change-Id: I19546fcca12be71cd536e4287eb5eddd9d236830
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Before calling the index function, we need to check the validity of the parameters.
Fixes: QTBUG-91878
Pick-to: 5.15 6.0 6.1
Change-Id: I9ec7265fff3f81b8a288c4ba8fae606a2ec808a6
Reviewed-by: David Faure <david.faure@kdab.com>
With C++20, there is a new iterator_category: contiguous_iterator, for
containers whose elements are stored contiguously in memory. In Qt 6,
QList satisfies this requirement.
However, we still need to tell the standard machinery about it. Step one
is to mark the iterators as contiguous_iterator; as that exists only in
C++20, we have to ifdef accordingly.
We also have to ensure that the iterators satisfy pointer_traits by
defining element_type due to how contiguous_range is specified. As this
runs afoul of LWG 3346, we check for known bad _GLIBCXX_RELEASE
versions.
Change-Id: I8c134544e694ba937e4d912393eb72fa75b49e3d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Add new configure option -make minimal-static-tests and CMake option
QT_BUILD_MINIMAL_STATIC_TESTS. In conjunction with QT_BUILD_TESTS
it will enable building a minimal subset of tests when targeting
a static desktop Qt build.
In qtbase the minimal subset includes all the auto tests of testlib,
tools, corelib and cmake. In particular this will also do cmake build
tests and qmake build tests (tst_qmake)
Adjust CI instructions to enable building a minimal subset of static
tests when a platform configuration is tagged with the
MinimalStaticTests feature.
Fix and skip a few tests that were failing.
Pick-to: 6.1
Task-number: QTBUG-87580
Task-number: QTBUG-91869
Change-Id: I1fc311b8d5e743ccf05047fb9a7fdb813a645206
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This commit amends 4ceaf22bed.
Signal parameter was not actually used, even is the signal was
specified.
This patch fixes it and also introduces unit-tests for this issue.
Change-Id: I029d413644eb6a72af3bdce27cc5f5bcadfe946a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Currently, QThreadPool's generated threads inherit the priority from the
thread they are created and that cannot be changed. This merge request
adds a property to QThreadPool so that the priority of the threads can
be different.
The default behavior does not change.
[ChangeLog][QtCore][QThreadPool] QThreadPool can now be configured to
use a different thread priority when creating new threads than the one
it inherits from the thread it was created in. This will only apply to
the threads started after the property is changed.
Fixes: QTBUG-3481
Change-Id: Ic98d4312d055a3357771abb656516ebd0715918d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is no need to write emit and notify at the same time, as not
emitting after notify does not make sense.
This naturally only applies to properties with a changed signal.
Change-Id: I99ff7863a509262ad9d4f7c9c5afbc66fd37001c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
For QObjectCompatProperty, which allows to do basically anything in its
setter, it is actually easier to manually specify when the change should
become visible. This is in line with manually writing emit calls in the
old property system, and allows the preservation of class invariants.
Change-Id: I585bd3f25d722ca3fd721ead85fe73dbee26c5f6
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Compilers are catching up, so some #if 0 codepaths can now be
conditionally enabled.
Change-Id: Ia9e87a096bc2ae4789ab390a9170d9c1eb9690d6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This check doesn't really do anything useful anymore: QStringLiteral
is used in Qt without any extra QT_NO_UNICODE_LITERAL #if-ery
Additionally, clean the related (and outdated) comment in
{QString, QByteArray}::literals()
Change-Id: I65b1eac33c5470508997be24f9ba6cf56d8578ea
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Q_CC_GNU is defined on compilers that masquerade as GCC (Clang, ICC),
so using it to work around GCC-specific bugs is wrong. Introduce a
local define for _only_ GCC and use it in place of Q_CC_GNU.
Drive by: version-fence a test we now know it's been fixed upstream,
and correct the link to the corresponding bug report.
Pick-to: 5.15 6.0 6.1
Change-Id: I9059d6e6bf86157aca71590ac22afb1a1c114313
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This function returns the metatype corresponding to the metaobject, or
an invalid metatype for namespaces.
This works as follows: First we increment the metaobject revision for
new metaobjects. Metaobjects with older revisions are handled by doing a
lookup by name. That fallback is also used for dynamic metaobjects (from
QtDBUS and those created by QMetaObjectBuilder).
For new metaobjects, we store the metatype in its metatype array, behind
the property metatypes. This avoids any changes to the property and
method metatype extraction logic: For properties, the metatype access
does not change, as the new metatype is after their metatypes. For
method metatypes, we already have an indirection layer (using offsets),
so by adjusting those offsets by one, the same logic keeps working.
To distinguish between namespaces and dynamic metaobjects, namespaces
store the metatypeinterface pointer for void in the metatype array,
whereas dynamic metaobjects store a nullptr.
One nice additional benefit is that this simplifies the generator logic
in moc, as the metatype array is now never empty.
Task-number: QTBUG-92077
Change-Id: Id3f920f28553f12032a71a1a87dad29e5374dbe7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Fix operator checks for containers whose value_type equals themselves.
It does not make sense to recurse on value_type in that case. Thanks to
std::disjunction having short-circuiting semantics, we can avoid that
issue by checking first whether T is T::value_type.
As a drive-by, check for value_type typedef before checking for
begin/end in is_container. This works around an issue in gcc <= 8.1,
which fails to correctly SFINAE the case where begin and end are private
methods.
Pick-to: 6.0 6.1
Fixes: QTBUG-89456
Change-Id: I27305a7cfe050f13a279c07f00bc229c01daa25b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Test we get the same starts of various days. Some coming changes shall
break some of these, but they should all be back to working by the
time we're taking account of DST before 1970 as well as after.
The first two or three test-cases work by accident in most zones, at
present, due to the zone-based code-path ignoring the LMT period
before the zone's first transition; but Europe/Helsinki had a renaming
transition in 1878, so does see its pre-zone offset between then and
the switch to UTC+2 in 1921, leading to failures in exactly the zone
Coin tests. So suppress these three test-cases pending later fixes.
On Windows, the next text (still pre-epoch) gets bogus zone data for
its LocalTime, so suppress that likewise.
Task-number: QTBUG-80421
Change-Id: I2264e0e436d92112b03264faa410e30057b8f73b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
qtbug_xxxxx is a fairly ambiguous test name
Change-Id: I4b407160464c9b8300d3683549b0ede837161e7b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
MSVC generates the following for those tests:
warning C4996: '_open': This function or variable may be unsafe. Consider using _sopen_s
instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online
help for details.
We need to set the define before any C runtime headers are included, so
do it right away, it doesn't do any harm on other compilers.
Change-Id: Ia25afb87934058c3f27e63820eeb2db063a627f1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
As QMultiHash uses a pointer for the data, nullptr dereference is a
thing, so check for valid d before doing anything in count()
Fixes: QTBUG-91704
Pick-to: 6.0 6.1
Change-Id: Ia20440cd7bdc03cb09c77f796fb9c5b52765eac5
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The code in qtdeclarative did not do anything at all anymore.
Change-Id: Idd97145cb74aeb4f43dfce2f282a765e90945073
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There may be a race where e.g. thread 'B' is woken up by a queued invoke.
At the same time thread 'A' asks 'B' to quit, which will set various
atomics (some important ones are 'interrupt' in the dispatcher and
'exit' in the event loop), but it does _not_ try to send another wake
since there is already an unhandled wake triggered by 'B' itself.
Sadly 'B' reads the 'exit' atomic before 'A' updates it.
Then, slightly before, 'B' sets 'interrupt' back to 0, 'A' write 1 to
it, meaning 'A's interrupt is ignored. Then, since there is no
interrupt, 'B' goes back to waiting for events, leaving the thread alive
and running instead of quitting.
Maybe this has unforeseen consequences (one consequence is that it will
return and re-enter the event dispatcher once more, possible
unnecessarily)
Fixes: QTBUG-91539
Pick-to: 6.1 6.0 5.15
Change-Id: Ie6f861f42ffddf4817d5c8af2d764abe9d9103c2
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When the source models don't have the same number of columns, the proxy
keeps only the smallest number of columns across all source models.
Afterwards, if a source model emits dataChanged in a column past
that number (a "hidden" column), the proxy needs to ignore it rather than
assert.
But also, if the source model emits a dataChanged signal across both
visible and hidden columns, then the last column number needs to be
adjusted so that the signal is correctly processed and forwarded.
Task-number: QTBUG-91253
Pick-to: 6.1 6.0 5.15
Change-Id: I939e8ec0faf41370472f86785851292e4372f72c
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The prior tst_QDateTime::setMSecsSinceEpoch(-1) testcase was the last
millisecond of 1969; which (deep in the relevant function) actually
uses time_t 0 (with the -1 ms offset taken aside to be put back
later); so add the matching -1 second test. At the same time, add +1ms
and +1s checks for symmetry.
Change-Id: Ib487305f6ad81b55563ea59926cae13fb1fde592
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Based on the discussion in https://codereview.qt-project.org/c/qt/qtbase/+/336742
changing our types from RELOCATABLE to PRIMITVE is fine.
Change-Id: Ica867203aa813d19fdfd3753fc4ff36ef4332fc3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The test causes frequent failures in the CI. This is the most
subtle fix until it is properly fixed.
Pick-to: 6.1
Task-number: QTBUG-91423
Change-Id: I6499378dcd3ed1c31275db38d83b572e764366cc
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Samuli Piippo <samuli.piippo@qt.io>
Before this change, the QMetaType for T const* where T is derived from
QObject would not store the static QMetaObject of T. This commit changes
this. As a consequence, the metatype system can now convert between
const and non-const pointers to QObject. Note that this allows casting
const away; but so does C++ with const_cast.
In addition, a new flag, QMetaType::IsImmutable is introduced, and used
to tag the metatypes of pointer to const types. This allows code to
discern between pointers to mutable and const QObjects, which is
relevant for the QML engine.
Task-number: QTBUG-82354
Change-Id: I3e4e4f39f565bd99a65e161528ce5304df73d6d6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
After QPoint(F), it's now the time of QSize(F) and QVectorND,
which can be unambiguously decomposed.
[ChangeLog][QtCore][QSize] QSize is now usable in a structured
binding declaration.
[ChangeLog][QtCore][QSizeF] QSizeF is now usable in a structured
binding declaration.
[ChangeLog][QtGui][QVector2D] QVector2D is now usable in a
structured binding declaration.
[ChangeLog][QtGui][QVector3D] QVector3D is now usable in a
structured binding declaration.
[ChangeLog][QtGui][QVector4D] QVector4D is now usable in a
structured binding declaration.
Change-Id: I67bb152f4210f2be27607179cd2ec522174cc483
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When attaching a continuation with the default (QtFuture::Launch::Sync)
policy, it will be launched in the same thread where the parent has
been executing, or in the thread where the parent lives, if the
continuation is attached after the parent has already finished. Fixed
the test-case to make sure the continuations are attached while the
parent is still running, so that they can be resolved in the parent's
context.
Fixes: QTBUG-91373
Pick-to: 6.1
Change-Id: I82b3b0c47b76d121b44bd512659c08b3b474e351
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In QTimeZonePrivate::dataForLocalTime(), mistrust the Android
backend's hasDaylightTime(), as it has a comment saying it only knows
about future transitions, not past. This caller of it really needs to
query "has ever had a transition", which this doesn't answer. Many
zones that have no plans for future transitions have had transitions
in the past; these were failing the transitionEachZone() test.
In the process, refine the test itself, making sure we catch some
quirk cases that shouldn't arise and making the debug message on
failure more informative (while eliding the zone name, as this is part
of the test name anyway, so added to the output by qDebug() itself).
Fixes: QTBUG-69131
Change-Id: I88a0528182c247acb8b6327b40516178e455bcc0
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We haven't used the spawn functionality on QNX since Qt 5.7 (commit
005a8bfbf0) because that's when we dropped
support for QNX 6.5.0.
Change-Id: Ic90d8429a0eb4837971dfffd1664f9712bdce2d8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
And set *pid to -1.
[ChangeLog][QtCore][QProcess] If a startDetached() fails to start the
target application, the QProcess object should now have a proper error
string in errorString().
Pick-to: 6.1
Change-Id: Ic90d8429a0eb4837971dfffd1664e825ffcb923e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
That qWarning cannot be in the child process (we don't know if a user
logger is fork-no-exec-safe) and the failure to chdir() should be
reported as a failure in QProcess::startDetached() instead.
Change-Id: Ic90d8429a0eb4837971dfffd1664e7577c81610b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: David Llewellyn-Jones <david.llewellyn-jones@jolla.com>
I get a warning about the variable t_var being set but not used.
This patch fixes the warning.
Change-Id: Ib2df5ed2dddd283eb87f71a8b85951d1f67f04f2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QTimeZone tests have some helper functions to test details of a
QTZP instance; these use QCOMPARE(), so may return early on failure.
The callers then need to notice the failure and, in their turn, also
return.
Change-Id: I0a188e9641ced70c9ffedd95e91f39681fad768a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Its back-end lacks transition data, so the test can't possibly
succeed. Make the skip conditional on the tested zone having
transitions, so that the test will come back into play if we ever gain
support for transitions on Android.
Fixes: QTBUG-69129
Change-Id: Ie4f96601b8b18cd496efbde7cf2557875cf3c1c9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
A recent change ( a7ca8b1a28 )
led to failure of binding removal in setInterval().
This was fixed by introducing setterScope.
This patch add unit tests for this regression.
Change-Id: Ic8da1f2d82ad6c8ccd81c9b1eff72d42cf75f28a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Apparently we used to have (back in 2007, only on Windows,
incompatibly with what we were then using on Unix) a TextDate format
(only for QDateTime, QDate used what it still uses) that put the
day-of-month number, with a dot after it, before the month's short
name. We have retained parsing of this format, on all platforms, ever
since.
It no longer matches the format we now use (since 5.2, in 2013, commit
61b56a89a1, which harmonised the format
with Unix and QDate); now seems like a good time to stop complicating
our parser for its sake.
[ChangeLog][QtCore][QDateTime] The parsing of Qt::TextDate in
QDateTime::fromString() no longer supports the old TextDate format
used (only) on Windows by Qt < 5.2 ("ddd d. MMM yyyy" with an
"HH:mm:ss" time either appended or inserted before "yyyy").
Change-Id: I73a798ab78f187543e415119cc4a11f1cfd73820
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since fromString() can't parse the (ambiguous at the best of times;
also backend-dependent and thus potentially system-locale-dependent)
abbreviations currently produced (since 5.9) and can parse UTC-based
offsets, the OffsetName of the zone is a more robust format for the
zone-suffix. This also makes it possible to consistently use the C
locale, compatibly with everything else about post-6.0 date-time
serialization.
[ChangeLog][QtCore][QDateTime] When spec is Qt::TimeZone, the
offset-suffix now used for the toString(Qt::TextDate) format is now a
UTC-based offset string, compatible with the parsing (now) supported
by fromString(). The zone-abbreviation suffix in use since 5.9 was not
parseable.
Change-Id: I4024ae87980c6d3590c68a67b8d1c8f433e36855
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There are GMT-offset zones whose convention for the sign of the offset
is the reverse of what we are (still) using, which is the usual
convention for UTC-offset zone: for example, the Olson Database's
Etc/GMT+3 has offset -3 hours in the UTC-based system we use, so we
give it suffix GMT-0300. The UTC-based suffix is also what we use as
the abbreviation for OffsetFromUTC() in toString().
For now this only adds support for parsing a planned future form: the
old form using GMT is retained, to give client code some chance to
prepare for a backwards-compatible transition. Although the GMT prefix
is matched case-insensitively, only match UTC if fully upper-case;
there is no meaningful precedent for case-insensitive usage here.
[ChangeLog][QtCore][QDateTime] The Qt::TextDate format now recognizes
UTC-based offset suffixes in addition to suffixes based on the
deprecated alias GMT. This prepares for toString() to use such
UTC-based suffixes for time-zones (fromString() cannot parse the
present abbreviation suffix). A future release of Qt shall use
UTC-based suffixes in place of the present GMT-based suffixes (which
conflict with GMT-based IANA zone names) for Qt::LocalTime and
Qt::OffsetFromUTC time-specs. Client code is encouraged to use and
recognize UTC-based zone suffixes in preparation for that transition,
unless compatibility with versions before 6.2 is required.
Change-Id: I5a42a488f1232a30f4b427b7954759283423b9b3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The emulation detection has been usable only on qtbase tests, move it to
QTest so that it can be used in other modules as well.
Pick-to: 6.1
Change-Id: I4b2321b7856414d7b1cfd5e6b1405a633c6bb878
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's the QScopedPointer test, so we want to test deprecated APIs.
Change-Id: I029103b3150c576cba9b395aafc571b9fccc914a
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Instead of an XFAIL, actually test what we expect will happen for the
test, namely that the milliseconds will be lost. In the process,
verify that milliseconds since epoch also matches what was expected,
change an "expecting empty" condition to check for the "invalid"
test-case to which it's actually relevant and note that this test-case
shall need amended when we update our ISODate support to the 2019
update, which extends the year range.
Task-number: QTBUG-56552
Pick-to: 6.1 6.0 5.15
Change-Id: I680aa31ee0dcc8fadabb5d4cd6c083a8afd48573
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The test verified that a LocalTime's time since Epoch changes when the
system time-zone changes. This works when the QDateTime object is in
short form and recomputes its offset from UTC every time it is needed,
but fails with a pimpled QDateTime, as this caches its offset from UTC
when it is created, saving the recomputation which - in the far more
usual case where the system time-zone does not change in the lifetime
of a QDateTime object - would normally produce the same result.
Changed the test to use a newly-created QDateTime constructed with the
same parameters, which doesn't have the cached out-of-date knowledge
of its zone offset. Removed the XFAIL. Made the test data-driven and
added test-cases: one so close to the Epoch that it should be short
even on 32-bit systems, one so far that it's pimpled even on 64-bit
systems (used in reproducing the issue in order to debug it).
This then revealed that Android 5 doesn't seem to support the POSIX
zone IDs used by this test, so it now verifies that LocalTime has the
expected offset from UTC after zone changes, QSKIP()ping if not.
Documented that the behavior of LocalTime is undefined after a change
to the system time-zone. Cleaned up the existing doc of Qt::TimeSpec
in the process.
Fixes: QTBUG-89889
Pick-to: 6.1 6.0 5.15
Change-Id: I1058f47a1ff3ee1c326f3579ac80bd8bab242e28
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The initial implementation and the commit
c00ab6f8ea was wrong:
* env->findClass() in fact returns a global reference, and in any
case we shouldn't be calling that, instead QJniObject would be
enough.
* The size param provided to env->RegisterNatives was wrong.
* A test for registerNativeMethods() is added to ensure such break
is not repeated again.
Task-number: QTBUG-89633
Pick-to: 6.1
Change-Id: I4d3a6a9270755f465c40add25521fb750dd4de0a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
The system locale of a macOS application is not affected by environment
variables like LANG. Yet, we were reporting a name determined from
environment variables as the fallbackUiLocale(), rather than one based
on the language and country of the actual system locale.
This lead, via the usual CLDR likely-subtag fallback, to claiming the
system locale's name, language, script and country were those obtained
from these environment variables, even when they were at odds with the
actual locale being used by the system, which was being used for some
queries.
Worse yet, any data not supplied by these queries was being obtained
from the same CLDR locale as the name, making for an inconsistent mix
of locale data.
While we cannot avoid the likely-subtag fallback step for fallback
data, it is more consistent to use the actual system locale's name
as start-point for that fallback.
At the same time, add support for the language, script and country
queries, so that the QLocale::system() describes itself faithfully,
instead of claiming to be the locale that results from that fallback.
If we want to support LANG or other environment variable overrides,
they should be handled by the layer above the system locale, by
changing the default locale of the Qt application, as if the user
had called QLocale::setDefault().
[ChangeLog][QtCore][QLocale] QLocale::system() on macOS no longer
pretends to support LANG or other environment variables as overrides,
as this is not a feature that the system locale on macOS supports.
To override the locale of an application, use QLocale::setDefault(),
or pass -AppleLocale en_US.
Fixes: QTBUG-90971
Change-Id: Ibdaf5ff9a2050f61233a88eabf3c29094f7757f1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Previously the only test was that it produced no warnings,
if anyone paused to read the output to notice them.
Change-Id: I225ca99c7ec316186702c0fdb355585374c014a4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Somehow QList::fill(t, newSize) introduced a regression in Qt6:
when newSize < QList::size() we should resize to the newSize.
This is aligned with QVector::fill() in 5.15 and std::vector::assign()
While 6.0 is already out, picking it to 6.0.x could save someone who
haven't migrated yet as well as fix some accidental bugs in Qt's code
[ChangeLog][QtCore][QList] Fixed QList::fill() regression introduced in
6.0: calling fill() with size < current list size wouldn't truncate the
list
Fixes: QTBUG-91042
Pick-to: 6.0 6.1
Change-Id: Ic166e2c5e42390b61df1030f7c705e344433f7f2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
gcc 9 consumed enourmous amounts of memory building the test, regularly
dying on a VM with 4GB RAM. Splitting it up helps.
As a drive-by, use inline static variables, and rename the header used by
other tests to tst_qmetatype_common.h.
Change-Id: Ib716d8e3506aac6c87845e57b04cb1a4f6c68387
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Amend ac970d48fd and use
QEXPECT_FAILURE for systemTimeZone test on 32bit systems.
Task-number: QTBUG-89889
Change-Id: I0eed35df871c69a20bcd7c544fc0e9a48dd8db7b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Dating from the origins of our support for the zoneinfo file format,
the mapping of POSIX's day-numbering (0 = Sunday through 6 = Saturday,
see [*]) to Qt's (1 = Monday through 7 = Sunday) was done by mapping 0
to 1, when it should have been 7.
[*] http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
Corrected a QTimeZone test that trusted the results it got without
checking which day of the week those were: they were all Mondays.
Verified that the corrected dates are in fact Sundays.
Checked the zone abbreviations, too.
Fixes: QTBUG-90553
Pick-to: 6.0 5.15
Change-Id: I84b4b14f9892ff687918cd3c42c7c9807e45313c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Introduction of QObjectCompatProperty requires every write to
the property to be examined whether it is OK or should be replaced
by a setValueBypassingBindings/markDirty combination. The existence
of operator= make this difficult as it is easy to miss places where
it is written. By not having operator=, we can help developers
make sure they had a conscious decision about each write to the
property.
Change-Id: Ia61ea4722eb0bab26ce7684b85dd03d710cd1751
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This reverts commit 8f8405e046.
Reason for revert: Appears not entirely thread-safe and caused QTBUG-90705
Change-Id: I390c0b1a555a18e6a095b52010371d017071e26b
Fixes: QTBUG-90705
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
This is in line with QML where
import QtQuick 2.15
Rectangle {
width: 100
height: 100
color: "red"
Rectangle {
id: inner
x: 10
y: x
width: 50
height: 50
onYChanged: { console.log("hey"); inner.x = 10}
TapHandler {
onTapped: inner.x = 20
}
}
}
results in a binding loop warning when the tap handler triggers. While
the change handler would only run once, we cannot statically determine
if we need to loop once, twice, or if there actually is a diverging
loop. Thus we unconditionally warn about the binding loop and stop
executing the binding.
As a drive-by, verify in the related test that a change handler which
overwrites its properties binding itself removes the binding.
Change-Id: I5372019c2389ab724c49cd7489ecbd3ebced1c69
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
