That seems to be enough for me when trying to reverse-resolve host names
inside the corporate network.
Pick-to: 6.7
Change-Id: I6818d78a57394e37857bfffd17bc6b0ebd39f51b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Because QHostInfo is threaded, so if the look up times out and we exit a
given test, the results may still be delivered to the next test.
Especially if the next test is also about to time out -- in which case
it doesn't and prints a nonsensical output.
Before:
FAIL! : tst_QHostInfo::lookupIPv4(WithCache:literal_ip4) '!QTestEventLoop::instance().timeout()' returned FALSE. ()
Loc: [tst_qhostinfo.cpp(220)]
FAIL! : tst_QHostInfo::lookupIPv6(WithCache:aaaa-single) Compared values are not the same
Actual (tmp.join(' ').toLower()) : "192.0.2.1"
Expected (expected.join(' ').toLower()): "2001:db8::1"
Loc: [tst_qhostinfo.cpp(281)]
Now:
FAIL! : tst_QHostInfo::lookupIPv4(WithCache:literal_ip4) 'helper.waitForResults()' returned FALSE. ()
Loc: [tst_qhostinfo.cpp(278)]
PASS : tst_QHostInfo::lookupIPv6(WithCache:aaaa-single)
Pick-to: 6.7
Change-Id: I6818d78a57394e37857bfffd17bc66e241cab24d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
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>
This patch simplifies the checks when migrating the class to comparison
helper macros.
Task-number: QTBUG-120359
Change-Id: I47a6ba20d3b89c31edc2f432621eae9385fbd0a3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Use WebDriverManager to install the correct version of chromedriver.
This will help avoiding mismatch of Chrome/chromedriver versions,
which sometimes happen in CI.
Fixes: QTBUG-122729
Change-Id: I40cf62c02c2cb6f57b031cc83b9fa38f6ed2610e
Reviewed-by: Simo Fält <simo.falt@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>
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>
This merges the tempFile and caching tests, which had been updated in
commit ae03ffaffd to attempt other
filesystems than APFS and btrfs.
Instead of adding yet another item to the list (xfs), let's insist by
writing more and flushing the OS buffers. Local testing says that btrfs
usually updates after the first write(), no later than the second, and
that APFS and XFS "just works" now (without the fsync() even).
Pick-to: 6.7
Fixes: QTBUG-123151
Change-Id: I6818d78a57394e37857bfffd17bbe7427307efc4
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
By using "wt" for all OS's; according to Thiago the 't' is ignored
everywhere except on Windows.
tests/auto/corelib/io/qfile/tst_qfile.cpp:2846:70: warning: comparison
between ‘enum QOperatingSystemVersionBase::OSType’ and ‘enum
QOperatingSystemVersion::OSType’ [-Wenum-compare]
2846 | const char *openMode = QOperatingSystemVersion::current().type() != QOperatingSystemVersion::Windows
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Amends 3446313c7a
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: I310d7d6ce3833756ffdc47b000e052ef3afdfdef
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
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>
Versionless targets in Qt6 are interface libraries that link the
versioned libraries using the INTERFACE link type. This makes the
linking chain more complicated than it can be. Also we miss some
significant interface properties in the versionless targets comparing
to the versioned targets.
The new approach manually generates the versionless targets, instead
of using CMake exports.
For CMake versions < 3.18 we now create a copy of the versioned
targets. The copy includes all the relevant INTERFACE properties from
the versioned targets and imported locations for all configs.
For CMake versions >= 3.18 we now create the versionless target ALIASes
which should behave give the transparent access to the versioned
targets.
Using the QT_USE_OLD_VERSION_LESS_TARGETS flag you may force the
behavor of the CMake versions <= 3.18
The change is partial workaround for QTBUG-86533.
Task-number: QTBUG-114706
Change-Id: Iafadf6154eb4912df0697648c031fcc1cbde04e0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Because we will do a small wait after the final connection (to see
if there are any unexpected extra connections) we can save some time
by reducing _how long_ we wait for it.
In general we only need an extra long wait for the first connection,
subsequent connections are faster.
So we change the loop structure from looping until we hit 20(!)
connections, when anything larger than 6 will fail the test anyway!
And use qWaitFor instead of repeatedly calling enterLoop and checking
the state of an ElapsedTimer, the total wait time is not super
interesting, and made it a guarantee that the test would take 10
seconds.
While we are here, update the attribute we use to test HTTP/2
connections. We were previously enabling http/2, but this is the new
default so it's not needed. We do, however, need to enable h2c if we
want to see it trying to upgrade to http/2 over cleartext.
Not a big issue, so we don't pick it very far back.
Pick-to: 6.7
Change-Id: Ia314ae2827ab8a8baaa4af2c5136c5e531bcb1f8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
I don't know what it is but it's not 1, because it is quite
often flaky in these tests. A single failure leads to deadlock
that takes 5 minutes to fail. Then a rerun might do another
5 minutes and fail the integration, or it will pass but take
longer to do so.
Pick-to: 6.7 6.6 6.5
Change-Id: I188276df7800b00a20dbe39edee91c582f0a82a7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
For some reason android in CI failed to include the
moc file through the mocs_compilation file.
It's an issue that needs some investigation, but
in the interest of time just include the moc file
directly.
Pick-to: 6.7 6.6 6.5
Change-Id: I079588598a6f4137ef1fccc482795d703b59bc6e
Reviewed-by: Alexey Edelev <alexey.edelev@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>
Retrieve the default value (if set) of a column during
QSqlDatabase::record() but not for QSqlQuery::record() as it's done for
the other drivers which support retrieving the default column value.
Fixes: QTBUG-122723
Change-Id: I92e052bfa6d88e019c0151fbcbc1483a65770c55
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
A QDialogButtonBox with the first accept button becoming default, didn't
explicitly set focus on such a button in a QDialog.
d44413d526 implemented this missing
functionality. It set focus to the automatic default button, unless the
QDialog had a focusWidget() set.
That has caused a regression, in cases where
- the QDialog has a QWidget child with a Qt::StrongFocus policy, and
- the QDialog is not yet visible, so focusWidget() returns nullptr.
Amend d44413d526ec12ed83acd7343c2005782178c7ad:
Implement a helper in QWidgetPrivate, that returns true, if a child
with a given focus policy is found.
Do not set focus to a QDialogButtonBox's automatic default button, when
- not located inside a QDialog, or
- a focusWidget() exists, or
- the dialog has QWidget child with Qt::StrongFocus, that is not a
child of the QDialogButtonBox.
Add an autotest function.
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-121514
Fixes: QTBUG-120049
Change-Id: I3c65ae36b56657f9af4a3a4b42f9b66e8bc5c534
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This finishes off ICC color space support in Qt (short of the
optional multi process elements), and includes necessary parts for
potential CMYK support (PCSLab and A2B support)
[ChangeLog][QColorSpace] ICC profiles that are not three-component
matrix based are now supported.
Task-number: QTBUG-108175
Change-Id: Ie29b17a366d9ba0ea8135e1752530d6bb19e7520
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The function replaces one of the found entries with the new value,
and removes any other entries. If no entries are found, a new entry
will be appended. The replacement search is done for performance
reasons; it's cheaper to replace an existing value.
All in all the function is a more convenient and performant
alternative for this sequence (which proved to be common while
porting QtNetwork internals to QHttpHeaders):
header.removeAll(<headername>);
header.append(<headername>, <value>);
[ChangeLog][QtNetwork][QHttpHeaders] Added replaceOrAppend()
convenience method, which either replaces previous entries with
a single entry, or appends a new one if no entries existed
Fixes: QTBUG-122175
Change-Id: I03957645d7e916a732ac7b8d3ae724bb6b16af87
Reviewed-by: Lena Biliaieva <lena.biliaieva@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Example takes precedent over build system file type.
According to QUIP-18 [1], all examples file should be
LicenseRef-Qt-Commercial OR BSD-3-Clause
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: Id348a89884bb309b96abb31077f14a51086b5d0c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
The variadic templates are supposed to be removed from the
overload set when any of the parameters is a literal string type,
as otherwise we get conflicts with the legacy overload taking
class names and signatures as const char *. The detection of
a literal string types was missing a few specializations, so that
we ended up with the wrong overload being called, and class
names getting interpreted as method names instead.
Add the missing specializations, and add more test coverage
for using the old overloads.
Task-number: QTBUG-122235
Pick-to: 6.7
Change-Id: I5488f2009c8f62d74fac6754844f57cf64011414
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Lauri Pohjanheimo <lauri.pohjanheimo@qt.io>
The class had operator==(), operator!=() and operator <() defined as
public member functions, so use QT_CORE_REMOVED_SINCE and
removed_api.cpp to get rid of these methods and replace them with hidden
friends.
Use QT_TEST_ALL_EQUALITY_OPS macro in unit-tests.
Use new \compares command in the documentation to describe the
comparison operators provided by QUrl.
Task-number: QTBUG-120303
Change-Id: Ic4fa2335292cc4b75ad2373832c0b89d768f529c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Specifically, don't use it for either of the x86-64 ABIs (LP64 and
ILP32). The generic case below should work for everyone.
Fixes: QTBUG-122720
Pick-to: 6.7
Change-Id: I01ec3c774d9943adb903fffd17b75fc79095e089
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
P2447 has been merged in C++26, backport the same functionality.
This makes QSpan<const T> a proper replacement for a const QList<T>&
parameter, because now both can be built via a braced-init-list.
// void f(const QList<int> &l); // old
void f(QSpan<const int>); // new
f({1, 2, 3}); // now OK
This is, technically speaking, SiC: in the presence of both `f`
overloads, the code above would have called the QList one. Now instead
the call is ambiguous.
We've been there already -- this is QString and QStringView all over
again, and the solution is the same: get rid of the owning container
overload. I'd rather have this construction *sooner* rather than *later*
in order to minimize the fallout.
And just like QString vs QStringView, there's nothing really doable to
prevent instant-dangling situations:
QStringView v = getString(); // dangles
QSpan<const int> s = {1, 2, 3}; // ditto
except for using QSpan (QStringView) as a *parameter type only*.
Note that QSpan with dynamic extent was already convertible from
std::initializer_list through its ranged constructor. However this fact
alone doesn't unlock the above syntax. QSpan with a static extent was
also convertible for the same reason. (This is non-standard:
std::span's range constructor for static extents is explicit, but QSpan
doesn't follow that design choice and makes the constructors implicit
instead.)
Found in API-review.
Pick-to: 6.7
Change-Id: I160ab5b292b0c2568cd9a7ad1b4430085f475c29
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
If a markdown file has FrontMatter, we look for the end of the newlines
after the `---` marker to begin parsing the actual markdown. But check
bounds in case the file contains only front matter and not markdown.
Fixes: QTBUG-122982
Change-Id: I09c4ae90c47ebd84877738aecc1d1cad0b0bfca2
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Before this fix, such screens would not render due to requestUpdateHold
is initialized to true and never reset.
The fix is to change the requestUpdateHold member to be a static
variable, so that it can be read by screens added after
requestUpdateHold has been called.
Also, add a test that would fail without this fix
Change-Id: Idf2ac916766a03480272cd550f9d1ab7fc5c5158
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Task-number: QTBUG-121787
Change-Id: Iee9f4fca676e77ab9d8ed485a28ce5ea8803be15
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
According to QUIP-18 [1], all tools file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: Icd5d5be2e04819617e68ff142924de1773bebbad
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
According to QUIP-18 [1], all test files should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: If06da73cecbbf718338d1b785b5eca36ac819ccb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Try to avoid writing anything that the parser would misinterpret.
Escape pre-existing backslashes, but not those that are already escaped.
Optimize maybeEscapeFirstChar() slightly and apply it to every line
of output (except in code blocks), not only to new lines created by
word-wrapping.
Since it would be hard to do this without using regular expressions,
the markdown writer feature now depends on the regex feature.
Fixes: QTBUG-96051
Fixes: QTBUG-122083
Pick-to: 6.7
Change-Id: I8d95366501fd31441829081c668f11a3a3a23fe2
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This reverts commit c41733b06b.
Based on the Grafana data, last flaky was August 14, 2023, and
the test works fine on local vm with stressed cpu.
Fixes: QTBUG-115598
Pick-to: 6.7 6.6 6.5
Change-Id: I634598d20a581d4d1443a3fd81e1e9481bfa2545
Reviewed-by: Inho Lee <inho.lee@qt.io>
Which will be used to represent timer IDs. Thanks to Marc for the idea
to use "a strongly typed int".
QTimer got a new id() method that returns Qt::TimerId (can't overload
timerId()). Various classes in qtbase have a member named timerId(), but
a new method is needed anyway in QTimer so id() it is (this is the
reason QChronoTimer only has id() and no timerId()). Besides
timer.timerId() has an extra "timer".
This commit fixes the inconsistency between QObject using `0` timer id
to indicate "failed to start", while QTimer::timerId() returned `-1` to
indicate "timer is inactive". QTimer::id(), being a new method and all,
now returns Qt::TimerId::Invalid, which has value `0`, so that the
values match between the two classes. Extend the unittests to ensure
QTimer::timerId()'s behavior is preserved.
[ChangeLog][Core][QObject] Added Qt::TimerId enum class, that is used to
represent timer IDs.
Change-Id: I0e8564c1461884106d8a797cc980a669035d480a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The interval in QTimer is a QProperty of type int, which means it's
limited to the number of milliseconds that would fit in an int (~24
days), this could cause overflow if a user constructs a QTimer with an
interval > INT_MAX milliseconds. And it can't be easily changed to use
qint64/std::chrono::nanoseconds:
- changing the getters to return qint64 means user code would have
narrowing conversions
- the bindable QProperty interval can't be changed to qint64 during
Qt6's lifetime without the risk of breaking user code
- adding a new bindable QProperty that is qint64/nanoseconds is an
option, but it has the complication of what to do with the int
interval; set it when setInterval(milliseconds) is used by using
saturation arithmetic? and what about notifying observers of the
changed interval?
Thus the idea of creating a new stop-gap class, QChronoTimer, as a
cleaner solution. Both classes use QTimerPrivate.
During the lifetime of Qt6, QTimer's interval range is about 24 days,
whereas QChronoTimer's interval range is about 292 years
(duration_cast<years>nanoseconds::max()).
Currently the plan is to fold QChronotTimer back into QTimer in Qt7.
Mark all QPropertyS in the new class as FINAL since they aren't
intended to be overridden; this offers a performance boost for QML[1].
[1] https://lists.qt-project.org/pipermail/development/2024-February/044977.html
[ChangeLog][QtCore] Added QChronoTimer, which uses a
std::chrono::nanoseconds intervals, as a replacement for QTimer.
Fixes: QTBUG-113544
Change-Id: I71697f4a8b35452c6b5604b1322ee7f0b4453f04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Ultimately this is the best way to keep the log history of the code.
Change-Id: I3413deffdb093a3239d65b6ca939e744224e722a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Then we will automatically handle invalid leading characters instead
of throwing away the whole sequence when it cannot be converted.
Added a test that was failing before.
Drive-by change: add a comment explaining why we
have the stack allocated buffer.
Task-number: QTBUG-118834
Change-Id: I647a58f2ba95e2e7ed4ea6a964d99ecc0c91fad3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some machine in CI is failing some of these sometimes and
I would like to know by how much.
Pick-to: 6.7
Change-Id: I88b41d5cde81419f7c11f7038101962630eb31ef
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The current logic that we will disable the read notification if we
have any data at all doesn't make sense for users who use the
receiveDatagram functionality, since they will not make any calls
that trigger the read notifier to be re-enabled unless there is a
datagram ready for us to hand back.
Fixes: QTBUG-105871
Pick-to: 6.7 6.6 6.5
Change-Id: I0a1f1f8babb037d923d1124c2603b1cb466cfe18
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Thiago Macieira
Alexandru Croitor
Tatiana Borisova
Ivan Solovev
Piotr Wiercinski
Ahmad Samir
Laszlo Agocs
Alexey Edelev
Mårten Nordheim
Christian Ehrlicher
Axel Spoerl
Allan Sandfeld Jensen
Juha Vuolle
Lucie Gérard
Volker Hilsheimer
Rym Bouabid
Giuseppe D'Angelo
Shawn Rutledge
Even Oscar Andersen
Matthias Rauter
Liang Qi