Replace public operators operator==() and operator!=() of QCborValue
to friend method comparesEqual().
Replace public operator<() of QCborValue to friend method
compareThreeWay().
Use QT_CORE_REMOVED_SINCE to get rid of current comparison methods
and replace them with a friend.
Delete #if 0 && __has_include(<compare>) blocks,
since they are not required anymore.
Task-number: QTBUG-120300
Change-Id: I884ff6ce2a71618b0e3eaa907f0852f93c2a073c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
QOperatingSystemVersion intentionally does not define operator==() and
operator!=() since ae072cd9c4.
It means that we cannot use comparison helper macros.
Still, we can manually define four relational operators or
operator<=>() in C++20 mode, and give the class a partial ordering.
We choose partial ordering, because versions of different OS types are
incomparable.
Implement the operators in terms of helper function compareThreeWay(),
which potentially allows to use this class in some templated code.
As a drive-by: make the static compare() function noexcept, because
it really is.
Fixes: QTBUG-120360
Change-Id: Id4c9ce740e42baa719ca0ee84146d087b21675c6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QTypeRevision consists of two quint8 values: major and minor version.
Each of the versions can be unknown.
The rules for comparing with the unknown version are as follows:
zero version < unknown version < non-zero version
At the same time, two unknown versions are considered equal.
This makes the comparison a bit tricky, but it still fits into the
category of strong ordering.
Replace the existing friend relational operators with helper functions
and comparison helper macros, making this type strongly ordered.
Update the unit-tests to use the new comparison helper test functions.
As the test functions check the reversed arguments as well, we can
reduce the number of rows for the data-driven comparison test.
Fixes: QTBUG-120359
Change-Id: Ib6f1037fc7b5fed148e35ee48b56b05dcd36b3b4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Done by harmonizing the use on the QT_CONFIG(temporaryfile) macro and
fixing one test that was missing. We can't remove the older macro
because it is marked PBULIC) but we don't need to use it ourselves.
Change-Id: I01ec3c774d9943adb903fffd17b7eb4dd1a4e63f
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
If the Android View is resized, the QWindow instantiated by it
should be resized accordingly.
Task-number: QTBUG-122626
Pick-to: 6.7
Change-Id: I7bfbca149f927718d1e28cdabfa8759afbd06039
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Qt window loading is initiated either when the QtView is attached
to its Android window, or when the Android QPA plugin has been loaded
and is ready, depending on the order. Since the window attachment
happens in the Android UI thread, and the Android QPA plugin callback
happens in Qt thread, add synchronized block to make sure the execution
stays ordered.
Fixes: QTBUG-122626
Pick-to: 6.7
Change-Id: Id476032f02aa8990432a02f62b6bf6237a17e7ac
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The SPDX database lists the license as 'Unicode-3.0', and 'Unicode
License v3'. Now, the SPDX standard actually says that
License identifiers (including license exception identifiers) used
in SPDX documents or source code files should be matched in a case-
insensitive manner.
But the website at https://spdx.org/licenses/ doesn't treat it this way,
so the link we generate out of the identifier actually gives a 404. So
it's just easier to use the 'original' capitalization.
Amends 063026cc50
Pick-to: 6.5 6.6 6.7
Change-Id: I826077a914721b7b9499ad62c08fdf20be94e88d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Some libs don't necessarily have the lib prefix in their names,
3rd party libs and Qt for Python might have that, so no need to
always add that prefix to loaded libs is the lib name already
contains a .so suffix.
Fixes: QTBUG-123286
Pick-to: 6.7 6.7.0
Change-Id: Ib65215d9b4410c5c9e00aa0642f48ab45c92fe03
Reviewed-by: Shyamnath Premnadh <Shyamnath.Premnadh@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
In the \fn commands for a limited number of methods in the
documentation for Testlib and Widgets, `= 0` is passed as default
argument instead of `= Qt::KeyboardModifiers()`. Until QDoc with Clang
17, inclusive, QDoc generated the correct signature. However, with
Clang 18, QDoc outputs `= 0` in the documentation. While strictly
speaking still correct, this change impacts the documentation
negatively in terms of readability.
Dropping the default argument from the \fn command ensures that QDoc
generates the right signature with both Clang 17 and Clang 18.
Task-number: QTBUG-123130
Pick-to: 6.7
Change-Id: I94ccec2f2c9a02241095fb5b18feb74aa55f97e1
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
We want to be able to pass as an argument whether the texture grabbed to
an FBO is supposed to have a flipped y-axis or not. This is required for
screen capture on the EGLFS platform.
Task-number: QTBUG-121835
Pick-to: 6.7 6.6 6.5
Change-Id: I6dddc879a4be7ff2c2c189747193423644be55a0
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
We already have fine-grained macros to individually disable APIs
that we consider "suboptimal" or "dangerous". This commit adds
a shortcut for the user to set all such macros in one go.
QT_ENABLE_STRICT_MODE_UP_TO is versioned, just like
QT_DISABLE_DEPRECATED_UP_TO; the idea is that users should set it
to the minimum Qt version they want to support.
Also, if QT_DISABLE_DEPRECATED_UP_TO is not set, then
QT_ENABLE_STRICT_MODE_UP_TO will set it as well, to the same value.
[ChangeLog][QtCore][QtGlobal] Added the QT_ENABLE_STRICT_MODE_UP_TO
macro.
Change-Id: I5466465986104e047a6a86369928be9294f24ab7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Give it a name in line with the function name:
qAsConst -> QT_NO_QASCONST, as already done for qExchange.
We can do this because we never documented the macro itself.
So, while at it: also document the macro.
Change-Id: I6eb0834df438e4f4e818ef2cf8e702ed156dc253
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The EventPointMap QPointingDevicePrivate::activePoints is actually a
QVarLengthFlatMap<., ., 20>, not 16, so copy the value instead of just
hard-coding something.
Amends 296ede3aab.
Change-Id: Ic8e83f4095f57be74f7708d5cec6a19971772b76
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Before the qWaitFor() port from int to QDeadlineTimer, the
implementation constructed a QDeadlineTimer internally, passing int
timeout and Qt::PreciseTimer. The int overload that was retained for
source-compatibility, however, constructs the QDeadlineTimer without
the PreciseTimer flag, which is a behavior change.
Restore the Qt 6.6 behavior and pass Qt::PreciseTimer.
Amends fa296ee1dc.
Pick-to: 6.7 6.7.0
Change-Id: Ib8e5b912c74b70d32a77195edb0d2a30cd7c241d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Wrap dlerror() in QLatin1StringView(), like we already do in
unload_sys().
Amends a6a5681470.
Pick-to: 6.7
Change-Id: Ia8c91d6962c74d5916c47b2abbb3920f051c8e5e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The bootstrapped tools really mustn't produce random output (they must
always be reproducible exactly). Therefore, ensure we don't need this
file.
Change-Id: I01ec3c774d9943adb903fffd17b7eb94dbd4be89
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
I added QT_NO_VARIANT to qconfig-bootstrapped.h to be clearer on what
the #ifs are, but there's no testing of that feature outside of
QT_BOOTSTRAPPED.
Change-Id: I01ec3c774d9943adb903fffd17b7e8ac4340fb89
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It was only used by the cmake_automoc_parser so it would write a 64-bit
in big-endian format. So bypass QDataStream and write it native
endianness.
Change-Id: I01ec3c774d9943adb903fffd17b79c78e56db4cf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Commit 90bc0ad41f ("QProcess/Unix: add
failChildProcessModifier()") added this line that set childStartedPipe
so that the failChildProcess() callback had something to write to. But
we left it set on exit from QProcessPrivate::startDetached(), which
caused the QProcess destructor to try and close it.
Noticed when debugging the issue for QTBUG-123083.
Pick-to: 6.7 6.7.0
Task-number: QTBUG-123083
Change-Id: I6818d78a57394e37857bfffd17bbc41c8400270f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Currently unused. I've tested that GCC 13 and Clang 17 do compile this
and do output reasonable assembly, with and without AVX512FP16 (I also
tested AVX10.1 with GCC 14).
Clang is unable to allocate a "v" (vector) register when T is qfloat16,
so I could only implement the conversion using _Float16. Strictly
speaking, Clang >= 16 always knows about _Float16, but I didn't want to
have a different detection from qtypes.h.
Change-Id: I6818d78a57394e37857bfffd17bae860f8055324
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The x86 SSE instructions do what we want and set a flag in the MXCSR to
indicate whether we should return false, so we can improve the codegen.
GCC generates for QStringView::toFloat():
call _ZNK11QStringView8toDoubleEPb
movl $8064, 12(%rsp)
movl $1, %eax
#APP
# 330 "/home/tjmaciei/src/qt/qt6/qtbase/src/corelib/global/qnumeric_p.h" 1
vldmxcsr 12(%rsp)
vcvtsd2ss %xmm0, %xmm0, %xmm0
vstmxcsr 12(%rsp)
# 0 "" 2
#NO_APP
movl 12(%rsp), %edx
testb $24, %dl
je .L2120
... handling of the under/overflow ...
The MXCSR instructions do need to read and write from memory, but the
stack is usually already in L1 and CPUs have special optimizations for
it.
There are two alternative implementations to the implementation chosen:
first, we could confirm there was no underflow or overflow using an
expression like:
(v == 0) == (*value == 0) && qt_is_finite(v) == qt_is_finite(*value);
But that is still very costly, with 4 UCOMISx instructions and several
memory loads.
Second, we could use the VFPCLASSSD and VFPCLASSSS (yes, 4 "S")
instructions to confirm whether a finite input became zero or non-
finite, but a) that's only available with AVX512, so of little practical
use today and b) it has a 3-cycle latency. Like the comparisons above,
we'd need 4 of them.
Change-Id: I01ec3c774d9943adb903fffd17b8b9cb2ce805ce
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
No change in behavior. But instead of trying to guess if we're going to
cross a page boundary, we check for the cacheline: if we don't cross a
cacheline boundary, then we can't cross a page boundary either. Testing
bit 4 can be implemented with a shorter instruction than a test for bit
11.
f43de: 40 f6 c7 20 test $0x20,%dil
Change-Id: I664b9f014ffc48cbb49bfffd17b04817a0fb8c6b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It's the same aeshash() as before, except we're passing a template
parameter to indicate whether to read half and then zero-extend the
data. That is, it will perform a conversion from Latin1 on the fly.
When running in zero-extending mode, the length parameters are actually
doubled (counting the number of UTF-16 code units) and we then divide
again by 2 when advancing.
The implementation should have the following performance
characteristics:
* QLatin1StringView now will be roughly half as fast as Qt 6.7
* QLatin1StringView now will be roughly as fast as QStringView
For the aeshash128() in default builds of QtCore (will use SSE4.1), the
long loop (32 characters or more) is:
QStringView QLatin1StringView
movdqu -0x20(%rax),%xmm4 | pmovzxbw -0x10(%rdx),%xmm2
movdqu -0x10(%rax),%xmm5 | pmovzxbw -0x8(%rdx),%xmm3
add $0x20,%rax | add $0x10,%rdx
pxor %xmm4,%xmm0 | pxor %xmm2,%xmm0
pxor %xmm5,%xmm1 | pxor %xmm3,%xmm1
aesenc %xmm0,%xmm0 aesenc %xmm0,%xmm0
aesenc %xmm1,%xmm1 aesenc %xmm1,%xmm1
aesenc %xmm0,%xmm0 aesenc %xmm0,%xmm0
aesenc %xmm1,%xmm1 aesenc %xmm1,%xmm1
The number of instructions is identical, but there are actually 2 more
uops per iteration. LLVM-MCA simulation shows this should execute in the
same number of cycles on older CPUs that do not have support for VAES
(see <https://analysis.godbolt.org/z/x95Mrfrf7>).
For the VAES version in aeshash256() and the AVX10 version in
aeshash256_256():
QStringView QLatin1StringView
vpxor -0x40(%rax),%ymm1,%ym | vpmovzxbw -0x20(%rax),%ymm3
vpxor -0x20(%rax),%ymm0,%ym | vpmovzxbw -0x10(%rax),%ymm2
add $0x40,%rax | add $0x20,%rax
| vpxor %ymm3,%ymm0,%ymm0
| vpxor %ymm2,%ymm1,%ymm1
vaesenc %ymm1,%ymm1,%ymm1 <
vaesenc %ymm0,%ymm0,%ymm0 vaesenc %ymm0,%ymm0,%ymm0
vaesenc %ymm1,%ymm1,%ymm1 vaesenc %ymm1,%ymm1,%ymm1
vaesenc %ymm0,%ymm0,%ymm0 vaesenc %ymm0,%ymm0,%ymm0
> vaesenc %ymm1,%ymm1,%ymm1
In this case, the increase in number of instructions matches the
increase in number of uops. The LLVM-MCA simulation says that the
QLatin1StringView version is faster at 11 cycles/iteration vs 14 cyc/it
(see <https://analysis.godbolt.org/z/1Gv1coz13>), but that can't be
right.
Measured performance of CPU cycles, on an Intel Core i9-7940X (Skylake,
no VAES support), normalized on the QString performance (QByteArray is
used as a stand-in for the performance in Qt 6.7):
aeshash | siphash
QByteArray QL1SV QString QByteArray QString
dictionary 94.5% 79.7% 100.0% 150.5%* 159.8%
paths-small 90.2% 93.2% 100.0% 202.8% 290.3%
uuids 81.8% 100.7% 100.0% 215.2% 350.7%
longstrings 42.5% 100.8% 100.0% 185.7% 353.2%
numbers 95.5% 77.9% 100.0% 155.3%* 164.5%
On an Intel Core i7-1165G7 (Tiger Lake, capable of VAES and AVX512VL):
aeshash | siphash
QByteArray QL1SV QString QByteArray QString
dictionary 90.0% 91.1% 100.0% 103.3%* 157.1%
paths-small 99.4% 104.8% 100.0% 237.5% 358.0%
uuids 88.5% 117.6% 100.0% 274.5% 461.7%
longstrings 57.4% 111.2% 100.0% 503.0% 974.3%
numbers 90.6% 89.7% 100.0% 98.7%* 149.9%
On an Intel 4th Generation Xeon Scalable Platinum (Sapphire Rapids, same
Golden Cove core as Alder Lake):
aeshash | siphash
QByteArray QL1SV QString QByteArray QString
dictionary 89.9% 102.1% 100.0% 158.1%* 172.7%
paths-small 78.0% 89.4% 100.0% 159.4% 258.0%
uuids 109.1% 107.9% 100.0% 279.0% 496.3%
longstrings 52.1% 112.4% 100.0% 564.4% 1078.3%
numbers 85.8% 98.9% 100.0% 152.6%* 190.4%
* dictionary contains very short entries (6 characters)
* paths-small contains strings of varying length, but very few over 32
* uuids-list contains fixed-length strings (38 characters)
* longstrings is the same but 304 characters
* numbers also a lot contains very short strings (1 to 6 chars)
What this shows:
* For short strings, the performance difference is negligible between
all three
* For longer strings, QLatin1StringView now costs between 7 and 17% more
than QString on the tested machines instead of up to ~50% less, except on
the older machine (where I think the main QString hashing is suffering
from memory bandwidth limitations)
* The AES hash implementation is anywhere from 1.6 to 11x faster than
Siphash
* Murmurhash (marked with asterisk) is much faster than Siphash, but it
only managed to beat the AES hash in one test
Change-Id: I664b9f014ffc48cbb49bfffd17b045c1811ac0ed
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
So that it hashes to the same value as QString{,View}.
In order to test this, you must either run on a CPU other than ARM and
x86, or disable the AES hasher. I did that and can confirm siphash and
murmurhash do work with on-the-fly conversion from Latin-1.
Change-Id: I664b9f014ffc48cbb49bfffd17b03e5e62ec4e89
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This complements the previous commit by adding the heterogeneous lookup
in operator[]. Unlike the members of the previous commit, this one may
insert into the hash, in which case it needs a way to cast from the
heterogeneous type K to the actual Key type.
Change-Id: I664b9f014ffc48cbb49bfffd17b037c1063dfb91
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This implements support in QHash and QMultiHash for lookups of
heterogeneous key types that produce the same hash value. This is
implemented by duplicating each of the following functions into an
overload on Key and one a template that is enable_if-constrained to a
key type that meets the requirement:
* contains
* count
* equals_range
* find
* operator[] (const only)
* remove
* take
* value
* values (QMultiHash)
The non-const operator[] may insert into the hash, so it's not part of
this commit.
Change-Id: I664b9f014ffc48cbb49bfffd17b037852f0fd192
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The typical examples are views and their corresponding owning
container. Since they are different types, the search is heterogeneous,
hence the name.
We have to do it differently from the Standard Library. There, because
the hasher is a template parameter to std::unordered_{map,set}, it can
be a structure with overloads for different types, all of which the
implementer guarantees produce the same hash for input that also
compares equal. For QHash/QSet, we don't have a template parameter.
One alternative solution would be to detect the existence of
qHashEquals(T1, T2) or qHashHeterogeneousEquals() or something.
Change-Id: I664b9f014ffc48cbb49bfffd17b0318c0775a2b5
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
They were literally identical (as in, they used exactly the same letters
in the exact same order), but changed on whether *this was const or not.
So pass *this as a parameter so we can have just one implementation.
QMultiHash doesn't need this change because its non-const equal_range()
calls the const version after making a copy.
Change-Id: I6818d78a57394e37857bfffd17ba06aee2e7db0b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Complements commit 7fe5611365 by moving
the default value selection into a lambda that is passed to the Impl
function. This makes the two pairs of overloads in each of the classes
be a single line.
Change-Id: I6818d78a57394e37857bfffd17ba067beb3a42fa
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
std::string has them too, see constructor 10 in [1]. There, they are
StringViewLike, something we may want to do here too, which would also
lower the precedence of the constructor in the overload resolution.
This will be needed for the non-const heterogeneous QHash::operator[].
[ChangeLog][QtCore][QByteArray] Added a constructor to create a
QByteArray from QByteArrayView.
[ChangeLog][QtCore][QString] Added a constructor to create a QString
from QStringView.
[1] https://en.cppreference.com/w/cpp/string/basic_string/basic_string
Change-Id: I6818d78a57394e37857bfffd17b9ab03bd0253e6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The switch from <string> to <string.h> dropped the definition of
std::size. Include <iterator> since <string.h> is no longer used to
pull in std::size.
Amends: dc2ae08e02.
Pick-to: 6.7
Change-Id: Ib742538eb5d21c77fcae7ee9abb6d5329bbcfd63
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
The relational operators were removed in
8652c79df0 with the argument that they
do not have a total order. Back than it was a valid argument, because Qt
did not support any of the C++20 ordering types.
Now Qt has its own implementation for all three ordering types, so we
could technically add relational operators and claim that QVariant
provides partial ordering.
However, that could potentially lead to many bugs and/or unexpected
results, if people start using QVariant as a key in std::map/QMap
containers.
We do not want that to happen, so we only use the helper macros to
implement (in)equality operators.
This commit also extends the unit tests, providing more extensive
testing of (in)equality operators and the pre-existing
QVariant::compare() method.
Fixes: QTBUG-113234
Change-Id: I783f3b5df552da782627f4ed0a5bb1b577753a23
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's redundant with the noswap member: we swap if the stream byte order
is the opposite of the CPU's and don't swap if it is the same. That the
default is to swap is another reason why people should stop using
QDataStream (though CBOR also stores numbers in big-endian).
Change-Id: I50e2158aeade4256ad1dfffd17b29adc2b698ead
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Just a little clean-up to avoid repetition.
Change-Id: I50e2158aeade4256ad1dfffd17b29a5b36c71ddc
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The q_status member has too much space dedicated to it: 32 bits. So we
can shrink it to a mere 8 bits and move it up to the 1-byte padding hole
and repurpose the space it used to use. This only works because the
q_status member was not accessed by any inline function before Qt 6.8
(see commit fc23fa459c).
After this, pahole says:
class QScopedPointer<QDataStreamPrivate> d; /* 0 8 */
class QIODevice * dev; /* 8 8 */
bool owndev; /* 16 1 */
bool noswap; /* 17 1 */
quint8 fpPrecision; /* 18 1 */
quint8 q_status; /* 19 1 */
enum ByteOrder byteorder; /* 20 4 */
int ver; /* 24 4 */
quint16 transactionDepth; /* 28 2 */
/* size: 32, cachelines: 1, members: 10 */
That leaves 16 bits of tail padding unused, so reduces the maximum
number of nested transactions to 65536. That is to support a Qt 7 layout
in an upcoming commit.
Change-Id: I50e2158aeade4256ad1dfffd17b29d75fd13f472
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There is a 2-byte padding in all architectures between the noswap member
and byteorder, because the latter requires a 32-bit alignment. So we can
use this space to store this little-used field and avoid one more reason
for QDataStreamPrivate.
Now:
class QScopedPointer<QDataStreamPrivate> d; /* 0 8 */
class QIODevice * dev; /* 8 8 */
bool owndev; /* 16 1 */
bool noswap; /* 17 1 */
quint8 fpPrecision; /* 18 1 */
/* XXX 1 byte hole, try to pack */
enum ByteOrder byteorder; /* 20 4 */
int ver; /* 24 4 */
enum Status q_status; /* 28 4 */
/* size: 32, cachelines: 1, members: 9 */
Change-Id: I50e2158aeade4256ad1dfffd17b29c2c5db02c12
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
We have to be able to strip the _SRGB nonsense from the render target
view formats when rendering into textures that are provided from an
external engine (e.g. OpenXR) and are forced onto us with formats such
as VK_FORMAT_R8G8B8A8_SRGB.
This highlights some limitation of the current system, which has very
limited handling of sRGB stuff since proper renderers such as Qt Quick
3D have first class support for linearization and converting to sRGB
at the end of their shading pipeline, so _SRGB format textures are
never used in practice.
OpenGL has an issue which is different from everything else, namely
that we do not correctly do the glEnable/Disable on GL_FRAMEBUFFER_SRGB.
The QOpenGLExtensions flag is not what we need. We need to know if the
sRGB-conversion-on-write is supported or not, not that some framebuffer
is sRGB-capable. So do our own query based on the desktop and the ES
extension (GL_EXT_sRGB_write_control is something we never checked for,
but that is the appropriate GLES extension, supported on the Quest 3
for instance) This is now corrected in the gl backend. This means that
the colors will no longer be "too bright" with OpenGL ES and multiview
on the Quest 3 for example.
Unlike OpenGL, Vulkan and D3D automatically convert in shader reads and
writes when the shader resource view or the render target view has a
_SRGB format. (which we get by default since we pass on the texture
format) Getting a second linear->sRGB conversion on the already sRGB
data generated by e.g. Qt Quick 3D is just wrong.
Allow solving this by a new function that can be optionally called to
say we want (RGBA8, srgb=false), i.e. VK_FORMAT_R8G8B8A8_UNORM, for
the views.
Of course, reality is more complicated. D3D11 for instance does not
allow "casting" a fully typed texture, we'd need to use a _TYPELESS
format for that (possibly with other consequences), so skip D3D11.
For D3D12 this should work from Windows 1703 on.
Implementing for Metal is also left as a future exercise - it is neither
needed at the moment within Qt, nor is it trivial, because view textures
have to be created explicitly in Metal, normally we just work with the
MTLTexture as-is, not with views.
Task-number: QTBUG-122288
Task-number: QTBUG-122614
Change-Id: I8aea4e892b308d48f0bf18bdef481e460fbc9d47
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Draw progressbars and progressbar handles on sub-pixel coordinates to be
HighDPI aware.
Pick-to: 6.7
Change-Id: Ib4f39c3b3a05d9f47c045dd6032d7544b7add175
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Draw scrollbars and scrollbar handles on sub-pixel coordinates to be
HighDPI aware.
Pick-to: 6.7
Change-Id: Iab7c8566f31a58f83d03ec6644be68bf130682ce
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
There were a few issues to deal with. One of them was that we would
print a warning about an internal error if we tried to *set* an error
on the reply after it had been cancelled. That's kind of unavoidable
since these things happen in different threads, so just ignore the
error if we have been cancelled.
The other issue was that, for a request with data, we will buffer the
data to send, and _only then_ do we start the request. This happens
asynchronously, so the user can abort the request before it has finished
buffering. Once it finished buffering it would set the state of the
request to "Working", ignoring that it was already marked "Finished".
Fixes: QTBUG-118209
Fixes: QTBUG-36127
Pick-to: 6.7 6.6
Change-Id: Idbf1fd8a80530d802bee04c4b0a6783cba4992d3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
On 64-bit systems, both the requests.size() and the
activeStreams.size() were truncated to uint32_t values from int64_t
ones. While extremely unlikely that either will contain more than 4Gi
elements, avoid the truncation by verifying that the `max` amount of
streams is larger than the activeStreams, and then using size_t for
the range.
Pick-to: 6.7
Change-Id: I50644cb634bab0f020acf9aea1d03744b11dbe51
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
By just moving the handling of the child process' desired target
directory below the initialization of either the signal mask and PThread
cancel state, without that "return".
Commit 52ed6af527 ("QProcess/Unix: merge
some code from startProcess() and startDetached()") introduced
QChildProcess and merged the functionality of PThreadCancelGuard into
it. But it added that "return;" to the code path failing to opendirfd()
the target directory, meaning that the QChildProcess constructor could
exit without calling disableThreadCancellations(), but the destructor
would still run restoreThreadCancellations() every time the opening
failed. And we have tests for that: setNonExistentWorkingDirectory and
detachedSetNonExistentWorkingDirectory.
For the cancel state, the uninitialized variable we ended up passing to
pthread_setcancelstate() was probably harmless, because the cancellation
state is almost always active and the variable would have been non-zero.
And we don't test pthread cancellation, so we would never notice the
problem.
But commit bd32c7d705 ("QProcess/Unix:
block all Unix signals between vfork() and exec()") introduced a block
of the Unix signals with the same uninitialized variable problem. Unlike
the PThread cancellation state, the original signal mask would usually
be empty, so the "restoration" would actually mask signals we wanted.
And one such important signal is SIGCHLD, used by QProcess/forkfd when
*not* using vfork semantics. This meant that tests that had a child
process modifier (meaning, they wouldn't use vfork semantics) would end
up timing out because we'd never get the SIGCHLD that told us the child
had exited.
Fixes: QTBUG-123083
Pick-to: 6.7 6.7.0
Change-Id: I1362eb554b97dc012d02eab2dbca90b06728460e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Contrary to OpenSSL the new ciphers support in Schannel
would disallow all ciphers when the list was empty.
The pre-existing behavior was to use the default list.
Amends f7792d2b6d
Pick-to: 6.7
Change-Id: I0e79013ac86261c4afa4affb28cb1838177c12de
Reviewed-by: Tobias Koenig <tobias.koenig@kdab.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Ensure move where it makes sense, and remove it where it doesnt
Change-Id: I988d7ff44f1d7898a967130fa53ed6ec5690e778
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Amends 8af346c1f6 and
1d9137e13f.
Found in 6.7 API review
Task-number: QTBUG-123115
Pick-to: 6.7 6.7.0
Change-Id: I98d79274f26f3439302a59181401b6e244fe5202
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Anton Kudryavtsev
Tatiana Borisova
Ivan Solovev
Thiago Macieira
Tinja Paavoseppä
Kai Köhne
Assam Boudjelthia
Paul Wicking
Mikko Hallamaa
Giuseppe D'Angelo
Lucie Gérard
Marc Mutz
Dennis Oberst
Laszlo Agocs
Wladimir Leuschner
Mårten Nordheim
Allan Sandfeld Jensen