This is purely cosmetic, to avoid confusion when reading the logs and
find many "FAIL!" strings all over the place. The ASAN testrun only
cares for "ERROR: AddressSanitizer" type errors, and tests pass even
if they print "FAIL!" (that is taken care by sanitizer-testrunner.py).
Fixes: QTQAINFRA-5896
Pick-to: 6.6 6.5
Change-Id: Ib7a5fb2c3ee56581db20efb4dd7cf24a053d5c13
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
While a minor issue, it's possible to use them in a way requiring
a definition, triggering a linker error. We can either make them
inline or constexpr.
Pick-to: 6.6 6.5
Fixes: QTBUG-118170
Change-Id: Ia3dede91b989b295c3e792691d534648581a27c2
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Calling std::mutex::try_lock() when the mutex is already owned by
the thread casuses undefined behavior.
Change-Id: I024ced271cad8a034bebf80b48e31e7e7461c560
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
[ChangeLog][Android][Deployment Changes] Now the auxillary mode
of androiddeployqt also copies the templates and the stdcpp lib
file without building the APK.
Fixes: QTBUG-115241
Change-Id: I3d4647277e7f62f079c683645443462ef8026948
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
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>
It's only called in exceptional circumstances, so the compiler should
optimize it for size, not speed, and paths leading up to calls to this
functions should be automatically marked as [[unlikely]].
Marking the function as cold accomplishes both.
GCC 11 seems to have had this figured out by itself, possibly
backtracking from the unconditional qWarning() in the first line of
the function, but it did have a (very small) effect on Clang 15, so
leave it in, if only as documentation.
Pick-to: 6.6 6.5 6.2
Change-Id: Ie8e9049300825a3aae2f9678a2907ceea0b21d1c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QPalette specifically has quite a large amount of output (1363
characters) when toString
is called on it. We should make sure that we can fit that in our
failure messages. This patch does that by increasing the limit from
1024 characters to 4096.
Fixes: QTBUG-5903
Fixes: QTBUG-87039
Pick-to: 6.5 6.6
Change-Id: I1dc5078ad05858bb6542c3a06c6b84711af79e4f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
Drive-by change, initialize a QList with std::initializer list instead
of old style operator()<<.
Change-Id: If5745a4554772661df438e757518f8cb55a8a55c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We will use it without holding an instance later. And there's
no reason it is not static already.
Change-Id: I06d455bb2852244c8a4993ea75ceda4e1cb679fb
Reviewed-by: Edward Welbourne <edward.welbourne@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>
Previously, it was left to the caller to guess.
Change-Id: Icc22b8c874046de78e16253cf0cc3ba2f334362b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Pick-to: 6.5 6.6
Change-Id: I8753b8793c744d4fe2cae8d7293abf6961c60601
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The tooltip text doesn't show with right palette when application runs
in dark mode using gtk3 theme.
This patchset removes explicitly setting ToolTipText palette in
gtk3theme.
Pick-to: 6.6 6.5
Change-Id: Id90626a377733814c3f32f0bf7e5539097b76dd6
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
QNetworkAccessManager may fail to finish with Windows apps that are
running with low integrity level sandboxing.
The root cause is that such applications are not allowed to open ROOT
system certificate store with write privileges. This causes the
CertOpenSystemStore helper function to fail, because it attempts to open
certificate stores with the option of adding or deleting certificates.
We only use the CertOpenSystemStore with the intent of fetching
certificates from the certificate store, so we do not need write access.
The fix for this issue is threfor to open the system certificate store
as read-only by using the lower-level CertOpenStore function.
The CERT_SYSTEM_STORE_CURRENT_USER flag is provided to CertOpenStore to
keep the documented behavior of CertOpenSystemStore, which states "Only
current user certificates are accessible using this method, not the
local machine store."
Fixes: QTBUG-118192
Pick-to: 6.5 6.6
Change-Id: I529b760398f84137a0e95c8088a71b293d302b54
Reviewed-by: Fredrik Orderud <forderud@gmail.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Documentation for the other functions refer to seat(), but that itself
isn't documented
Pick-to: 6.6
Change-Id: I9a628e87153b687b2fa444798de1af74e6251eee
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
To allow building and developing from Android Studio and get rid of
warnings.
Change-Id: I5f896a270917120f98eefd2f4aa449714451f994
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
This check for error code is never reached, the error code is
always set to 0 in startApp() and then check for in loadApplication()
while the latter method is only called by
startApp().
Task-number: QTBUG-114593
Task-number: QTBUG-115016
Change-Id: I762009d76567cc1d090fe29048c35220d433dd1d
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
The variable m_optionsMenuIsVisible is assigned but never
used.
Task-number: QTBUG-114593
Change-Id: Ie4b61b37f2bc05d8d2a348dcad7487eb8fa1ac00
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Clean the long lines on the code, extract into smaller methods where
appropriate, and some small naming or logic clarifications. Some of the
deeper code might use some simplification but that's for another patch
with better debugging to avoid potential regressions.
Task-number: QTBUG-118077
Task-number: QTBUG-114593
Change-Id: I8964b87727819b4846c51f5fa5febfa8caae4f8d
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
To further simplify the code and logic of the delegate, move keyboard
input code to separate class. Make an input delegate available under the
QtActivityDelegate to allow classes like QtNative and the Activity to
access that. For now, it's okay to leave access from QtNative to that,
but for future even that should be simplified and the Activity should be
accessing that directly.
For the case where the QtInputDelegate needs access to
QtActivityDelegate, for now namely updateFullScreen(), a new Listener
is implemented to be implemented under QtActivityDelegate.
Along the way use newer JNI APIs under C++ QtAndroidInput.
Don't make them static methods, so that it can be possible later to
do various keyboard operations to specific activity and not a global
one.
Task-number: QTBUG-114593
Task-number: QTBUG-118077
Change-Id: I110b897f6f16d0ae5f5a645551b4a82e8ad3f2fb
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
If a QJniObject method that uses the stored JNIEnv pointer is called
from a different thread than the one the object was created in, then a
FATAL abort of the JNI runtime is likely, but hard to debug (the error
messages from JNI are visible in the logcat log of adb).
In debug mode, compare the stored JNIEnv pointer with the one provided
for the current thread, and emit a critical runtime warning if they do
not match, as this indicates a race condition to the underlying JAVA
object.
Change-Id: Ief578f445bcfab1939ddbe95c6ba796279be9115
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@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>
While we can probably deprecate this function, with the change of
Q_DECLARE_JNI_CLASS'ed types to be QJniObjects we need to correctly
translate from e.g. jobject to QJniObject.
Amends 62cb5589b3.
Change-Id: Id3c23fc0724e2eff895029b694d418481abcb8e6
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Since QWasmIDBSettingsPrivate is only supported on JSPI now, there is
no need to maintain the isReadReady flag anymore. This lets us simplify
the class a lot.
Change-Id: I67322389463af13b5110091a4f8433f08da19925
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The header uses QPointer in-name-only, so it doesn't need to include
the class' header file. A forward-declaration suffices.
[ChangeLog][Potentially Source-Incompatible Changes] The headers
qevent.h and qfuture.h no longer include the header qpointer.h.
Change-Id: I8d3c3b56f5928a0745a523abf5df3b8106dc15ee
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Change the heuristic only to use the stored compiler if we
are building qt itself, like with qt-cmake-private
/ qt-configure-module. qt-cmake is also used by end-users,
where the heuristic to change the compiler default base on
paths is surprising, and can go wrong.
Fixes: QTBUG-108323
Pick-to: 6.6
Change-Id: I0274e470f214a84711013d77068551f9097f4685
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
pkgconf is an alternative implementation of pkg-config, and it is mostly
compatible with pkg-config, but in the case of HarfBuzz, it adds the
`/usr/local/include` to `INTERFACE_INCLUDE_DIRECTORIES` when reports the
include path, and if the path doesn't exist, the configuration fails.
In the case of HarfBuzz, we do some extra work to make sure that we can
always find the library, so, with a bit of modification, we can skip the
faulty pkgconf intervention and create the correct imported target.
Fixes: QTBUG-117905
Change-Id: Id628e4434633534b0d7bfad9e819a8c05da4944d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Simplify addIconFiles() by passing an initializer list instead an
c-array + size
Task-number: QTBUG-118122
Change-Id: Id54bbe8436a9106e59b6fede81e31c3065623b4d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Dont't checks before call QCursorData::initialize().
The inside of QCursorData::initialize() already checks initialized.
Change-Id: I4b34218132df9decf7d04dcc31e873daf300ffe6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
Instead of a sequential and thus predictable counter. This improves the
performance of when you keep creating and trashing the same file base
name. The previous algorithm would try all occurrences from 0 to however
many trashings have happened.
This could have been any random number, but the source file's inode is
"random" enough for us.
strace of the second file's trashing:
openat(AT_FDCWD, "/home/tjmaciei/.qttest/share/Trash/info/tst_qfile.moveToTrashOpenFile.vLwfNe.trashinfo", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = -1 EEXIST (File exists)
newfstatat(AT_FDCWD, "/home/tjmaciei/tst_qfile.moveToTrashOpenFile.vLwfNe", {st_mode=S_IFREG|0644, st_size=16, ...}, 0) = 0
openat(AT_FDCWD, "/home/tjmaciei/.qttest/share/Trash/info/tst_qfile.moveToTrashOpenFile.vLwfNe-23527891.trashinfo", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 4
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644, st_size=2852, ...}, 0) = 0
write(4, "[Trash Info]\nPath=/home/tjmaciei"..., 103) = 103
renameat2(AT_FDCWD, "/home/tjmaciei/tst_qfile.moveToTrashOpenFile.vLwfNe", AT_FDCWD, "/home/tjmaciei/.qttest/share/Trash/files/tst_qfile.moveToTrashOpenFile.vLwfNe-23527891", RENAME_NOREPLACE) = 0
close(4) = 0
Change-Id: I9d43e5b91eb142d6945cfffd1786d73459c2eb3d
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
QStorageInfo is great, but rather expensive, so this introduces a faster
check by stat()ing the source file and $HOME, to see if they are the
same device, saving us two or three QStorageInfo constructions. That is
a necessary condition: if they aren't the same device, we know rename()
into $HOME/.local/share/Trash will fail.
But it's not a sufficient condition: they need to be the same mount
point and that's something only QStorageInfo will give us. Strictly
speaking, the only way to be sure that you can rename() into the trash
path is to, well, attempt it (as usual, something for a later commit).
Change-Id: I9d43e5b91eb142d6945cfffd1786c474cac25083
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
This is not a security issue because we still use QIODevice::NewOnly
(O_EXCL) and loop again. But because we do so, we don't need to check
for existence with QFile::exists() in the first place.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd1786c98a39781517
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Make it receive the QSystemError so it can set the error condition
properly in case the suitable location for this input file can't be
found. This also includes the case when the input file does not exist in
the first place, which I moved into the function because upcoming
commits will imply this check anyway.
Change-Id: I9d43e5b91eb142d6945cfffd1786c6e59d3b0204
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The m_children container isn't used at all, so remove it. Spotted by
Volker Hilsheimer.
Change-Id: I79db1f77c0e4caf8ebab1573a82e07396a6a806b
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Instead, check the macro that we're about to use. This is also done in
qprocess_unix.cpp
Pick-to: 6.5 6.6
Change-Id: I8f3ce163ccc5408cac39fffd178d657b7594d07a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Extract the information about the relation between invalid and valid
datetimes into a snippet, and include it in the documentation of
every relational operator.
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I61b239647efe928eb0758cfc5649b33ab4d06c7d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We need to re-apply the application badge when the color scheme changes;
when a task bar button is being created for the fist time; or after Explorer
has crashed and re-started.
But we should only do that if the user has set an application badge
via our APIs. Otherwise we might end up clearing an existing badge
that was set via the native APIs directly.
Fixes: QTBUG-118117
Pick-to: 6.5 6.6
Change-Id: I1f1fecba44c118d4e3f7ef4119139c3ebd23f047
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
