This test was determined to be flaky on the CI.
Task-number: QTBUG-58713
Change-Id: Ie6e6a69b8ea625e3a3102c88d52f1f0fbec242aa
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
At 200 ms, the error on first firing could be 10 ms.
Task-number: QTBUG-58519
Change-Id: Ifaee7464122d402991b6fffd14a02a4ce782f11f
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
There was a test that tested this, but was wrong.
[ChangeLog][QtCore][QVariant] Fixed a bug that caused wrong results for
comparisons of QVariants containing either NaN or infinite numbers.
Task-number: QTBUG-56073
Change-Id: I33dc971f005a4848bb8ffffd1475d29d00dd1b7f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Under certain circumstances, VS2015 reported ambiguous options in using
the operator>(Enum,int) operator. This change adds a static_cast<qint64>
to remove any ambiguity. In the process of testing this change, a gap
in the existing logic was identified: the handling (just in the test
code) of large negative enum values. Consequently, and additional
test case was added, and additional if-conditions were added to account
for that case.
Change-Id: Ife2c471ba4caa4b9a0107722042114e58145c4d0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Implements isNull for QVariants of a nullptr so they always return
true to isNull(), instead of depending on how they were constructed.
Task-number: QTBUG-58296
Change-Id: Ibddec795cdadedef7e17d22c265c29e752d8f99f
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
C++17 adopts P0021R1[1], which makes noexcept be part of the function
pointer's type and thus be overloadable. It contains some provisions for
allowing a noexcept function pointer to cast implicitly to a non-
noexcept function pointer, but that fails in the presence of templates
and additional overloads that could match the type in question.
Fortunately, the paper proposed a test macro, so we can change our
sources now and be compatible with both C++14 and C++17 rules.
This first failed with Clang 4.0 trunk. This source incompatibility is
not our fault, it's the language's doing.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0012r1.html
Task-number: QTBUG-58054
Change-Id: I2bc52f3c7a574209b213fffd14988cf0b875be63
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
[ChangeLog][QtCore] QCoreApplication::applicationVersion now defaults to
an appropriate platform-specific value. On Windows, it defaults to the
PRODUCTVERSION parameter of the VERSIONINFO resource for classic desktop
apps, and the version attribute of the application package manifest for
Univeral Windows Platform apps. On Apple Platforms (macOS, iOS, tvOS,
watchOS), it defaults to the CFBundleVersion property of the information
property list (Info.plist) file. On Android, it defaults to the
android:versionName attribute of the AndroidManifest.xml manifest
element. On other platforms, the default remains an empty string.
Task-number: QTBUG-57715
Change-Id: I26f83dd00737e06f4321cf962aa5fab8398104ec
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We have to enable qt_safe_ftok with either sharedmemory or
systemsemaphore. In order to make the resulting QT_CONFIG work with the
bootstrap library we switch the features off for bootstrapping. Some
tests and examples have to be excluded when sharedmemory is not
available.
Change-Id: I3fc3926d160202b378be2293fba40201a4bf50c5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The prior test deemed there to be narrowing if source and destination
integral-or-enum types didn't have the same signedness; but all values
of an unsigned source type can be represented in a larger signed
destination type, so there is no narrowing in this case.
Updated QObject test-case to match.
Change-Id: I517a5997adcad70e185d7469a8d26788e463cb75
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Since the macro is now just a wrapper for std::is_enum,
its use is also deprecated.
[ChangeLog][QtCore][Global] Q_IS_ENUM is deprecated.
Use std::is_enum<>::value instead.
Change-Id: I09b9f4559c02c81f338cace927873318f2acafde
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Apparently, the CI can run something over 1000x slower than on my
machine. We're getting over 100 ms delays in operations that shouldn't
have taken more than half a millisecond. The last report was of 136%
over budget, so I multiplied the resolution by 4.
Change-Id: I9093948278414644a416fffd1474406967b2a6ee
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Consistent with other Unix platforms, and internally consistent between tests,
as a lot of tests were already applying CONFIG -= app_bundle manually.
Change-Id: Icd2b7e1c08015b26137af60ff82fddbc753f0ff4
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
By templating on the <chrono> types and unconditionally using
duration_cast to coerce the duration into a milliseconds, we
violate a principal design rule of <chrono>, namely that non-
narrowing conversions are implicit, but narrowing conversions
need duration_cast. By accepting any duration, we allow non-
sensical code such as
QTimer::singleShot(10us, ...)
to compile, which is misleading, since it's actually a zero-
timeout timer.
Overloading a non-template with a template also has adverse
effects: it breaks qOverload().
Fix by replacing the function templates with functions that
just take std::chrono::milliseconds. This way, benign code
such as
QTimer::singleShot(10s, ...)
QTimer::singleShot(10min, ...)
QTimer::singleShot(1h, ...)
work as expected, but attempts to use sub-millisecond
resolution fails to compile / needs an explicit user-
provided duration_cast.
To allow future extension to more precise timers, forcibly
inline the functions, so they don't partake in the ABI of the
class and we can later support sub-millisecond resolution by
simply taking micro- or nano- instead of milliseconds.
Change-Id: I12c9a98bdabefcd8ec18a9eb09f87ad908d889de
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
By using _MIN for signed values, and _MAX for unsigned values, we may
detect conversion issues when serializing QVariants using QSettings.
Change-Id: I3ce58ba4b93f791f75c7ae44d1fd5030f07b2f25
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The fix is trivial, but the patch adds a new QSettings tests that iterates most
of the QMetaTypes and verifies that storing and retrieving them again gives the
same value. This is a more complete test than the testVariantTypes tests, which
is limited to a subset of the QVariant types. The new tests borrows logic from
the QMetaType test machinery.
QSettings has been Q_ENUM'ified in the process, for improved debug output.
Note that on backends such as the INI backend, the metatype of the QVariant read
from the settings will be a string, so it won't match the input QVariant type,
but the result of converting that to the original value type should still work.
Task-number: QTBUG-56124
Change-Id: Ib03a26abf77c9fb449b94160d28bc4baeb095f25
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
A check "just in case" -- we don't want leaks nor crashes
due to double deletions, and so on.
Change-Id: I24f1a486f0d438595bbe352ab780b07c5d53acbd
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
It makes very little sense that one needs to have a debug build
of Qt to debug QObject issues in application code. At this date
we don't even offer debug builds for Linux systems, and anyhow
one might want to debug an application running against a
release build of Qt.
[ChangeLog][QtCore][QObject] QObject::dumpObjectInfo and
QObject::dumpObjectTree are now fully functional even in a non-debug
build of Qt.
Change-Id: Ifddd3023ffc82f3dc3928a7a94d4970e2fb1b44a
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Use the new qtConfig macro in all pro/pri files.
This required adding some feature entries, and adding
{private,public}Feature to every referenced already existing entry.
Change-Id: I164214dad1154df6ad84e86d99ed14994ef97cf4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
These tests use helpers, which are not supported on UIKit platforms.
Change-Id: I51447754dba2cd2547be05c3767e4ff3b6b5a671
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
It's like QElapsedTimer, but marks a time in the future instead.
[ChangeLog][QtCore] Added QDeadlineTimer, a counterpart to
QElapsedTimer, used to mark a time point in the future (a deadline) and
determine whether such a deadline has passed.
Change-Id: Ifea6e497f11a461db432ffff144921f7fbc1d1d3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
As it were, QStringLists were not handled explicitly when comparing
QVariants. If both QStringLists contained only a single entry, they
were treated as QStrings - if both QStringLists were empty, there were
equal (correctly so) - but if one of the QStringLists had more than
one entry, the compare function fell through to returning always 1.
As discussed here: https://stackoverflow.com/a/38492467/3444217
Added rich comparison tests for all non-numerical, non-recursive
QVariants that support them (except QModelIndex and
QPersistentModelIndex)
Task-number: QTBUG-54893
Change-Id: Icc5480d9ba056ee5efe83da566c5829caa1509d7
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
One of the good features of the new connection style is that
implicit conversion is performed for the connection arguments.
However, this is also a bad feature when it comes to the old
C remnants in the C++ language: for instance, doubles implicitly
convert to ints, possibly losing precision (and GCC/Clang do not
even warn about those under -Wall, only MSVC does) or even
triggering undefined behavior.
For this reason, when using braced initialization, C++11
disables narrowing conversions or floating/integral conversions.
Use this feature when checking the arguments of a PMF-style
signal/slot connection. Technically this makes the program
ill-formed, however GCC still accepts it (but at least
warns under -Wall).
Hence, add a way to disable these implicit conversions.
This is a opt-in and guarded by a macro, as it's a source
incompatible change.
[ChangeLog][QtCore][QObject] The
QT_NO_NARROWING_CONVERSIONS_IN_CONNECT macro has been added.
When using the new connection syntax (PMF-based) this macro
makes it illegal to narrow the arguments carried by the signal,
and/or to perform floating point to integral implicit
conversions on them. When the macro is defined,
depending on your compiler a QObject::connect() statement
triggering such conversions will now fail to compile.
Change-Id: Ie17eb3e66ce0cd780138e60d8bb7da815a4ada83
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In all other forms of disconnecting this is done. We also know the
signal index, so there is no reason not to do this.
Change-Id: Ic8b042cd8f45dbff74b42ee30c384a84bef78b20
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
[ChangeLog][QtCore][QTimer] Added support for std::chrono duration
objects for QTimer methods, like QTimer::singleShot and
QTimer::setInterval.
Change-Id: I87e17314d8b24ae983b1fffd14536e24d5b12424
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
It's really a kernel functionality, as it implements really low-level
functionality and it's used by the event dispatcher. It was in tools/
only because QTime is.
QDeadlineTimer is also coming to kernel/.
Change-Id: Ifea6e497f11a461db432ffff14491c6d9b839eb0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
...if a PMF connection had already happened. Since UniqueConnection
isn't implemented for non-PMFs (functors and lambdas aren't comparable,
even if static member functions or non-member functions are), we pass a
null pointer for comparison argument. The disconnect() code already
protected against a null pointer there, but not the connect code path
with Qt::UniqueConnection
Change-Id: I87e17314d8b24ae983b1fffd145324beced0494d
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Dario Freddi <dario.freddi@ispirata.com>
The stream in question is from prior to Qt 5.0 release, before
commit 718a2251be changed QDateTime
serialization format to store Qt::TimeSpec instead of the private
flag. The last byte was 0xff meaning LocalUnknown, but 0xff is
not valid in Qt 5.0.
It was just garbage that Qt up to now just accepted. With the upcoming
short QDateTime optimization, the results are worse.
Change-Id: I25d85d86649448d5b2b3fffd1450f57df17e7794
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Pass -xplatform macx-tvos-clang to configure to build.
Builds device and simulator by default.
Added ‘uikit’ platform with the common setup.
Also added QT_PLATFORM_UIKIT define (undocumented).
qmake config defines tvos (but not ios).
tvOS is 64bits only (QT_ARCH is arm64) and requires bitcode to be
embedded in the binary. A new ‘bitcode’ configuration was added.
For ReleaseDevice builds (which get archived and push to the store),
bitcode is actually embedded (-fembed-bitcode passed to clang). For all
other configurations, only using bitcode markers to keep file size
down (-fembed-bitcode-marker).
Build disables Widgets in qtbase, and qtscript (unsupported,
would require fixes to JavaScriptCore source code).
Qpa same as on iOS but disables device orientation, status bar, clipboard,
menus, dialogs which are not supported on tvOS.
Change-Id: I645804fd933be0befddeeb43095a74d2c178b2ba
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
QVariant::canConvert<Enum> was returning true for everything can can be converted
to integer, but not for integer itself. That's because in QVariant::canConvert
we set the targetType to Int of it's an enum, but the Int->Int case was not
on the conversion matrix. So this commits adds it to the conversion matrix
and now QVariant::canConvert<Enum> returns consistently true for int itself.
But even tough canConvert returned true, it did not actualy do any conversion
to the enum type itself. Fix that by handling the case properlt in 'convert'
[ChangeLog][QtCore][QVariant] Fixed QVariant::canConvert and conversion from
integer types to enumeration types.
Task-number: QTBUG-53384
Change-Id: I6ac066f3900e31bfcea7af77836ddfc7730bd60b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
