The test fails as sendmsg() on the socket trying to deliver a packet to
the IPv6 link-local fe80 address returns with -ENETDOWN. I cannot figure
out why this happens when RHEL 6.6 is run under qemu/kvm but not under
vmware. More details are in the task, but meanwhile the result of this
test is ignored.
This affects only RHEL 6.6, it passes on RHEL 7.2.
Change-Id: I4ade5cd249dd0d1901368ab571dad324e0fd10c2
Task-number: QTQAINFRA-1042
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
QTimeZone("UTC") should be valid, as "UTC" appears in the list of
availableTimeZoneIds(), and tst_QTimeZone::dataStreamTest() constructs
timezones like this, which are considered valid.
The internal representation of a QTimeZone("UTC") as created by
QTimeZone::QTimeZone(const QByteArray &ianaId) is a QUtcTimeZonePrivate
which isValid(), so the containing QTimeZone isValid() too.
When QTimeZone is serialized into a QDataStream, it calls
tz.d->serialize(ds) which is QUtcTimeZonePrivate::serialize. This
writes QStringLiteral("OffsetFromUtc") followed by the IANA ID and
the offset (etc.) to the datastream.
When QTimeZone is deserialized it looks for this marker string, and if
present, it passed all of the parameters to the QTimeZone constructor
(not just the name). However, that constructor does not support standard
IANA timezones (only custom ones), and when it detects that the supplied
IANA ID is actually listed in availableTimeZoneIds(), it leaves the
pointer to the QTimeZonePrivate uninitialized (NULL), which leaves
the QTimeZone invalid (isValid() returns false).
Thus, a valid timezone which was serialized and then deserialized has
become invalid. This also affects serialization of QDateTimes with
timezones.
Fixed by calling the name-only constructor first, which works (only) for
IANA standard timezones and leaves the QTimeZone invalid (isValid()
returns false) otherwise. In which case, we can call the many-argument
contructor to create a custom timezone with the same offset as the one
which was originally serialized.
[ChangeLog][QtCore][QTimeZone] Fixed sending IANA standard UTC-offset
QTimeZones through QDataStream, which previously came out invalid after
deserialization.
Task-number: QTBUG-60595
Change-Id: Id9c47e8bda701faae4d800e012afb6db545b2fe9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It is possible that tmpdir already exists as a leftover from previous
tests. That is no reason for the test to fail.
Change-Id: I010633fb92defb064093af9872ae6fd2178f07dd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
load(resources) makes embedding the test data into the executable
fail for platforms that use builtin test data. As the load call
is only used to obtain QMAKE_RCC we can avoid that call by
assuming that rcc was not renamed and assembling the path ourself.
Change-Id: I25b982d10f5617d9a213803e7e4bcc85fc66b2e7
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
The binary hangs rather than segfaults on that platform.
Task-number: QTBUG-59936
Change-Id: Id7d38edb7c746e3c0cd4b4941e0e19b3d42a628a
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
By avoiding unneeded nested QPainters.
Crash was:
ASSERT: "s" in file /data/sources/qt/qt5/qtbase/src/gui/painting/qpaintengine_raster.cpp, line 2239
s was nullptr because the inner QPainter had called updateState(0), which is then dereferenced by the outer QPainter.
Task-number: QTBUG-61036
Change-Id: I7aad648f805f1abac4d38dfbefa2292da8b52af4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Normaly, in C++ It's not valid to define a keyword, but it turns out that some
system header do, so we just silently accept it.
[ChangeLog][moc] moc no longer errors out if a C++ keyword is #define'ed
Task-number: QTBUG-61204
Change-Id: Ia4d3ff9c77b6ff261b6140c220cfb81bd13f1d6d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
There were two more places that blacklisted certain interface types that
commit e579c822c5 didn't catch. This
commit adds those two.
Task-number: QTBUG-61263
Change-Id: Ia58d0480a9169f0f121aec03bf2e8900a58939cd
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
Similar on how it is done for Windows desktop we also use the given
style hint when building the list of fallbacks a font family.
Change-Id: I71378581d07f20ebe5bf0bc757bba919cc70e118
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
The documentation says that it's equivalent to
qgetenv(varName).toInt()
But the implementation wasn't. QByteArray::toInt() verifies that the
entire string was consumed, so QByteArray("1a").toInt() == 0, but
qstrtoll alone doesn't. That is, qstrtoll("1a", ...) == 1.
The implementation also detected the base, a behavior I kept. Instead, I
updated the documentation.
Change-Id: I0031aa609e714ae983c3fffd14676ea6061a9268
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
This method now returns -1 by default, due to commit 6255cb893d
which mistakenly replaced -1 with Qt::IgnoreAction (0x0).
As a result, dropping is forbidden in a number of applications
(I detected this in zanshin).
Change-Id: I4922451216e08d5d3fe36f8ba87364a361b691bf
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
A number of drawing paths were never tested by lancelot because we
always used argb32pm for subsurfaces. This patch switches the
subsurfaces to use the painter format or its alpha version. This means
changes to composition tests as it changes precision, especially of
alpha in the a2rgb30 formats.
Change-Id: I24d53bf6e1db8cca36bda69e2ddf07f20256b3c8
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
tryAcquireWithTimeout(0.2s) was already blacklisted and
now the same failed with "(2s)".
Task-number: QTBUG-58745
Change-Id: I82363238c08056d2969a7616e3a6e5af080d537d
Reviewed-by: Liang Qi <liang.qi@qt.io>
We have to use a temporary data path for winrt, as the applications
are sandboxed and cannot just put data anywhere.
Change-Id: I8f95de132e5b5ac77441cbbf26af873b8018c7cb
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
In the referenced bug report, dismissing a QFileDialog while the
Qt Virtual Keyboard was in use would result in a crash.
Dismissing a file dialog created with
e.g. QFileDialog::getOpenFileName() causes it to eventually be
destroyed. When this happens, it starts deleting its children. Each
child widget's destructor calls clearFocus(). In clearFocus(), there is
a block of code that emits QWindow::focusChanged(), passing the result
of focusObject() called on that widget's window.
QWidgetWindow::focusObject() could end up using itself as a fallback
focus object if it had no other focus objects (e.g. children) to use
instead, even though it was in the process of being destroyed; as were
all of its children. The Qt Virtual Keyboard plugin would then try to
use the focus object, even though it was in an invalid state.
To fix this problem, we return early from QWidgetWindow::focusObject()
if the window is in the process of being destroyed.
Task-number: QTBUG-57193
Change-Id: I137cf9415812ce2e0419c0afe8076ce150f248cb
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jarkko Koivikko <jarkko.koivikko@code-q.fi>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This makes the test a lot faster and perhaps more reliable.
Change-Id: I055cfde627c75f71735eabbf01af2a196bd8b00a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Packets sent to to link-local addresses on it are never received. We
don't know why this happens, as the tooling provided by Apple for
development is close to useless. So we just ignore this interface.
Task-number: QTBUG-61041
Change-Id: Ia608df1fff6bdee5238e107d8a50292a1f9e5c03
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
It was grabbing a QLabel without accounting for the size of
the window in the case where the DPI is larger than 1:
FAIL! : tst_QWidget::translucentWidget() Compared values are not the same
Actual (actual.size()) : QSize(32x32)
Expected (expected.size()): QSize(16x16)
Change-Id: I4873f3c6364ee2696f5612d91e6c97c60b2cd915
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
tst_QSharedPointer can't create a pipe as the OS has too many files
open. Systems like macOS have a lower limit to these simultaneous files
open.
Task-number: QTBUG-60410
Change-Id: I21e89f992ada2a7d09b706522a05b5952f00ec33
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This is a followup to 77a8e90cdd which
didn't handle the case where no columns had been moved.
visualIndices and logicalIndices are empty until initializeIndexMapping()
is called, in which case appending is wrong.
As a result, visualIndex(i) would return -1 for the values over
those added by read(), and an assert would happen at painting time.
The fix is to leave visualIndices and logicalIndices empty if
they are empty already, leaving it to initializeIndexMapping()
to fill them later if necessary (e.g. when moving a column).
Task-number: QTBUG-60837
Change-Id: Ia7e4b9d3122647984acd434dfaa0400df319d065
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
They have been blacklisted on windows previously and now fail on
macOS 10.12 as well.
Task-number: QTBUG-60993
Change-Id: Ib7a3acfc7f2285c0a587d4abd88a4a218391d623
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The test has been observed to be flaky on Windows. Introduce
QTRY_VERIFY_WITH_TIMEOUT for diagnostics.
Change-Id: I72abdd2e5544f8f35199876486ab15151f60e5f2
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
According to the test metrics this test failed 10 times in the last two
days. Interestingly the log shows that usually 5.5 seconds would have
let it pass.
Change-Id: I38f21f35bd6624f1d3de1e1e811a4d107136a241
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
There was only one place that needed it.
Change-Id: I067fcfe299b34ab6a771fffd14bf2945f1953d10
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
QPainterPath could in certain cases where sub-path points were on the
border of a rect fail to calculate intersects() correctly.
The patch adds handling of such cases by looking if end points cross in
or out of the rect. Other cases are already caught.
Task-number: QTBUG-31551
Change-Id: I6284da8ff8646d4636702923a76362302dde5767
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Known to fail now and then, most likely due to the mouse cursor
moving while the test is executing.
Task-number: QTBUG-60754
Change-Id: Id8f0786416d0df33f197a7a8f99b7aad1341a6be
Reviewed-by: Liang Qi <liang.qi@qt.io>
On winrt, the default application version is determined by its
manifest file. The template's default version is 1.0.0.0.
Additionally addRemoveLibPaths should not fail if libraryPaths
only contains currentDir.
Change-Id: Ifdd517f1bfe2fdf641f3d728ebe1fa144df1a8ca
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Found by GCC 7.
Change-Id: I90267617a038558e5b5213c598a949baf8d4d9be
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
CI metrics show that this test was flaky ~38 time in 3 days.
The problem is old: after we get a surface, a window manager can still
decide to re-position the window.
The fix is to simply send the touch event in a position where it is sure
to hit the window (usually the offset is the title bar height).
The blacklisting seems to not have worked, I could reproduce the failure
on a linux/xcb machine.
Change-Id: I5229fe020ba75c984fd3b6c322ad00d769707573
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This commit fixes two bugs:
1) Two ranges should not be merged if they are of different columns.
The old code would have merged (0,0) with (1, 1). Tranforming a selection
of just two indexes in a rectangle of four indexes.
2) The QItemSelectionRange appended had wrong column and worked only for
indexes of the first column. For example if 'tl' was (0, 1) than br was (0, 1)
so the QItemSelectionRange would have be ((0,1), (0, 1-1)) so ((0,1), (0,0)).
This QItemSelectionRange is invalid because topLeft columns is greater than
bottomRight column. The fix take in consideration the bottomRight column.
Task-number: QTBUG-58871
Change-Id: I591ef0bcc63926f24a7b1ced002af9b7737a4b6e
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
... and update the unittest accordingly.
Compared to the 1.8 release there is one change in freedesktop.org.xml,
the magic for application/x-java-keystore was changed from host32 to
big32, as done upstream, see https://bugs.freedesktop.org/show_bug.cgi?id=99328
Task-number: QTBUG-60608
Change-Id: I47de71c9396cfc3eabc884d5679c73a3e4850a17
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The conditions checked are compile-time conditions anyhow.
Simplify or strenghten a few conditions while at it.
Change-Id: If07f2aedca4c3632d852a8fdb2b3f7eb55a96c93
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
Backtrace logging tests were not passing for arm when -O2 option was used.
Set "-fno-inline" on for the app whose backtrace is to be inspected.
Task-number: QTBUG-59966
Change-Id: Id1bbf78c31dc524357a30c7d39c239689621b155
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The operator double() and operator long double() members of qfloat16
are causing cast ambiguities. This removes them, leaving only
operator float() which seems to be adequate.
Also, additional arithmetic operator tests were added which without
this removal fail to compile.
Change-Id: Id52a101b318fd754969b3de13c1e528d0aac2387
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They're deprecated since C++11 and removed in C++17.
Change-Id: Ia2acd9312707bfee96838743645a04ae1780e5dd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The existing QHash::operator== does not work when the same
keys appear in different order between the two hashes being compared.
However, relying on iteration order on a QHash is (as usual) a bad
idea and one should never do it.
Task-number: QTBUG-60395
Change-Id: Ifb39a6779230e26bbd6fdba82ccc0247b9cdc6ed
Reviewed-by: Lars Knoll <lars.knoll@qt.io>