We try our best to pass on the file location of a failure, including for
fatal errors, but the reporting or logging machinery should not assume
there is one.
By passing on nullptr for the file location we allow the logging backends
to decide how to handle the situation, e.g. by not emitting extra fields
for failure location.
This effectively reverts c25687fa0b,
in favor of relying on the backends to cope with null filename,
which they already did.
As qFatal uses QMessageLogger, which by default disables file/line
information in release builds, we need to explicitly enable this in
our self-tests, to get uniform test results. Similarly, we disable
file/line info from testlib itself, as reporting Qt internal file
and line information for user diagnostics is less useful. The odd
one out there is qtestdata.cpp, which still ends up in test output
due to using QTEST_ASSERT instead of qFatal for its diagnostics.
Cleaning up that, and unifying how we report testlib issues to the
user, is left for another day.
Pick-to: 6.2
Change-Id: Ib9451b8eed86fe3ade4a4dcaf0037e1a3450321c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QtTest best practices documentations recommends using output
mechanisms such as qDebug() and qWarning() for diagnostic messages,
and this is also what most of our own tests do.
The QWARN() macro and corresponding internal QTest::qWarn() function
was added when QtTest was first implemented, but was likely meant as
an internal implementation detail, like its cousin QTestLog::info(),
which does not have any corresponding macro.
This theory is backed by our own QtTest self-test (tst_silent)
describing the output from QWARN() as "an internal testlib warning".
The only difference between QWARN() and qWarning(), besides the much
richer feature set of the latter, is that qWarning() will not pass
on file and line number information in release mode, but QWARN() will.
This is an acceptable loss of functionality, considering that the user
can override this behavior by defining QT_MESSAGELOGCONTEXT.
[ChangeLog][QtTest] QWARN() has been deprecated in favor of qWarning()
Pick-to: 6.2
Change-Id: I5a2431ce48c47392244560dd520953b9fc735c85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This follows up on commit 98666c8afc,
which did the same for QString. If someone wants to get formatting
suitable to an unsigned value, they can cast the value to that
unsigned type and the correct overload shall pick it up.
[ChangeLog][Important Behavior Changes] QByteArray's formatting of
negative whole numbers to bases other than ten now, like QString's
(since Qt 6.0), formats the absolute value and prepends a minus sign.
Task-number: QTBUG-53706
Pick-to: 6.2
Change-Id: I91fee23d25ac0d5d5bcfcbeccbac1386627c004a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
One is a bad application or library in this case, but nonetheless
we should handle this more gracefully then just crashing due to
the QRhi already having been destroyed. Mainly because in Qt 5 one
could get away with the same: releasing OpenGL objects underneath,
for example, a QSGPlainTexture with no (or wrong) GL context did
not generate any user visible fatal errors. So we should not crash
in Qt 6 either with these code bases.
In debug builds or when QT_RHI_LEAK_CHECK is set, one will get the
unreleased resources warning printed in Qt 6, which is a step
forward compared to Qt 5. So there is still some indication that
something is badly designed, even if the application survives.
Task-number: QTBUG-95394
Pick-to: 6.2
Change-Id: I944f4f425ff126e7363a82aff926b280ccf1dfc3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
- avoid calls to private and virtual functions, if the device is not
open;
- avoid repetitive checks in loops;
- add missing checks in readLine() overloads;
- remove check against unsuccessful resize().
Change-Id: I973d5931163b25db1c09c7c3b66f29ea90bb1b29
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This signal is emitted by the QIODevice itself, so we don't have to
forward it from the internal socket.
Pick-to: 6.1 6.2
Change-Id: I85745f36d7a27d92f339a9184de3b6e5d46f6f34
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Remove the QString/QStringView/QLatin1String/const char* overloads
from the API, but not the ABI.
As a drive-by, replace a use of QStringView::left() by truncate(), as
suggested by a comment.
[ChangeLog][QtCore][QUuid] The from-string constructor and the
fromString() function now take QAnyStringView (was: overload set with
a subset of QString, QByteArray, const char*, QLatin1String,
QStringView each).
Change-Id: If7fa26cfbef9280480c78b669d9f5f14118995ed
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Formatting using scientific notation with extra precision wasn't tested
Change-Id: I7a89a0f3d6468515604e43e52fc366dedf3c39ea
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For historical reasons a few of the subtests are skipped when
running with anything but the plain text logger to stdout.
To ensure we have as broad test coverage as possible for the
expected output of the various loggers we run these tests in
stdout-mode.
Pick-to: 6.2
Change-Id: I856905d1543afe89710533657a55bd599c0305fd
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The JUnit reporter was initially named xunit, but the naming was inaccurate
and the reporter was renamed in 27db9e458c.
The corresponding test has now been renamed as well, and as an added bonus
we only run it for that reporter.
Pick-to: 6.2
Change-Id: I59cb7d949514cdf46a0199a53a7a3e39f833207c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
This patch introduces some test improvements to check the calls of
different methods on an empty default-constructed string.
Apart from that, many other tests are added to extend code coverage.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: If86ef3d8611a678798b1bcc60a1a4f5598fd2179
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch fixed two bugs in indexOf/lastIndexOf:
1. The lastIndexOf(char, qsizetype) overload was crashing with an empty
QByteArray. It was unconditionally calling lastIndexOfCharHelper()
which assumes that this QBA is not empty. An explicit check for
the empty case is added.
2. The indexOf(QByteArray, qsizetype) overload was behaving incorrectly
while searching for an empty QByteArray. In this case it
unconditionally returned its second parameter (from). However, from
can be negative, or even exceed the size of this QByteArray. This
patch handles this cases properly.
As a drive-by: this patch adjusts the QByteArray::indexOf(char, qsizetype)
and QByteArray::lastIndexOf(char, qsizetype) overloads to match with the
QByteArrayView implementation. This is done to have similar code paths
in both cases and avoid tricky bugs in future.
Ideally we had to adjust the QByteArrayView implementation, but it's
fully inline, so can't be changed without breaking BC.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Iaef2fdc5b99cce6aa342cca2d17544a1ad7ca677
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
There are few slots whose lambdas are empty; most will at least
capture [this]. But there are a few in Qt examples that do, e.g. []{
qApp->quit(); }. Logging is also an example. So go the extra mile and
optimize for empty functors by inheriting from them as opposed to
storing them in a member variable.
Change-Id: I3904f10db5ebe904ba889d29c08569edd804df3b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QString itself can be compiled without QRegularExpression, but
the tests do not check if they are supported or not.
This patch fixes the issue by introducing the proper #ifdef guards.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: I797691f78a34d4f78a86af99c78bf06e26e846d1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In commit 9bad096c09 I gave
qFuzzyIsNull(qfloat16) a more forgiving threshold, consistent with
qFloatCompare(qfloat16, qfloat16)'s fractional threshold. The selftest
failed to catch two of the tests failing, so fix one of them to use
different values, and remove one.
Updated test expection for txt and deleted for other formats, as
they're skipped (in tst_selftests.cpp) for this test. Refined the
generator script to know about this test only being tested for txt.
Pick-to: 6.2
Change-Id: I109547cf92178bb9f5ff0b06e0b3bb40c881b41b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
C++20 deprecated compound volatile statements such as pre- and
post-increments, to stress that they're not atomic. So instead of
volatile i;
~~~~;
++i;
you're now supposed to write
volatile i;
~~~~;
int j = i; // volatile load
++j;
i = j; // volatile store
which matches more closely what hardware does.
Instead of fixing every use of volatile pre- or post-increment in this
fashion individually, and realising that probably a few more Qt
modules will have the same kind of code patterns in them, write
QtPrivate functions to do the job centrally.
Change-Id: I838097bd484ef2118c071726963f103c080d2ba5
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Before this change, next() was the only way to advance the iterator,
whether the caller was ultimately interested in just the filePath()
(good) or not (bad luck, had to call .fileInfo()).
Add a new function, nextFileInfo(), with returns fileInfo() instead.
Incidentally, the returned object has already been constructed as part
of advance()ing the iterator, so the new function is faster than
next() even if the result is ignored, because we're not calculating a
QString result the caller may not be interested in.
Use the new function around the code.
Fix a couple of cases of next(); fileInfo().filePath() (just use
next()'s return value) as a drive-by.
[ChangeLog][QtCore][QDirIterator] Added nextFileInfo(), which is like
next(), but returns fileInfo() instead of filePath().
Change-Id: I601220575961169b44139fc55b9eae6c3197afb4
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The number(double) testing done in tst_qstring was a bit lacking,
so other tests (like tst_uic) had to be run to properly test changes.
Task-number: QTBUG-88484
Change-Id: I2fc6cba27788ab4fab6d625257f35868e2b684e3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We missed the chance of deprecating them in 5.15, so
they'll just add to the pain of porting to 6.0. We
should not keep them around forever, though; QMap isn't
random access and so its iterators should only have
bidirectional APIs.
Pick-to: 6.2
Fixes: QTBUG-95334
Change-Id: I3577f7d25e8ab793722d2f220fd27bc85c622b0d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QHash::squeeze() was unconditionally calling reserve(0), which is
always allocating memory (even for 0 size).
This was leading to a confusing situation when calling squeeze() on
a default-constructed container with 0 capacity() actually allocated
memory. This is very misleading, as squeeze() is supposed to free
unneeded memory, not to allocate more.
This patch adds a check for non-zero capacity. As a result, nothing
is done for default-constructed container.
Note that this patch also affects the QSet::squeeze() behavior, because
QSet uses QHash as its underlying data type.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Ib1c3c8b7b3de6ddeefea0e70b1ec71803e8fd3b3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
When inserting items into the result store, a ResultItem is created,
which stores a pointer to the results list and their size. If the size
of the ResultItem is set to 0, it means that a single result is stored.
In case of trying to report results via an empty list, the size is 0, so
result store treats it as a single result.
Added checks before storing the results to make sure that the result
list isn't empty. Note that empty lists are allowed in some cases for
the filter mode, because ResultStoreBase::addResults() knows how to
handle those cases correctly.
Task-number: QTBUG-80957
Pick-to: 5.15 6.1 6.2
Change-Id: I399af4c3eef6adf82fea5df031fe9a9075006b1f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This reverts commit c19695ab95.
Just because QSet has limited API doesn't mean we can't provide this
in an efficient way for std::unordered_set :P
Added tests.
Pick-to: 6.2
Change-Id: I4f8f0e60c810acdc666cf34f929845227ed87f3b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This introduces a new attribute that allows behavior to keep
the TCP connection(s) to a HTTP1/HTTP2 host longer or shorter
than the default of 120 seconds.
Note that the server might still close the connection earlier.
Fixes: QTBUG-20726
Fixes: QTBUG-91440
Change-Id: I7da64230a78c642c12c0ddbe6b678cf17c3aafde
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In two cases, it was as easy as replacing an unnamed enum's values
with constexpr variables. In the case of QSimplex, I opted for
qToUnderlying(), as the enum made sense on its own.
Change-Id: Ifcf5be14bd2f35e50adabdbd7ecdb2e83f6bf5b4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch introduces some test improvements to check the calls of
different methods on an empty default-constructed container.
Apart from that, many other tests are added to extend code coverage.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Icc1f1342738603c9bed065b2a36c72ea60b48962
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This mechanism was neither properly designed nor correctly tested
initially on Windows.
[ChangeLog][QtNetwork][Important Behavior Changes] QLocalSocket on
Windows now implements delayed closing, which is consistent with
the behavior on Unix.
Change-Id: Ic3bc427e68eea7f18201f6129df19fbc87d68101
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
It's the user's privilege to do so when they want to finish reading the
QIODevice. Moreover, this is the only difference between close() and
disconnectFromServer().
[ChangeLog][QtNetwork][Important Behavior Changes] The Windows
implementation of QLocalSocket::disconnectFromServer() no longer calls
close(), which is consistent with the behavior on Unix.
Change-Id: Ie9ce20c60259a2b08f5254b719355bd7be9b17cd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
In the case where we have pending data to write, calling flush() here
may cause the device to close immediately, if the pipe writer already
got a result of the last operation from the thread pool. In this
scenario, the device does not enter the 'Closing' state, which leads
the following code to unexpectedly fail on Windows
socket.write(...);
socket.disconnectFromServer();
QVERIFY(socket.waitForDisconnected());
Removing the call to flush() makes the behavior consistent with the
implementation on Unix.
Change-Id: Ic31fbc999be979c1e5befa8f132d9fb367f472ca
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
According to the documentation, calling abort() should immediately
reset the socket to its initial state. This includes:
- closing the file descriptor;
- closing the QLocalSocket as an I/O device;
- canceling a pending outgoing connection, if it exist;
- reseting 'serverName' string.
So, adding a call to close() resets the state entirely.
Pick-to: 6.1 6.2
Change-Id: I9c604b5187c6300b437d7aa4c2d06db03edacf21
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The plan for QObject::connect() (perfect) forwarders, such as
QWidget::addAction(), was to just use a variant of the Detection Idiom
to see whether QObject::connect() with the arguments as given would
compile and SFINAE out the forwarder otherwise.
It turns out that the "functor" overload of QObject::connect(), in
particular, is severly underconstrained and accepts e.g. QKeySequence
as a function object, only erroring out via a static_assert() in the
body of the function, and thus at instantiation time and not, as
needed, at overload resolution time.
At the same time, we don't really want QObject::connect() to SFINAE
out on argument mismatches between signal and slot, because the
resulting error messages would be ... unkind to users of the API. We
would like to keep the static_assert()s for easier error reporting.
Reconciling these two contradicting requirements has so far eluded
this author, so for now, to unblock progress, we explicitly black-
and, in one case, white-list possible arguments. Because QKeySequence,
in particular, is implicitly constructible from int(!), and therefore
any enum type(!), incl. Qt::ConnectionType, we need to do way too much
coding in the addAction() constraints. Hopefully, we'll be able to fix
the issue at the root cause, in QObject, before Qt 6.3 is out, but
until then, this is an ok-ish stop-gap measure.
Add thorough overload set checks (positive ones only, for now) to
tst_qwidget and tst_qmenu.
Change-Id: Ia05233df818bc82ecc924fc44c1b349af41cbbf1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
All the getters of QFutureWatcher are consistent with the getters of the
corresponding QFuture, except for the isFinished() method, which returns
'true' only after the finished() signal is delivered. This behavior
might be unintuitive for the users. In particular, isFinished() returns
'false', even if it's called immediately after waitForFinished().
[ChangeLog][QtCore][QFutureWatcher][Important Behavior Changes] The
QFutureWatcher::isFinished() method now indicates if the related
QFuture is finished, instead of indicating if the finished() signal was
delivered. This makes it consistent with the future that is being
watched.
Fixes: QTBUG-91048
Pick-to: 6.1 6.2
Change-Id: I6ae9b882b23e06198a82c95b026491bd480b3bf0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QAbstractButton::setChecked is not virtual, so QToolButton cannot
override to synchronize the default action's checked state. This resulted
in button and default action not being in sync when the checked state
of the button was changed programmatically, while changing the checked
state on the action kept the button in sync.
Connect to the button's own toggled signal instead to keep the state of
the default action in sync. Make it a unique connection to allow multiple
calls to setDefaultAction, which are used by QToolButton to keep the
button updated if properties of the default action change.
Add a test that confirms that button and action are synchronized both
ways, and that we only get single signal emissions when changing either
programmatically.
Fixes: QTBUG-95255
Pick-to: 6.2 6.1
Change-Id: I0e027faf1da763ef1878e46e85bfa70073c8bf82
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Extend tests to explicitly check the behavior of empty
default-constructed container.
Also add some missing tests to increase the code coverage.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Ie57b5d13fad9a846c29c87be4985c87e69bba305
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch introduces some test improvements to check the calls of
different methods on an empty default-constructed string.
Apart from that, some other tests are added to extend code coverage.
As a drive-by:
* fix int -> qsizetype in the test data
* fix int -> enum in the test data
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: I159473b7f5dcbea1bdaf2966979e066296351208
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
CMake 3.21.0 + Ninja now pass absolute source file paths to the
compiler which causes __FILE__ to be absolute and qFindTestData
to ignore any QT_TESTCASE_BUILDDIR value.
This causes the test to fail, because it won't find test data in the
custom specified location.
Disable the test for now.
Amends 70464b355e
Pick-to: 6.2
Task-number: QTBUG-95268
Task-number: QTBUG-95018
Change-Id: If99035e897ac1d5f153d4e19c94e4355f88970af
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The MinGW resource compiler fails to handle compile definitions
with multiple values.
When the resource file is compiled as part of the main target rather
than a separate object library, the resource generation rule will
inherit all the compile definitions from the main target.
For the case of tst_selftests this causes errors like
gcc: error: badxml\: No such file or directory
gcc: error: benchlibcallgrind\: No such file or directory
gcc: error: benchlibcounting\: No such file or directory
gcc: error: benchlibeventcounter\: No such file or directory
gcc: error: benchliboptions\: No such file or directory
Limit the compile definition to the C++ language only, so the multiple
values are not passed to the resource compiler.
Pick-to: 6.2
Change-Id: Ie53666839272556323b50d79c090f0dc71745d11
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
While QFileSelector is documented to work on files, select accepts
arbitrary URLs. Moreover, the QML engine can end up intercepting
arbitrary (user provided) URLs, including to directories.
Prior to this change, passing "file:///" or "/" to the function would
break: We would temporarily get a "//" path, which is invalid, and thus
we would return an invalid in the end.
Prevent this by only appending a slash to the path when it doesn't have
one.
Fixes: QTBUG-85410
Pick-to: 6.2
Change-Id: I1d2807a9d225df611c3a5e871e3c1d90a6a25953
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QtConcurrent reduce functions were requiring to explicitly pass the
the result type when passing functors as reductor. This was because of
inability to deduce the result type from the functors. The result type
of the QtConcurrent reduce functions should match with the type of the
fist argument of the operator() when a functor is passed. Reused the
ArgResolver type trait (already used for QFuture and QtConcurrent::run)
to find out the result type in that case.
Task-number: QTBUG-88448
Change-Id: Ief0eeee197df8cb9c30f3403d71978f36e4fb0f2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
layoutAboutToBeChanged must be called before
persistentIndexList as the user might create persistent indexes
as a response to the signal
Fixes: QTBUG-93466
Pick-to: 6.2 5.15
Change-Id: I73c24501f536ef9b6092c3374821497f0a8f0de4
Reviewed-by: David Faure <david.faure@kdab.com>
These signals allow monitoring where in the HTTP1/HTTP2
flow a request is currently in.
Fixes: QTBUG-71698
Fixes: QTBUG-18766
Change-Id: Icc2fe435afc9f680fa7a76c32731e25fcdfeb4b4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The server's socket may not have been created yet, so use the server's signal
instead.
Switch to QCOMPARE to get better output.
Delete the extra checking for schannel, we don't support Windows 8 anymore.
Pick-to: 6.2
Change-Id: Icd310c32939cb577c9f3438789f667aa0a3a4d85
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If the file already existed we simply removed the old one without
adjusting the size. So use the removeFile() function which takes care of
that.
Additionally, if the current size was non-null we previously increased
the size (presumably meant to be temporarily but wasn't) and called
expire() which would either:
1. not do anything and return currentCacheSize, if it was not greater
than the max size. This would mean that the size of the file would be
counted twice.
or,
2. discard currentCacheSize, measure the size of the items, and then
remove some items if the total size surpassed the max cache size
Neither of those branches need us to (temporarily) increase
currentCacheSize. It also doesn't attain the (presumed) goal of trying
to keep below the max cache size after having added the new item.
Fixes: QTBUG-95009
Pick-to: 6.2 6.1 5.15
Change-Id: I2b5b13ff473a7aa8169cf2aecfea783c97f2d09a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Extend tests to explicitly check the behavior of empty
default-constructed containers.
Also add some missing tests for the existing methods
(mostly for QMultiHash) and correct some end()s to cend()s
in comparisons.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Ic9e1b86ef67f6bca2751a65a8589b2f7e0ebb5ea
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The test causes frequent failures in the CI. Couldn't reproduce on
actual arm64 hardware, so it's likely to be a QEMU bug. From the
available logs it seems that all the test cases are flaky (there's a
failure even after cleanupTestCase() is called), so disable all of them.
Fixes: QTBUG-94737
Pick-to: 6.1 6.2
Change-Id: I783ec2179ba779a2c8d93351a78e8472a4f7a907
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Declaration::lengthValue only supported 'px' sizes, but one can transform
any 'pt' value into 'px' by multiplying with 1.33.
Notes: this ignores display DPI, and instead follows the W3C definition
of 'pt' and 'px' as absolute lengths [1].
[1] https://www.w3.org/TR/css3-values/#absolute-lengths
1pt = 1/72th of 1 inch
1px = 1/96th of 1 inch
so the conversion is px = pt * (72/96).
Add unit test that verifies this using QPushButton's icon-sizes property,
also with changed font in preparation of adding support for 'em' and 'ex'
units in a follow up commit.
Task-number: QTBUG-8096
Pick-to: 6.2
Done-with: Cristian Maureira-Fredes <Cristian.Maureira-Fredes@qt.io>
Change-Id: I58782e7ad0e2ff9d89ed695f8a23b1e584cfed64
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
This patch mostly introduces some test improvements to check the
calls of different methods on an empty default-constructed
container.
Apart from that some other tests are added to extend test
coverage.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: If2bc96158462292bbdf8504942141af94568c729
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Add tests to verify parser behavior with locales that use code points
outside of Unicode BMP to represent dates. ccp is used for this because
Chakma language uses code points outside of BMP for both letters and
digits. QDateTimeParser currently is not able to handle this locale
correctly, so the tests are marked as expected failures.
Task-number: QTBUG-87111
Change-Id: I1cc6fe7304b47f19950ae0ad3179c4ffa946adb3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
