It's by far the most common use, so having to call two things is just
cumbersome.
Change-Id: I79e700614d034281bf55fffd178f454c4e31929e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The test that needs this bool is using 2013, so test that year for a
match. (Africa/Tunis toyed with DST in 1990, the year used before, but
thought better of it.) In the process, move the initialization to the
member-initialization of the class and make the member const.
Change-Id: Ib87636cdb0b038fad0cdef9fbe49e96f7bf79d1f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This reverts commit 6a93ec2435.
Reason for revert: Breaks qtdeclarative build, submodules need
to be clean before we deprecate or remove APIs.
Change-Id: Id0726b9bfad6072065b380b44b6ff6dffda79e45
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
These special member functions have no purpose.
We never *documented* their semantics. Any code using them is
unconditionally wrong (which semantics was it assuming?), so we can
accept the SIC (type A). If a user needs such a copy, they would have to
reason on the intended semantics (relaxed? acquire/release?) and be
explicit in their code. Especially for assignment, they would need
understand the consequences of the memory ordering that apply on _each_
atomic object involved and not on the assignment operation as a whole
(there are no such semantics).
Testing this change on qtbase has already found bugs.
From a purely technical point of view: we don't guarantee lock-free
atomics nor we require them from the underlying platform. An atomic is
therefore allowed to be implemented as a mutex protecting a value, and
mutexes are not copiable. std::atomic follows the exactly same pattern
(not copiable nor copy-assignable) for exactly the same reasons, and Qt
atomics are implemented on top of std:: ones.
[ChangeLog][QtCore] The copy constructor and assignment operators of
Qt atomic classes (QAtomicInteger, QAtomicPointer) have been removed.
Their usage in user code should be considered a programming error, as no
memory ordering semantics were ever documented for these operations (and
therefore relying on any specific semantic would be relying on
undocumented, unportable behavior). This matches the API of the
std::atomic class in C++. Note that you can still use explicit
load/store operations to transfer a value across two Qt atomic objects,
and therefore use the memory ordering specified for the load/store
operations.
Change-Id: Iab653bad761afb8b3e3b6a967ece7b28713aa944
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Then we can easily test how fromLocal8Bit() and toLocal8Bit() behave
with different code-pages.
Pick-to: 6.6 6.5
Task-number: QTBUG-118318
Task-number: QTBUG-118185
Task-number: QTBUG-105105
Change-Id: Ib1cd3bccd27d598f4c80915557e332befcd96354
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove qt_poll_msecs() since the "forever" state can be simply expressed
with a QDeadlineTimer::Forever arg, instead of passing a nullptr
timespec, and the negative timeouts treated as "run forever" is also
encapsulated by QDealineTimer.
Use the QDealineTimer(qint64) constructor in the call sites where
the timeout could be negative, so that it creates a Forever timer (the
QDeadlineTimer(chrono::duration) constructor uses
setRemainingTime(duration) which handles negative timeouts by creating
expired timers).
Remove qt_gettime() (and do_gettime()).
Drive-by changes:
- Fix a narrowing conversion warning, qt_make_pollfd() takes an int
- Remove an unused include
Change-Id: I096319af5e191e28c3d39295fb1aafe9d69841e6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When the array type is QJniObject or a subclass, then we need to
explicitly release the local reference returned by GetObjectArrayElement
in the QJniArray::at implementation. Do this by constructing the
QJniObject via fromLocalRef, which does exactly that.
Amends 80d4d55e25.
Add a test case that stresses the local reference pool, and fix the old
test case (which operates on a QJniArray<jobject>) to also release the
local references.
Change-Id: Ie293b1db9f1b6825376bbf12338b22dfc3f8c6e9
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The format is changed from 6.7 to support more than UINT32_MAX - 1
elements. The format used to have a quint32 size. Now if the size is
larger or equal to 0xfffffffe (2^32 -2) the old size is an extend
value 0xfffffffe followed by one quint64 with the actual value. The
32 bit size with all bits set is still used as null value.
Fixes: QTBUG-105034
Change-Id: I62188be170fe779022ad58ab84a54b1eaf46e5d9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QStringList] Added lastIndexOf() overloads that take
a QString/QStringView/QLatin1StringView and a Qt::CaseSenitivity
parameters. Prior to this calling lastIndexOf() would call the methods
inherited from the base class. This change is source compatible and
existing code should continue to work.
Task-number: QTBUG-116918
Change-Id: Ia50c884c00021bf581c23c12e0e0c22700dae446
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QStringList] Added filter(QLatin1StringView)
overload, which is more optimized when searching for a Latin-1 string
literal as no conversion to QString is necessary.
Task-number: QTBUG-116918
Change-Id: Ieb92f4cfd545b070258dbc5c701ddfb2e6f3fc64
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QStringList] Added indexOf() overloads that take
QString/QStringView/QLatin1StringView, and a Qt::CaseSensitivity
parameter. Prior to this using QStringList::indexOf() called the methods
inherited from the base class.
Task-number: QTBUG-116918
Change-Id: Ibc42130b6509f6ecfe7de0d6be378f226ae61982
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Now that users can pass a QStringMatcher to do the matching, change the
existing overload to not use QStringMatcher.
Thanks to Giuseppe D'Angelo for the idea of passing a QStringMatcher to
filter instead of using a magic number to decide whether to use
QStringMatcher or not.
Results of running filter() and filter_stringMatcher, times are in msecs
and this was compiled with gcc -O3:
Without With QStringMatcher
list10 0.00022 0.000089
list20 0.00040 0.00014
list30 0.00058 0.00018
list40 0.000770 0.00023
list50 0.00094 0.00027
list70 0.0012 0.00037
list80 0.0014 0.00041
list100 0.0018 0.00050
list300 0.0054 0.0014
list500 0.0091 0.0023
list700 0.012 0.0032
list900 0.016 0.0041
list10000 0.17 0.045
Drive-by change: optimize tst_QStringList::populateList().
[ChangeLog][QtCore][QStringList] Added filter(const QStringMatcher &)
overload, which may be faster for large lists and/or lists with very
long strings.
[ChangeLog][Possible Performance Changes][QtCore][QStringList] Changed
the implementation of filter(QStringView) overload to not use
QStringMatcher by default. Using QStringMatcher adds overhead, so it is
beneficial/faster when searching for a pattern in large lists and/or
lists with long strings, otherwise using plain string comparison is
faster. If using QStringMatcher makes a difference in your code, you can
use the newly added filter(QStringMatcher) overload.
Change-Id: I7bb1262706d673f0ce0d9b7699f03c995ce28677
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of the previous realpath() comparison resulting from the symlink
processing. parseMountInfo() was extracting the device number from
/proc, so this information was already readily available.
We must take care of anonymous block devices (major == 0). Certain
filesystems, such as btrfs, always use them, so we must still stat() the
device path to get the real block device.
This implementation assumes that udev only creates entries in the
/dev/disks/by-label directory that are symlinks to real devices, but
that must already be the case because they are in /dev in the first
place. An alternative implementation would be to compare the inode and
host device (st_dev) of the entry, if different /dev entries could have
different labels. I don't think that's possible. But multiple /dev
entries for the same device is definitely possible.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd1787552af3d09676
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Otherwise we have no way of knowing which QStorageInfo entry was being
tested.
Previous:
FAIL! : tst_QStorageInfo::storageList() 'other.isValid()' returned FALSE. ()
Now:
FAIL! : tst_QStorageInfo::storageList(/run/user/0/gvfs) 'other.isValid()' returned FALSE. ()
Change-Id: I8f3ce163ccc5408cac39fffd178d786e596ece81
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The existing pattern() method always returns a QString, which means that
if the matcher was constructed using a QStringView, pattern() would
uncoditionally convert it to a QString.
This is useful to check if a match is exact:
auto pattern = matcher.patternView();
if (pattern.size() == needle.size() && matcher.indexIn(needle) == 0)
....
This may be needed for a later change in QStringList::contains();
regardless of that, this change makes sense on its own.
Change-Id: I49018551dd22a8f88cf6b9f878a5166902a26f58
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For those that simply repeat or skip a whole calendar day, life is
fairly simple. However, Alaska's 24-hour transition at 15:30 LMT Sitka
(incidentally combined with a change of calendar) is a bit trickier.
Also fix a typo I noticed in passing.
Write tests to determine what the actual behavior is and document
enough to make the actual behavior seem unsurprising once encountered,
without trying to go into all the excruciating details. Naturally, MS
time-zone data lacks the data on the historic transitions involved in
these tests, so MS (when not using ICU's time-zone data) is excluded.
It seems Cupertino believes Alaska was always in the USA, too.
Change-Id: Ia638c04d2ffc3a956a70a2a85badb7bbfdbb791c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously, requesting a time that got repeated - on the given date,
due to a fall-back transition - would get one of the two repeats,
giving the caller (no hint that there was a choice and) no way to
select the other. Add a flags parameter that captures the available
ways to resolve such ambiguity or select a suitable time near a gap.
Add such a parameter to relevant QDateTime methods, including
constructors, to enable callers to indicate their preference in the
same way. This replaces DST-hint parameters in various internal
functions, including QTimeZonePrivate's dataForLocalTime(). Adapted
tst_QDateTime to test the new feature.
Adapt to gap-times no longer being invalid (by default; or, when they
are, no longer having a useful toMSecsSinceEpoch() value). Instead,
they don't match what was asked for. Amend documentation to reflect
that. Most of the code change for this is to QDTParser and QDTEdit.
[ChangeLog][QtCore][QDateTime] Added a TransitionResolution parameter
to various QDateTime methods to enable the caller to indicate, when
the indicated datetime falls in a time-zone transition, which side of
the transition to fall or whether to produce an invalid result.
[ChangeLog][QtCore][Possibly Significant Behavior Change] When
QDateTime is instantiated for a combination of date and time that was
skipped, by local time or a time-zone, for example during a
spring-forward DST transition, the result is no longer marked invalid.
Whether the selected nearby date-time is before or after the skipped
interval may have changed on some platforms; unless overridden by an
explicit TransitionResolution, it is now a date-time as long after the
previous day's noon as a naive reading of the requested date and time
would expect. This was the prior behavior at least on Linux.
Fixes: QTBUG-79923
Change-Id: I11d5339abef9e7125c4e0dc95a09a7cd4f169dab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... adding a bit of test coverage of keysToValue().
This is not intended as a reproducer for QTBUG-118240, because that
is concerned with inputs valueToKeys() cannot produce.
Task-number: QTBUG-118240
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I5d772be4231717cdbb5d033b1f11ae31e4c57c0b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The comment in this function made it clear that it really depended on
the size of the pipe buffer in the OS. I don't see a way to make a pipe
default to a different size on Linux -- it always defaults to
PIPE_DEF_BUFFERS (16) and that value is only increased as a result of
fcntl(F_SETPIPE_SZ), which we don't do. But we can be defensive and
simply write until the OS can't take any more data.
Drive-by update the comment on Windows to be clear that bytesToWrite()
does work, but only while the child process is still running.
Pick-to: 6.6
Task-number: QTBUG-80953
Change-Id: I9d43e5b91eb142d6945cfffd17866d22a4127e5e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Amends commit 78d0b6e975 ("Ignore failing
test for free space on APFS") and merges it with the btrfs code, which
seems to have the same problem. But unlike Linux systems with btrfs,
Apple systems don't usually have another filesystem available so we
don't bother to try and find another.
Change-Id: I8f3ce163ccc5408cac39fffd178d7b4c13f0dfd1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
These tests skip when we're writing to a btrfs filesystem because, for
some reason, the amount of free space does not update synchronously with
file writing. But instead of giving up if $TMPDIR is a btrfs, let's try
and use the $XDG_RUNTIME_DIR, which is usually a tmpfs.
This will work in the CI for the openSUSE set ups, where / is btrfs,
/tmp is not a separate tmpfs, but /run/user/1000 is available.
FAIL! : tst_QStorageInfo::tempFile() The computed value is expected to be different from the baseline, but is not
Computed (free) : 25510780928
Baseline (storage2.bytesFree()): 25510780928
Loc: [tst_qstorageinfo.cpp(234)]
Pick-to: 6.6
Change-Id: I8f3ce163ccc5408cac39fffd178d7af1c67ec988
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Almost all operations on a QJniObject require a QJniEnvironment,
including the construction and destruction of a QJniObject. Instead of
instantiating a temporary QJniEnvironment object in each call, store the
one from the constructor in the private, and reuse it.
Pass the stored environment through to other functions needing it, and
add a checkAndClearExceptions() wrapper.
Static class members still need their own QJniEnvironment, but we can
reuse the one we have to get both jclass and jmethodID rather than
creating new QJniEnvironments in several wrappers.
As a drive-by, clean up nullptr usage in the test that failed when
shortcutting isSameObject for the trivial cases.
Change-Id: Ibadbd2be8a0ec9ab62daf285608ee7fe0a3c8852
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Our signature mapping treats both e.g. bool and jboolean as "Z", and it
is allowed to pass a bool variable as an argument to a function expecting
a jboolean. Except for fields and callMethod return values, where we only
allowed the JNI primitive types.
Fix this by comparing the signatures and size of the type we have with
the JNI types that there are explicit functions for. Cast from and to
the JNI type in both directions to address narrowing (e.g. jboolean is an
unsigned char and converting to bool would be narrowing, even though
both are 8bit types).
This way we can get boolean fields using getField<bool>, and int fields
using getField<int> etc.
Change-Id: I2f1ba855ee01423e79ba999dfb9d86f4b98b1402
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
So we can more easily get any errors from attempting to write the file.
It is possible to get them with QFile, by either doing .flush() or using
QIODevice::Unbuffered, but using the C API is a definite sure way. Plus,
since this is QFileSystemEngine, this avoids the possibility that QFile
may choose to use a different file engine than the native one, for some
reason. And it reduces overhead.
This allows us to more easily detect why the file creation failed and
therefore stop looping if the error wasn't EEXIST. That will avoid an
infinite loop in case the necessary directories exist but aren't
writable.
It's also moved above the renaming, such that the failure to populate
the info file prevents the renaming too. Both operations can have the
same likely errors, ENOSPC and EIO. The likelihood of EIO is very low,
for both; but for ENOSPC it's far more likely for writing the
file. Avoiding the ENOSPC error for the renaming is handled in a later
commit.
Change-Id: I9d43e5b91eb142d6945cfffd1786d417142ac728
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Implements an iterator API and other standard member access functions
for sequential containers so that we can use ranged-for over an object
that is a jarray. Provides read-only access to individual elements
(which is mostly relevant for arrays of objects), or the entire data()
as a contiguous memory block (which is useful for arrays of primitive
types).
QJniObject call functions can return QJniArray<T> when the return type
is either explicitly QJniArray<T> or T[], or their Qt equivalent (e.g.
a jbyteArray can be taken or returned as a QByteArray). If the return
type is a jarray type, then a QJniObject is returned as before.
Arrays can be created from a Qt container through a constructor or the
generic fromData named constructor in the QJniArrayBase class, which
implements the generic logic.
Not documented as public API yet.
Added a compile-time test to verify that types are mapped correctly.
The function test coverage is added to the QJniObject auto-test, as
that already provides the Java test class with functions taking and
returning arrays of different types.
Change-Id: I0750fc4f4cce7314df3b10e122eafbcfd68297b6
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
These must pass, but they're highly unlikely to be trashable because
/var/tmp is usually not its own filesystem (it might be a subvolume of
its own, but usually isn't). Instead, it's usually part of / or /var.
On my machine:
openat(AT_FDCWD, "/var/.Trash", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/.Trash-1000", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
mkdirat(AT_FDCWD, "/var/.Trash-1000", 0700) = -1 EACCES (Permission denied)
Change-Id: Ifeb6206a9fa04424964bfffd17884246a4d27443
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Both QTemporaryFile and QTemporaryDir are documented to use the current
directory if given a pattern. That can be anything & arbitrary, so it
doesn't give us consistency in checking. Moreover, it might be a read-
only directory.
Drive-by fix the number of 'X'.
Task-number: QTBUG-117449
Pick-to: 6.6
Change-Id: Ifeb6206a9fa04424964bfffd178841c44e9636a0
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
QtTest can't handle a test that does both. This ends up recorded as a
skip in the summary.
Pick-to: 6.6
Change-Id: Ifeb6206a9fa04424964bfffd1788412a438085b0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This base class implementation for COM objects provides IUnknown
interface implementation with reference counting which will allow to
keep all this functionality and implementation in the same place.
Pick-to 6.6 6.5
Change-Id: I8ec597b1040ac33295317e06338ffdcb61b78f85
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It was weird that they were missing. Now that C++23 added them to
std::span, add them to QSpan, too.
Pick-to: 6.6
Change-Id: I4a9b1fdeda66bc7b133c8f7b3b269656e5faffa3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This changes takes Qt for Android Java code away from the Delegate
classes that uses heavily Java reflection to invoke Activity/Service
calls and overrides. So instead of that, now, we have a QtActivityBase
and a QtServiceBase classes which handle the override logic needed for
Qt directly without reflection.
These Base classes extend Android's Activity and Service directly, and
are inside the internal Qt android package (under Qt6Android.jar).
For example, to handle onConfigurationChanged, instead of the current
way where we need this in QtActivityDelegate:
public void onConfigurationChanged(Configuration configuration)
{
try {
m_super_onConfigurationChanged.invoke(m_activity, configuration);
} catch (Exception e) {
e.printStackTrace();
}
handleUiModeChange(configuration.uiMode &
Configuration.UI_MODE_NIGHT_MASK);
}
And then this in QtActivity:
@Override
public void onConfigurationChanged(Configuration newConfig)
{
if (!QtLoader.invokeDelegate(newConfig).invoked)
super.onConfigurationChanged(newConfig);
}
public void super_onConfigurationChanged(Configuration newConfig)
{
super.onConfigurationChanged(newConfig);
}
And having to keep it's Method handles around and then use Java
reflection
to call the override behavior done by Qt and the superclass methods.
instead of that, we can do it now in QtActivityBase like:
@Override
public void onConfigurationChanged(Configuration newConfig)
{
super.onConfigurationChanged(newConfig);
handleUiModeChange(newConfig.uiMode &
Configuration.UI_MODE_NIGHT_MASK);
}
Then, we would still have our user facing QtActivity class which extends
QtActivityBase and benefit from the same implementation of Qt logic done
in the base class.
An additional benefit to this approach is that now QtActivity will be
very lightweight and doesn't need to have all the boilerplate code as
before.
[ChangeLog][Android] Simplify Qt for Android public bindings
(QActivity, QtService and QtApplication) by implementing base
classes which use the delegate implementions directly and avoid
reflection.
Task-number: QTBUG-115014
Task-number: QTBUG-114593
Change-Id: Ie1eca74f989627be4468786a27e30b16209fc521
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
It noted that an unspecified function claimed the offset it was
checking should be +1, while testing it against that or -1. The
function turns out to be QDateTime::addDays(), whose doc did indeed,
misleadingly, say that it lands after a gap it would have hit. It in
fact overshoots the gap in the direction of its change. Amend its
docs, likewise those of addMonths() and addYears(), to reflect the
true behavior.
Amend the test to look at the direction of the step its taking and
anticipate that the adjustment will be in the same direction; then
compare the actual adjustment to that.
Change-Id: I9ab918fac0ab2195ef014983f37fccc435bf0498
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The implementation previously worked for non-short date-times, where
the offset has been remembered since construction. This included the
case of zoned times (and local times more than 2^55 msec away from the
start of 1970) that hit a spring-forward's gap; but excluded local
times that did the same (within 2^55 msec of the epoch).
This precluded an offset check in a spring-forward test, now added.
We can in fact determine the offset whenever we got a valid date and
time (we do so in the course of initializing the object, and when
asked for toMSecsSinceEpoch(), even when invalid), and we should not
use the value of the recorded offset if we didn't get a valid date and
time, so amend to always return 0 if we didn't get valid date and time
and always report the correct offset otherwise.
In the process, amend offsetFromUtc()'s computation to directly
resolve the date-time, rather than doing so via toMSecsSinceEpoch(),
which has to repeat decision-making offsetFromUtc() has already done
by the time it calls it. Also amend toMSecsSinceEpoch() to return 0 if
we didn't have a valid date and time to begin with, so it only
attempts to produce a useful result in the case where construction
attempted to resolve the date-time.
Change-Id: I6574e362275ccc4fbd8de6f0fa875d2e50f3bffe
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The resolution selects a point in time outside the gap, which will be
represented by toMSecsSinceEpoch()'s return, despite the QDT object's
isValid() returning false. Previously we retained the
originally-calculated msecs, so as to keep date() and time() matching
what was asked for. However, this required adjusting offset, which was
not remembered for local times within 2^55 milliseconds of the start
of 1970. This lead to an inconsistency between the offset from UTC
reported for the resolution for a local time further from the epoch,
or for a time-zone, and the actual offset from UTC at the time
indicated by the return from toMSecsSinceEpoch().
Instead, retain the actually calculated offset (even if we aren't
going to remember it) and adjust the msecs to the value that ensures
toMSecsSinceEpoch() will get the selected resolution. This
incidentally means that, when toMSecsSinceEpoch() has to re-resolve
(for a local time within 2^55 msecs of the epoch), it avoids
revisiting the complications of hitting the gap.
In passing, change internal stateAtMillis() to take the QTimeZone it
is passed by const reference, to save a copy (noticed during debug).
Also tweak a comment in a test to be explicit about a default value.
[ChangeLog][QtCore][Possibly Significant Behavior Change] When
QDateTime is instantiated for a combination of date and time that was
skipped, by local time or a time-zone, for example during a
spring-forward DST transition, the invalid result's time() - and, in
rare cases, date() - no longer match what was asked for. Instead,
these values and offsetFromUtc() now match the point in time
identified by toMSecsSinceEpoch().
Change-Id: Id61c4274b365750f56442a4a598be5c14cfca689
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Since it hides QFile's overloads this was not supported for
QTemporaryFile.
[ChangeLog][QtCore][QTemporaryFile] Added support for passing
std::filesystem::path to rename and createNativeFile.
Change-Id: I909ff1d5b9c586824c9901d7dad278dfad09ffc3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Added moveToTrashDuplicateName() to see what happens if you attempt to
trash two files with the same exact full path. Both files should get
independently moved to the trash bin and not clobber each other.
Added moveToTrashXdgSafety() to test that QFileSystemEngine will
properly skip over an unsafe $root/.Trash directory, as required by the
XDG specification. I think the specification should also make security
requirements on $root/.Trash-$uid too, but that's for another change.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd1786cd60e4244c7c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
qnativesocketengine_win.cpp: don't check if timeout is < 0, because
remainingTimeAsDuration() doesn't return negative values.
All the changes done in one go, not function by function, as that causes
the least churn. You can think of them as a couple of very similar
changes repeated various times.
Drive-by change: replace `forever {` with `for (;;)`
Task-number: QTBUG-113518
Change-Id: Ie9f20031bf0d4ff19e5b2da5034822ba61f9cbc3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Construction from nullptr wasn't, before, because it was using the
QPointer(T*) constructor, which cannot be constexpr. Add a constexpr
QPointer(std::nullptr_t) constructor to enable this use-case.
This requires to mark the (T*) constructor as Q_WEAK_OVERLOAD,
otherwise legacy construction from a literal 0 would be ambiguous.
No documentation changes needed, as the set of valid expressions
(apart from constinit'ing) has not changed. Mention the nullptr ctor,
though, without \since.
Add a test to confirm that contruction from derived still works.
Change-Id: If9d5281f6eca0c408a69f03fecba64a70a0c9cf0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Ignore expected warning messages when looking up classes, methods, or
field that don't exist. Make the test implicitly fail for any other
warning messages.
Change-Id: I79ec799102b1ab9424aa39c5255413931b8ad152
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
In non-static builds, of course.
Change-Id: Ifbf974a4d10745b099b1fffd1777ac97c0921759
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Construction from nullptr isn't, because it's using the QPointer(T*)
constructor, which cannot be constexpr.
Pick-to: 6.6 6.5
Change-Id: I19129a0fca5873e83d20351a909a7994399bfcce
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- Initialize QStringList with an initializer_list instead of old style
operator <<()
- Use Qt::StringLiterals more, better readability
- Test CaseSensitivity
Change-Id: If7dde14333d54b8c2f682036634ad94d5f9f9c74
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The jbyte type is a signed char, which also promotes to int in variadic
argument functions.
Extend the test case to make sure that we don't get any warnings for
the most relevant parameter types.
Change-Id: I7811e1eebdbc989ab5989eb1a2c502acd0540bc7
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
Implement the missing overload to handle UTF-8 specific data types,
including char8_t (C++20), char, uchar and signed char.
Introduce the helper function 'assign_helper_char8' which handles the
non-contiguous_iterator case. The contiguous_iterator case is already
handled by the QAnyStringView overload.
Include 'qstringconverter.h' at the end of the file, since it can't
be included at the top due to diamond dependency conflicts.
QStringDecoder is an implementation detail we don't want users to
depend on when using assign(it, it). It would be unnatural to not
be able to use a function just because we didn't include an
apparently unrelated header.
[ChangeLog][QtCore][QString] Enabled assign() for UTF-8 data types.
Fixes: QTBUG-114208
Change-Id: Ia39bbb70ca105a6bbf1a131b2533f29a919ff66d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
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>
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>
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>
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>
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>
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>
By first checking if the list has any matches before potentially making
it detach.
Change-Id: I7a42c2910ef6efc45033e562573414a3a9ef972e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
91dcc76fc1 might have fixed the underlying issue, so we no longer
need the XFAIL codepath at all.
Fixes: QTBUG-114720
Change-Id: I67ccbed67a0536b679c50c26eb0b3e51c93dceeb
Pick-to: 6.6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Because the local `seed` variable shadowed the member one, this test
was run for each QFETCH_GLOBAL with the same data and seed. That
doesn't make sense, so make the test use the member variable `seed`,
as all other tests already do.
Since zero is one of the seeds coming from QFETCH_GLOBAL, drop the
seedless calls to qHash(), too.
Amends 64bfc927b0.
Pick-to: 6.6 6.5 6.2
Change-Id: I1e22ec0b38341264bcf2d5c26146cbbcab6e0749
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The old code only tested with seed = 0 and seed = 1045982819, the
latter being a "random number", which, however, fits into
32-bits. Since Qt 6.0 increased the seed from uint to size_t, amend
the test to actually test a seed value with some of the upper half of
bits set, too, also in 64-bit mode.
While we're at it, also test with each seed's bits flipped for extra
coverage.
Remove a static assertion that prevented testing seeds with the MSB
set.
Pick-to: 6.6 6.5 6.2
Change-Id: I5ed6ffb5cabaaead0eb9c01f994d15dcbc622509
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This commit reverts 2d77051f9d.
When requesting an allocation of size 0, we will actually get
a nullptr.
qarraydata.cpp:
~~~
if (capacity == 0) {
*dptr = nullptr;
return nullptr;
}
This will let the Q_CHECK_PTR trigger falsely. Such an occurrence was
initially detected during the cmake_automoc_parser build-step.
Found-by: Marc Mutz <marc.mutz@qt.io>
Task-number: QTBUG-106196
Pick-to: 6.6
Change-Id: Icb68c5dd518c9623119a61d5c4fdcff43dc4ac5d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QStaticLatin1StringMatcher is a static templated Latin-1 Boyer-Moore
string matcher which can be case sensitive or not. It should be used
when the needle is known at compile time so there is no run-time
overhead when generating the skip table.
The convenience functions qMakeStaticCaseSensitiveLatin1StringMatcher
and qMakeStaticCaseInsensitiveLatin1StringMatcher should be used to
construct the matcher objects.
Green Hills Optimizing Compilers are currently not supported.
[ChangeLog][QtCore] Added QStaticLatin1StringMatcher, which can be used
to create a static constexpr string matcher for Latin-1 content.
Task-number: QTBUG-100236
Change-Id: I8b8eed1e88e152f29cbf8d36d83e410fafc5ca2c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The latest XDG spec (0.8) defines XDG_STATE_HOME that does not exist
in QStandardPaths::StandardLocation.
Some Linux distributions clean XDG_CACHE_HOME on restart which makes
XDG_STATE_HOME useful as a path for saving application state.
This commit adds StateLocation and GenericStateLocation to serve as a
StandardLocation for XDG_STATE_HOME for all platforms.
This commit also updates docs and tests to fit the new changes.
[ChangeLog][QStandardPaths] Added StateLocation &
GenericStateLocation to StandardLocation
Change-Id: I470602466c37f085062cc64d15ea243711728fa5
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>