The relevant bits are a two-line snippet.
Pick-to: 6.6 6.5
Change-Id: Id1731e5bc6585b1d1fd684817b39d19ad0a8a9cc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Detect if JSPI is available and suspend the execution of the program
if so, instead of using 'bare' asyncify.
For now:
1) This works only with emscripten 3.1.36 with mboc-qt patches from
emscripten repo
2) Apps have to specify the following linker options:
-sDYNCALLS=1
-sASYNCIFY=2
-sASYNCIFY_EXPORTS=dynCall_*
Fixes: QTBUG-113570
Change-Id: Ide7c51e36990df7e20c6c9b5a218366cb0db100e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Create the fixed string once and reuse it. Also give a name to the
escape code that's its repeated character.
Pick-to: 6.6 6.5
Task-number: QTBUG-111228
Change-Id: I3d6416070f1d5490ec137e251daff0e1637fb788
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Put readBookmark() first of the constituent parts, as it's the most
intelligible (albeit currently undocumented) and gives some clue to
the purpose of readTitle(), which is next.
Pick-to: 6.6 6.5
Task-number: QTBUG-111228
Change-Id: I91d3d6bf8adc3f3001c90274bb62a9da6bf05362
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
If the length of the quaternion was slightly larger than 1,
the resulting quaternion would be invalid, causing
getAxisAndAngle() to fail.
Fixes: QTBUG-114313
Pick-to: 6.5 6.6
Change-Id: I8f0616e74590dd6cfee0ce913d214c8e280c4df4
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Don't show a blank frame on app startup.
The wasm update request system supports two types of update
requests: Expose and UpdateRequest. It can happen that both
types of request are made for a single window, in which case
the current code prefers UpdateRequest, since those must be
delivered in order to keep QWindow in a consistent state.
However, if the window is visible but not yet exposed then
delivering the update request will not make the window paint
anything, and we end up with a blank frame.
Ideally this should be handled elsewhere and QWindow::requestUpdate()
should not be called for non-exposed windows, but in the
case does happen then sending an expose here allows us to
recover.
Pick-to: 6.5 6.6
Change-Id: Ib53050c33ad1769ea9b9ad678896af15f87a7ecb
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
IFW requires static build of Qt which does not build tests on all
configurations. This allows building modules without them building tests. Previously IFW used 5.15 repos, those build tests in test workitem, not running into the issue.
This is only relevant if the tested repo i.e IFW implements it's own
test instructions.
Pick-to: 6.6 6.5 6.2
Change-Id: I1e03f3b577d7be314f92ed3989e5f6daf2a46da1
Reviewed-by: Toni Saario <toni.saario@qt.io>
If we wish to introduce a new color dialog option, then we might as well
use it in our example.
Change-Id: I7771d9d50e2ab0489fbeece8dea38a0b72b9b21e
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
These APIs started out as private APIs in qnumeric_p.h, but have since
been made pseudo-public in qnumeric.h. The qnumeric_p.h versions just
forward to the qnumeric.h ones, so just use the latter.
This is in preparation of removing the {add,sub,mul}_overflow
versions, which, despite being defined in the unnamed namespace, don't
sport the q prefix, so potentially clash with global symbols.
The change is a simple textual search and replace, manually excluding
qnumeric_p.h.
Picking to 6.5 to avoid cherry-pick conflicts going forward.
Pick-to: 6.6 6.5
Change-Id: Ic0f7c92f7c47923317109e8a9dc06fa66bdff2c2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If we have a rvalue reference to an unshared QVariant, we can avoid
potentially expensive copies, and use move semantics instead.
[ChangeLog][QtCore][QVariant] Added rvalue QVariant overloads of qvariant_cast<T>() and QVariant::value<T>().
[ChangeLog][Potentially Source-Incompatible Changes][QVariant] It is no
longer possible to take the address of a specialization of
qvariant_cast; consider using a lambda function instead.
Change-Id: Ifc74991eadcc31387b755c45484224a3200bb0ba
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Deduplicate it in the process by moving to qstringalgorithms.h.
In non-constexpr contexts, both GCC and Clang were giving up in
pre-calculating the length if the UTF-16 string literal was too big. For
the old code, that was 14 and 16 characters respectively. That number
can be raised by adding some Q_ALWAYS_INLINE and (for GCC's case),
replacing std::char_traits::find() with std::find(). If that limit is
exceeded, we call the newly introduced qustrnlen() function.
qustrnlen() is just qustrchr(), like qstrnlen() is just memchr(). But it
is introduced as a separate function so we could change implementation
if we ever wished to, plus QStringView is only forward-declared at this
point.
Change-Id: Ieab617d69f3b4b54ab30fffd175c560d926db1c3
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is not q20::is_constant_evaluated() because it does not replace
that for all compilers. Instead, it's our own version of it that may
return false even in constant contexts. However, for the majority of our
users, it will work even in C++17 mode.
Updated QStringView and QAnyStringView to use it, which are the only two
places in all of Qt that used std::is_constant_evaluated().
Change-Id: Ieab617d69f3b4b54ab30fffd175c50c517589226
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Because GCC isn't really working them out at compile time. First, for
both lengthHelperPointer(), they don't get called on string literals
such as
return QStringView(u"Hello");
because the type hasn't decayed to a pointer, but is instead a
char16_t[6]. No one writes
constexpr auto str = u"Hello";
return QStringView(str);
Second, even when you do write that, GCC is emitting the code to search
for the null or non-ASCII byte at runtime, instead of pre-calculating
it. That's not worth it because the code is not vectorized, even at -O3
and with a long string. Instead, let it get the length at runtime with
QtPrivate::qustrlen(), which has vector code.
Drive-by fix the QAnyStringView::lengthPointerHelper() to be constexpr,
avoiding the same GCC warning that was fixed for QStringView in commit
4fd4082c3a.
Change-Id: Ieab617d69f3b4b54ab30fffd175c505cb66eac02
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Other parts of the code are expecting int.
Pick-to: 6.6 6.5
Change-Id: Iea73412c874adb2e6589e9b11607f313e1747d19
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The HDR info is independent of the current format anyways.
Removing the format check allows code to use hdrInfo() as
a signal for whether to set a HDR format, instead of having
to set the format, then query hdrInfo(), and then setting
SDR again if needed.
Pick-to: 6.6
Change-Id: I99b57335003d06af227f2a7078560c2a483b049b
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Knowing the maximum potential component value can be useful
to potentially (sic) opt out of an HDR code path if the maximum
color component value will be too low to make the additional
processing overhead worth it.
Pick-to: 6.6
Change-Id: Ib1e1b7a745b236e1d137a1e7daf1248f1572e184
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Although QRhiSwapChainHdrInfo uses 'max' for this value, it's used
by Qt Multimedia's QVideoWindowPrivate::render() as the current
maximum, so we need to reflect UIScreen's currentEDRHeadroom
rather than potentialEDRHeadroom (the absolute max), the same
way we reflect maximumExtendedDynamicRangeColorComponentValue
and not maximumPotentialExtendedDynamicRangeColorComponentValue
from NSScreen.
As we don't support HDRExtendedSrgbLinear on < iOS 16 there
is no point in providing a heuristic fallback based on the
iPhone 12 spec.
Pick-to: 6.5 6.6
Change-Id: If071bb64f269ce16886206df05eb9f27d260bf15
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
When using move-only types, continuations args are set using takeResult
function, which has the side effect of invalidating the QFutureInterface
associated with the promise/futures by:
1. setting isValid to false
2. setting the state to NoState
And when the promise is destroyed, it tries to run the continuations if
`finished()` is not called, which is done by checking the Finished bit
in the state. But since the continuation has been run before, and the
state has been set to NoState it tries to run the continuation again
causing a segfault. Multiple solutions come in mind:
1. don't run the continuation if the state is NoState, but this would
break the case when an empty promise is destroyed
2. check inside the continuation if it has been run before, and if so
don't run it again, but this seems hacky since we don't want the
continuation to be run twice, and it should break if it did.
3. when invalidating the promise leave the state as is, and change
isValid only to false, which changes the current behavior, but is
still compatible with the documentation which states only that
isValid will return false if takeResult is called
I chose option 3
I also extended some tests to test for move only types, and added a test
that continuations run when a promise is finished. This simple case
would segfault before with move only types.
Fixes: QTBUG-112513
Pick-to: 6.5 6.6
Change-Id: Ie225ac4fdf618e4edfb0efd663d6c7fd6b916dbd
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Replace the only usage of updateCurrentTime() outside of the class by a
getter that checks if there are pending timers. And make
updateCurrentTime() private.
Change-Id: I148639b01abd75990cfc7b25bb1f466e45ab0c71
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- Initialize member in-class
- Remove redundant include
- Remove QTIMERINFO_DEBUG related code, it hasn't been compiled for a
long time, so it has bit-rotted, and its purpose isn't clear any more
Change-Id: I874415e1edec7c4da03f697f5f9f8665d8b015a3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I.e. use chrono first, see linked task for more details.
Task-number: QTBUG-110059
Change-Id: Ie0908f9446957d4383fb7a70b67c16b78605a0f3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use new api calls for calculating pixel size and physical size
of multi-display setups after some existing apis have been deprecated
in Android API 30 and 31. Also, do the physical size calculation outside
of the supported modes loop.
As for the physical size, this patch still uses xdpi/ydpi for the
calculation instead of densityDpi as suggested in [1] because from
testing few scenarios, the results returned from xdpi/ydpi are more
consistent with physical device specs.
[1] https://issuetracker.google.com/issues/194120500
Pick-to: 6.6 6.5
Task-number: QTBUG-112742
Change-Id: I0c8ef5185c8b6463830b528374954c324a32d657
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Pipes are unnamed FIFOs, so they're basically the same.
The difference here is that open() blocks on opening a FIFO until both
ends of the FIFO are opened. This helps us in synchronizing the two
threads and thus ensuring that that the read() system call deep inside
QFile does, indeed, block.
We see this with strace -T on Linux:
[pid 662956] openat(AT_FDCWD, "/run/user/1000/tst_qfile_fifo.2575572361", O_RDONLY|O_CLOEXEC <unfinished ...>
... aux starts up ...
[pid 662957] prctl(PR_SET_NAME, "QThread") = 0 <0.000004>
[pid 662957] openat(AT_FDCWD, "/run/user/1000/tst_qfile_fifo.2575572361", O_WRONLY|O_CLOEXEC <unfinished ...>
[pid 662956] <... openat resumed>) = 4 <0.000133>
[pid 662957] <... openat resumed>) = 6 <0.000011>
[pid 662957] clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=500000000}, <unfinished ...>
[pid 662956] read(4, <unfinished ...>
[pid 662957] <... clock_nanosleep resumed>NULL) = 0 <0.500183>
[pid 662957] write(6, "\2", 1) = 1 <0.000033>
[pid 662956] <... read resumed>"\2", 1) = 1 <0.500311>
Pick-to: 6.6
Change-Id: I63b988479db546dabffcfffd1766d7a48819b149
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QProcess detects other types of failures from inside the modifier as
successful starts, because the childStartedPipe gets closed without an
error condition getting written. The new method allows a reporting as a
proper failure-to-start.
Added tests for both cases.
[ChangeLog][QtCore][QProcess] Added failChildProcessModifier().
Change-Id: Icfe44ecf285a480fafe4fffd174da2b10306d3c2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I've investigated the functions we call in the child side of a vfork()
for implementations that do more than simply place the system
call. Where wrappers exist, they are usually related to handling of Unix
signals or PThread cancellation. The implementations investigated are:
- Bionic (Android)
- FreeBSD
- glibc (Linux)
- MUSL (Linux)
- NetBSD
- OpenBSD
Relating to thread cancellation, NetBSD implements it with an internal
API that does not include Unix signals and Bionic doesn't implement
thread cancellation at all. Their wrapper functions are harmless.
The rest do use Unix signals to implement thread cancellations (called
SIGCANCEL everywhere except OpenBSD, where it's SIGTHR). Therefore, they
all block the application attempts to mask this signal or change its
handler (if they're not buggy). FreeBSD's and MUSL's do some locking in
their implementations[1][2] we really want to bypass, therefore we must
bypass their sigaction() wrappers.
The investigation also showed that the glibc[3] and NetBSD[4] abort()
implementations to be slightly unsafe, but we don't use them
ourselves. We're also adding QProcess::failChildProcessModifier() so
users won't have to resort to abort().
[1] https://github.com/bminor/musl/blob/master/src/signal/sigaction.c
[2] https://github.com/freebsd/freebsd-src/blob/main/lib/libthr/thread/thr_sig.c
[3] https://codebrowser.dev/glibc/glibc/stdlib/abort.c.html
[4] https://github.com/NetBSD/src/blob/trunk/lib/libc/stdlib/abort.c
Task-number: QTBUG-113822
Pick-to: 6.6
Change-Id: I9201d9ecf52f4146bb04fffd17651123800e15a4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This amends commit f9c87cfd44 to reset the
signal block mask too, not just the signal handlers. For this, SIGPIPE
is not treated specially.
Pick-to: 6.6
Change-Id: Ib5ce7a497e034ebabb2cfffd17627289614bf315
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The replace() implementation overwrites the passed Key key with a new
version, const_cast'ing away the const from the key passed by
reference-to-const. This is UB if the Key was originally declared
const.
Deprecate the function.
Also inline the const_cast, so compilers can readily detect the UB
even if users don't enable deprecation warnings. Due to the severity
of the issue (UB), immediate deprecation is warranted. There appear to
be no in-tree user of the API outside of tst_qpixmapcache.cpp.
[ChangeLog][Deprecation Notice][QtGui][QPixmapCache] The `replace(key,
pixmap)` function has been deprecated, because passing a `const Key`
to it results in undefined behavior. Use `remove(key, pixmap)`
followed by `key = insert(pixmap)` instead.
Pick-to: 6.6
Change-Id: Ic5060ce3271f2a1b6dc561da8716b452a2355d4c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If a foreground style has been defined in the style sheet,
QStyleSheetStyle populates its brushes for the color roles ButtonText,
WindowText, Text, and the widget's foregroundRole with the foreground
brush. PlaceholderText is set to the same brush with a modified color.
That sets their resolve bits in QStyleSheeetStyle's palette and
prevents these color roles from being inherited by the widget's
palette - in contrast to all other brushes.
This patch makes the brushes mentioned default to the widget's palette
if they are set there. It adds a test in tst_QStyleSheetStyle.
Fixes: QTBUG-93009
Pick-to: 6.6 6.5
Change-Id: Ie3df9dbd17b96fa72beee90792fc7eca1933cdbe
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The Qt Widgets Application example was moved to manual tests,
and no longer contains the snippet identifiers. Fix \snippet
and \quotefile commands to quote similar code snippets from
other examples or snippet files.
Fix also the following documentation warnings:
* No such parameter 'parsingMode' in QUrl::fromEncoded()
* Missing image: rsslisting.cpp
Pick-to: 6.6 6.5
Change-Id: Ibc989e83abc49837db08628facaf8e5f72b2f123
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
They are now ordered so that the mutex and the wait condition are in
different cache lines, to avoid false sharing situations, if the types
are holding the actual threading primitive structures, not mere pointers
to some other structure elsewhere.
For 64-bit systems:
OS | mutex | cond | Remark
--------------------+-------+-------+------------------
Darwin | 64 | 48 |
FreeBSD | 8 | 8 |
INTEGRITY | 8 | 8 | QMutex & QWaitCondition
Linux | 24 | 48 | Always uses futex
MinGW (Winpthreads) | 8 | 8 | Always uses futex
MSVC (MS STL) | 32 | 16 | Always uses futex
NetBSD | 48 | 40 |
OpenBSD | 8 | 8 |
QNX | ? | ? |
Change-Id: I63b988479db546dabffcfffd176698e4f0097e90
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
futexSemaphoreTryAcquire_loop() always waits on 32-bit portions of
QSemaphore. The current implementations only look at the pointer address
and don't care what size the waiter used. That's not the case for the
Darwin/macOS implementation:
In xnu/bsd/kern/sys_ulock.c:ulock_wake[1]:
if (opcode != ull->ull_opcode) {
ret = EDOM;
goto out_ull_put;
}
[1] 5c2921b07a/bsd/kern/sys_ulock.c (L970-L973)
Change-Id: I63b988479db546dabffcfffd1766c5eae61187f0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It turns out that Darwin's date formatting uses the Julian calendar
for dates before 1582-10-15, when the Gregorian calendar first came
into use (in some countries, while many others continued using
Julian). This leads to discrepancies between the (Gregorian) dates we
pass it for formatting and the (Julian) dates it actually prints, that
are the same number of seconds before 1970.
Previously the QLocale system backend for Darwin already had a kludge
to work round its handling of negative years, so it suffices to extend
that to years before 1583.
Fixes: QTBUG-54955
Pick-to: 6.6 6.5
Change-Id: I70f219b73bf20c0cd63bcda2b0e99042354872ca
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The function was part of the Cocoa style for checking the metal
look (not Metal the graphics API), but has long been removed.
Pick-to: 6.5 6.6
Change-Id: I366b952db4ae82b8ecc442f1ce61e7f53cacfe80
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
After the "CMake: make compile options consistent for Qt created libraries"
revert, this part of the code also get reverted, however, it's not
related to the revert reason: the user project's deprecation behavior
is changed. So restore this code. We need this code to make sure
we use the same parameters when compiling QtLibraryInfo, otherwise
some compilers may complain about it, such as clang-cl.
Pick-to: 6.6 6.5
Change-Id: Ie50d4f820be3a2e950dd87902d794f1d2681b7a5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
QDeferredDeleteEvent has the loopLevel field, which is a sum of
scope and loop levels found at posting. In sendPostedEvents however,
it is impossible to only use this information to find delete events
posted before the outermost loop (which should be handled by any loop)
based solely on this information, as the scope level essentialy removes
the information on loop level.
Break the loopLevel in two, storing both loop and scope levels in
QDeferredDeleteEvent, so that we can check whether an event was posted
before the outermost event loop (for which we need to compare only the
loop level).
QDeferredDeleteEvent was also made private as it should - it is an
implementation detail that wasn't hidden properly.
Change-Id: I0a607a0bd3a2deb5024acad67f740dbf4338574c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
We observe failures in CI on QNX because the measured timeout is ~995ms
rather than the expected 1000ms. Start the timer before the thread
starts to guarantee that at least as much time elapses as the thread
waits before writing the second byte to the pipe.
Otherwise, the thread might be sleeping already when the timer starts,
and then we can't rely on any measurements.
Pick-to: 6.6 6.5
Change-Id: I6072569a987f5e952b0953e0e394a223f891fd25
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
We should sync external headers for 3rdpary projects
like freetype and harfbuzz-ng and keep the directory
structure.
Fixes: QTBUG-113416
Pick-to: 6.6 6.5
Change-Id: Ie66edb9a21cff37ca6c8c68b6d225de6d8bbad81
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
It's an example in Qt SVG that is to be removed.
Pick-to: 6.5 6.6
Change-Id: I6e8cf38885649ca10f70a70b8400873c97bf1698
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Between the find() == 0 obfuscation (since fixed) and this unchecked
replace(), it took me way too much time to figure out what was going
on: the key passed has been invalidated by the setCacheLimit(0).
Now that we QVERIFY that the replace() _fails_, it's much easier to
backtrack and figure out why it does so and why, consequently, the
following find() is also expected to fail.
As a drive-by, reorder two lines so the grouping becomes clearer
(blocks now both headed by setCacheLimit()).
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I434b65fc13c3fed6512036efeb98d738eeb2a13d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
