headFromHttp hasn't been flaky since 5.14 times according to grafana,
does not fail locally.
Same situation with ioHttpRedirect as above.
ioHttpRedirectMultipartPost has not failed on Windows since october
2019, assumed stable now.
backgroundRequestInterruption no longer exists.
ioPostToHttpFromSocket would fail in debug MSVC builds but was
fixed in 710886fbdd.
Task-number: QTBUG-88943
Change-Id: Ida640179ef15a3452291745e4e94a71a385f57ae
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The intention was always that you can define properties that do
not require a changed signal. But having to explicitly pass
a nullptr as signal parameter into the macro is ugly, so
use the cool QT_OVERLOADED_MACRO to make it optional.
Pick-to: 6.0
Change-Id: I0ce366d043850f983c968d73c544d89933c48df9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The windows library user32 is no longer a known library for qmake; add
it explicitly.
Pick-to: 6.0
Change-Id: I61f44e8a2cbccbabbdc5d58bd2615b431097aafd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Similar to the previous commit which applied to QCborStreamReader, don't
allocate too much data before checking that the stream actually has that
much.
Pick-to: 5.15 6.0
Fixes: QTBUG-88256
Change-Id: I7b9b97ae9b32412abdc6fffd16454b7568a063ba
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
By calling the internal readStringChunk() function with a QByteArray
pointer, QCborStreamReader::readByteArray() can now avoid allocating the
resulting buffer until the internals have confirmed that there is
sufficient data in the incoming buffer. As a result, we first detect the
EOF condition before we conclude the payload would have been too big for
QByteArray (validation()) test. Meanwhile, the hugeDeviceValidation()
test ends up with a few conditions where it would have copied 1 GB of
data, so limit that too.
We make a choice of reporting OOM vs DataTooLarge only if QByteArray
fails to allocate in the first place (QByteArray::resize() ->
Q_CHECK_PTR -> qBadAlloc, QtCore is always built with exceptions on).
The QCborValue unit test needed a temporary work around until we apply
the same allocation fix (see next commit).
Pick-to: 5.15 6.0
Fixes: QTBUG-88253
Change-Id: I7b9b97ae9b32412abdc6fffd164523eeae49cdfe
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Previously a default constructor was required for the result type
of mappedReduced() and filteredReduced(), even if a default value
was provided.
This patch fixes the problem.
The issue was in the ResultReporter type, that was calling
QList::resize() to adjust the size of expected reported results.
A default-value parameter was added to the class, so that
a corresponding overload of QList::resize could be invoked.
Task-number: QTBUG-88452
Change-Id: I51113753e314d76aa74d201b5a7e327a6ca75f47
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
QColors were not premultiplied before being set.
Pick-to: 6.0 5.15 5.12
Change-Id: Id3765b6932a72374ddfd788fae4bb628a4edf0b7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Just like it was done in the .pro file.
Pick-to: 6.0
Change-Id: I7def52127f4bab6f0ef490ac7eee2de2da479352
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If a QBindable is created from a computed property, it is not possible
to actually set a value or a binding. If we try to do it anyway, we'd
get a crash. Thus we now check whether the function pointer is null
before invoking it.
Pick-to: 6.0
Task-number: QTBUG-87153
Change-Id: I5bedb9080ccf79d9b8166b80d5733d095ed76f8d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The hash and equality operators used need to be consistent with
each other. Unfortunately, QPMI::operator==() is not suitable to do
this. So specialize qHashEquals() for QPMI.
Fixes: QTBUG-88966
Change-Id: If5f19a722ae9fc4e78e93537e7ea15726f148768
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 83e95956ed58e88b11e2cc3cb61c5beacb7985db)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Amend 53b7cb1bd7, match() is only used
to provoke data races.
Change-Id: Id20b11fedf7f20e74baab15bbb60c995c1a0c794
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It was previously untested
Task-number: QTBUG-88183
Pick-to: 6.0
Change-Id: Icc59fc632957a75cac8c7f5e2a1aed88a1c9ff9d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The test in general is fine, but it was making an assumption that the
first 5 readyRead emissions would never result in the whole message
being received. In certain scenarios with slowdown however it was still
possible that we would receive the whole message after just a few
readyReady emissions. While I didn't check it's most likely due to a
mechanic in the QNetworkReply machinery where we suppress some
emissions if we know there's more data just about to be available.
Task-number: QTBUG-88943
Change-Id: I0cf06edb34d4e86cc8a42c0f1cd7e8c35765f6ee
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It's not _wrong_ to time out when connecting to something unreachable
(it's just a different way of handling it) so we shouldn't fail when
this happens either.
In local testing (windows) it times out after 8 seconds, so bump
the timer to 10 seconds. On systems where it's faster there'll be
no difference as long as things don't go wrong.
Pick-to: 6.0
Fixes: QTBUG-89089
Change-Id: I8437cf8e4fbecedea2391ed87fdce1213085b964
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Add test for qRound that covers some edge cases for rounding. Note that
as of right now, this test fails and the docs have been updated to warn
that it should not be depended on for strict correctness.
Change-Id: I1a61bca47abd77855fe7c13ded44e913cc7e8722
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Which contains a lot of 'macos'/'osx' black-listed auto-tests. They
mostly fail with SecureTransport (on BigSur) because SecTrustEvaluate()
does not like our old certificate. Instead, since SecureTransport
is deprecated anyway and we are not planning to develop it in future,
skip the related auto-test depending on QT_CONFIG(securetransport).
Task-number: QTBUG-88943
Change-Id: I5f6cb7b2d0ea15c445603c1ff3e1700f123c28d1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It was blacklisted due to the issue there. The issue is resolved, but
the blacklist stayed.
Task-number: QTBUG-88943
Change-Id: I7d9a660a17c1463dd8b654752ed5787fe5f5af24
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
If the first font in the families list happens to have been
disambiguated because of duplicates, two things went wrong:
1. hasFamily() would return false for the font family, because
it does not disambiguate when checking for the family name and
only checks if the families list contains the exact string.
2. Adding aliases to the full disambiguated string is not supported,
only the family name.
The first issue has been reported separately as QTBUG-89068.
The test failure is fixed by just avoiding the fonts that
are ambiguous in the test, as it really doesn't matter which
font we pick.
Fixes: QTBUG-89008
Pick-to: 5.15 6.0
Change-Id: I829778c2e7bb6090475c34dcf9cdce58862729d6
Reviewed-by: Liang Qi <liang.qi@qt.io>
Use a trick similar to the one we use for their ranged
constructors: support predicates that either take a
container's iterator, or that take a std::pair (for STL
compatibility).
[ChangeLog][QtCore][QMap] Added removeIf() and erase_if().
[ChangeLog][QtCore][QMultiMap] Added removeIf() and erase_if().
[ChangeLog][QtCore][QHash] Added removeIf() and erase_if().
[ChangeLog][QtCore][QMultiHash] Added removeIf() and erase_if().
Change-Id: Ie40aadf6217d7a4126a626c390d530812ebcf020
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The requests will remove themselves once they get deleted
but since the deletion is done through a _queued_ invokeMethod
to 'deleteLater' we will call
QHttpNetworkConnection::_q_startNextRequest first which may
end up starting a reconnect of the TCP socket which we had the error on.
In this specific instance it manifested as a race condition where we
either don't get a proxyAuthorizationRequired signal at all (it was
emitted while we didn't have any valid replies), or we get the signal
emitted too late and it gets emitted on whatever the next reply was.
Task-number: QTBUG-88417
Pick-to: 5.15 6.0
Change-Id: If3f8ececc5550f1868c90124559cb8e3029646d8
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We already have all we need in QHash to support this, so the addition
is simple enough.
Add test checking how many copies and/or moves are needed for a single
insert.
As a drive-by: remove some unneeded static_cast
Change-Id: Iaf768657644afa45f78f5c81ffcf89ba9607be96
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In preparation for the next changes.
Change-Id: Ibe0635dfa040842073749aa3e2ae140f27dc983a
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QEventPoint instead of TouchPoint: we have source compatibility for that,
but we can use the new type to avoid the deprecation warnings.
Some position accessors have been renamed too.
Change-Id: I5bfe5bc853931127a883d2bd61fab122495fd427
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Add QMetaType::hasRegisteredDataStreamOperators() to complement
the method to check whether a data stream operator exists.
Fixes: QTBUG-82916
Change-Id: Ib2f841131b7c401d5a3ae76d49104e41697c4eac
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QHeaderView sorting may be triggered when the user performs
some mouse interactions that should really not result in sorting.
Generally speaking, this happens when the user:
* presses on a non-movable section (A)
* moves on another section (B)
* releases on that section
resulting in B becoming sorted / flipping sorting.
(Non-movable is required, otherwise dragging would cause section moving,
not sorting.)
To make the matter worse, QHeaderView doesn't check that the release
happens within its geometry. This makes sense when moving sections: one
is able to drag a section horizontally/vertically even if the mouse
leaves the QHeaderView.
But when not moving sections, this means that one can
* press on section (A),
* move the mouse anywhere vertically (for a horizontal bar, mut.mut
for a vertical) above or below another section (B), that is,
outside QHeaderView's geometry
* release the mouse
and cause B to be sorted.
Fix it by
1) remembering which one was the section that the user originally
clicked on; that's the only one that can possibly become sorted
(if we're not moving and other conditions hold). No other variable
seemed to remember this.
2) on release, check that it happens within that section's geometry.
If so, sort.
Pick-to: 6.0 5.15
Change-Id: Icfb67662221efbde019711f933781ee1e7d9ac43
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Avoid spurious bindings by resetting the binding state before calling
the setter of eager properties.
Fixes: QTBUG-88999
Pick-to: 6.0
Change-Id: I1e3b5662307d906598335a21d306be9c606529d4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Currently untested
The socks case is odd: after accepting the first connection it shows as
unconnected. Details as for why is unknown, out of scope of adding this
test.
Pick-to: 6.0
Change-Id: I0e7658f23b89f3af8db379b001ee33a844f3bec4
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It didn't initially have tests. To avoid relying on realizing
breakage implicitly through other classes we'll just add tests instead.
Task-number: QTBUG-88183
Pick-to: 6.0
Change-Id: I7449dc1f9a118d4b7a8158a2c34563dbd9c43c66
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
This patch disables four failing unit tests when executed with the
offscreen backend.
Change-Id: Ie67341b886984e6de19cd8dd8a8a237a620a1b7a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
And also, reduce the utter sloppiness, weirdness of the test and
make it more a test and not a joke. Since the test itself depends
on !QT_NO_SSL, why bother building and running its main, to create
a useless tst_QSslError and do nothing then? Exclude test from
no-ssl build.
Pick-to: 5.15
Pick-to: 6.0
Change-Id: I67879b0de036cbc8c2f75a18f4cf94e6c43c5af0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
And inline the fast checks inside the methods in QBindingStorage.
This allows QObjectBindableProperty and friends to inline all the
fast checks and almost completely eliminates the overhead for property
accesses when no bindings are being used.
Read and write times of QObject based properties when no bindings
are being used:
Read Write
Old style property: 3.8ns 7.3ns
QObjectBindableProperty (no notification): 4.5ns 4.3ns
QObjectBindableProperty (with signal): 4.5ns 7.6ns
QObjectBindableProperty (inline accessors): 3.2ns 3.4ns
Numbers without this patch:
Old style property: 3.8ns 7.9ns
QObjectBindableProperty (no notification): 7.2ns 7.7ns
QObjectBindableProperty (with signal): 7.2ns 16.0ns
QObjectBindableProperty (inline accessors): 6.3ns 6.7ns
Change-Id: Ifd1fa3a489c3be8b1468c0b88af547aac397f412
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 98c82fb445acf45cc4c4bc86a5adda43358127bf)
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
QSslCertificate::verify() has an undocumented and not very desirable property -
on some platorms it updates the default configuration, which can be surprising.
For example, we deprecated QSslSocket::setDefaultCaCertificates() and recommend
using QSslConfiguration::defaultConfiguration(), QSslConfiguration::setDefaultConfiguration(),
and QSslConfiguration::setCaCertificates(). If an application does this to select
CA roots it trusts explicitly, and then for some reason is calling verify, the
application can have its QSslSockets successfully connecting to a host, whose
root was not trusted by the application. Also, on Windows, defaultCaCertificates()
include system roots already, no need to have them twice.
[ChangeLog][QtCore][QtNetwork] QSslSocket::verify - do not change the default configuration
Pick-to: 5.15
Pick-to: 6.0
Pick-to: 6.0.0
Fixes: QTBUG-88639
Change-Id: I1cd40b259d0a6dcd15c78d1e7c027ff10859595c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
And extend an auto-test for this. When a cookie verification mechanism is
enabled, and verifier, indeed, verifies that some datagram is a 'Client Hello'
message with a proper cookie attached, we start a real DTLS handshake creating a
QDtls object and calling 'doHandshake'. In case cookie verification
was enabled, we need parameters from the verifier (it's a crypto-strong
'number' and hash algorithm) to 'lock and load' the TLS state machine in
a freshly created TLS session object. This code path previously was only
tested manually and was found by LCOV as untested.
Pick-to: 5.15
Pick-to: 6.0
Change-Id: Ieacb8c989997999ea10e15bda6ae106a0338b698
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
And do not run the test with QSslSocket::supportsSsl() returns false -
this may mean unresolved symbols and thus missing functionality,
like i2d_X509 etc. This also makes cases more like other, that already
had those checks.
Fixes: QTBUG-87386
Change-Id: If4e9a650ca325b6f70956f532891a4c1d50465c0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Some code-paths were never executed by auto-test, thus giving us LCOV's
diagnostic. Extend existing tests and add new ones.
Pick-to: 5.15
Change-Id: I648747547f0525a482216b1e1972fcc698c73f65
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QMetaObject::indexfOfMethod returns the method corresponding to a
specific signature. In QML, we however only want any of the methods with
a given name (and do overload resolution at a later point).
For this usecase this patch introduces the internal
QMetaObject::firstMethod function.
Change-Id: Ie3820354edffb273c4cbe1399201a955ebe79344
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
std::optional<int> is the wrong datatype to use for compare.
First and foremost, it can't be used in the idiomatic form of
auto r = a.compare(b);
if (r < 0) ~~~ // a is less than b
if (r > 0) ~~~ // a is greater than b
which we *already* feature in Qt (QString, QByteArray).
Also, std::optional<int> (explicitly) converts to bool, which is
a trap, because the result of the comparison can be accidentally
tested as a bool:
if (a.compare(b)) ~~~ // oops! does NOT mean a<b
Not to mention extending this to algorithms:
auto lessThan = [](QVariant a, QVariant b) { return a.compare(b); }; // oops!
std::ranges::sort(vectorOfVariants, lessThan);
which thankfully doesn't compile as is -- std::optional has
an *explicit* operator bool, and the Compare concept requires an
implicit conversion. However, the error the user is going to face
will be "cannot convert to bool because the operator is explicit",
which is deceiving because the fix is NOT supposed to be:
auto lessThan = [](QVariant a, QVariant b) { return (bool)a.compare(b); }; // big oops!
Instead: backport to Qt the required subset of C++20's <compare>
API, and use that. This commits just adds the necessary parts
for compare() (i.e. partial ordering), the rest of <compare>
(classes, functions, conversions) can be added to 6.1.
Change-Id: I2b5522da47854da39f79993e1207fad033786f00
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 3e59c97c3453926fc66479d9ceca03901df55f90)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In addition (and as a fallback) from requiring qHash, add support
for std::hash specializations. This catches two birds with one stone:
1) users of Qt can simply specialize std::hash for their datatypes,
and use them in both QHash and stdlib unordered associative containers;
2) we get QHash support for any (stdlib) datatype that is hashable
without having to overload qHash for them.
[ChangeLog][QtCore][QHash] QHash, QMultiHash and QSet now support
for key types anything that can be hashed via std::hash, instead of
always requiring a qHash() overload.
Change-Id: Ib5ecba86e4b376d318389500bd24883ac6534c5f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
If one clicks on a QHeaderView's section, the header view will
sort the view by the respective column/row. By clicking multiple
times, one is able to toggle the sorting between ascending
and descending. Something that is NOT possible to do however is to
un-sort the view -- that is, to restore the model's original
sorting. This must be done via code, by asking the header or the
view to sort by section -1.
This commit adds new property to QHeaderView to make it possible
to unsort models. Basically, the sort indicator becomes a tri-state:
sort ascending, sort descending, unsort (sort by column -1).
[ChangeLog][QtWidgets][QHeaderView] Added the sortIndicatorClearable
property. Setting this property allows the user to clear the sort
indicator on a section, resetting the model to its default ordering.
Change-Id: Ibf4e280b2086b75ccd64d619ea4d70816dc3529f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
- Add tests for QCollatorSortKey
- Add test for QCollator copy assignment and copy construct
Currently QCollatorSortKey tests are working properly only
with QT_CONFIG(icu)
Task-number: QTBUG-88546
Change-Id: Ic35dfd33038cc736245904b78fe4383a5a11b580
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
