| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
According to qcompilerdetection.h, the Dinkumware C++ library does not
have std::initializer_list, even though the compiler supports it.
Add the missing Q_COMPILER_ guards.
Change-Id: I84a7d5054c00dba38bcde15e277ceb0ee05e6cd7
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
| |
and Q_PRIMITIVE_TYPE-come-Qt-6.
Change-Id: I97bb9add8ed0870fb70c231d6fed6abce8729434
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
The values do not need to be 2 x 32-bits. Eight bits suffice for a long time to come.
Should save 189 bytes in text size on Android builds.
Change-Id: I78e31e7caa7a698f41c66d7bbac58a766c6e8834
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
| |
The copy constructor is not disabled by any user-defined move or copy
special member function, and thus does not need to be = default'ed.
Change-Id: I90586d25756885ac77f0946c147079efb5d1b1e0
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
| |
it contains no code.
Change-Id: Ie8a43abb2db3d040f7046206adf2bf555960dd9c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
Detected by clang
Change-Id: Ia7d1bf085d838d19319ee1060dcb3c0086a510e4
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
|
|
|
|
|
|
| |
Change-Id: Id6533c8a444854f6215f6e47000875ef9751905b
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
| |
Change-Id: I7814054a102a407d876ffffd14b6a285c70b21de
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Commit d56c6cf7a4fe2b7e5543d58a786efc768b7370c2 was incorrect. It was a
nice try, but on a 64-bit Mac machine (x86_64 CPU), it returned
hw.cputype = 7, which is CPU_TYPE_X86. CPU_TYPE_X86_64 is only used in
Mach-O slices for fat binaries and does not reflect hw.cputype.
Task-number: QTBUG-61205
Change-Id: Ia3e896da908f42939148fffd14c54b3050b8e64b
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-61205
Change-Id: Ia3e896da908f42939148fffd14c46fc991650f6f
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang's definition of the __EXCEPTIONS macro is inconsistent across
platforms. When compiling for Darwin, Clang 3.6 and newer will set the
token when exceptions are enabled in either C++ or ObjC. This change
adds the reliable check described in the Clang 3.6 release notes to
ensure that QT_NO_EXCEPTIONS is defined when required.
The check requires the use of the Clang-specific __has_feature()
syntax for which a new proxy macro QT_HAS_FEATURE(x) is added in
qcompilerdetection.h
Task-number: QTBUG-61034
Change-Id: Ie7b482dfa1a4a5b700a6b97562c26b626be1fc04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Change-Id: I352c9b16077011aad1175e31ffaadfa44d2403ea
Reviewed-by: Nikola Velinov <nvelinov@ghs.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
| |
Change-Id: I3067bd7e6ae2d6d68d5232a56eaf368a0415876c
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
|\
| |
| |
| | |
Change-Id: Ia8ac1960387c0f78c32f9d0385bb0aa9a8209af1
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| | |
Change-Id: Ie8ed872547aa16a2bca2b3886d8c58bffb92b279
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
|
|/
|
|
|
|
| |
Task-number: QTBUG-60558
Change-Id: Ica9894dc9b5e48278fd4fffd14bb34c6d98d2555
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't depend on QT_HAS_INCLUDE for such an important functionality in
QtQml, so detect at configure time.
alloca() is not a POSIX function (it apparently first appeared in
Version 32V AT&T UNIX), so the actual header that defines it varies from
system to system. Clearly, if alloca.h exists, that's the one, so we try
it first. On most other systems that don't define it, it's in stdlib.h.
The only exception is Windows, where it's actually defined in malloc.h.
Task-number: QTBUG-59700
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: Icd0e0d4b27cb4e5eb892fffd14b4b2b389a4684e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
| |
We have it for a reason.
Change-Id: I84e363d735b443cb9beefffd14b8f355aeb8a31c
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
|
|
|
|
| |
Change-Id: I84e363d735b443cb9beefffd14b8b5f3885b84d6
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|
|
|
|
|
|
|
| |
ICC 17 does not yet implement C++17 [[fallthrough]] nor does it support
GCC's __attribute__((fallthrough))
Change-Id: I84e363d735b443cb9beefffd14b8aba60a7e3f81
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
|
|
|
| |
Change-Id: I4b9aad9cc2f2605a01635c2760e76fde7023f92f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit bf2160e72cd8840a8e604438cbdc807483ac980a, we can rely on
charNN_t support in all compilers except MSVC 2013, and since that
commit, we use (in 5.10, not 5.9, yet)
!defined(Q_OS_WIN) || defined(Q_COMPILER_UNICODE_STRINGS)
when we only need charNN_t, the type, as opposed to its library
support (u16string, char_traits<char16_t>, ...).
This patch splits the Q_C_UNICODE_STRINGS macro into two, adding
Q_STDLIB_UNICODE_STRINGS for when we need std::uNNstring, leaving
Q_C_UNICODE_STRINGS for when we need just charNN_t support.
In QDebug, when constructing a QChar out of a char16_t, cast to ushort
first, since QChar(char16_t) was only officially introduced in Qt 5.10.
[ChangeLog][Potentially Source-Incompatible Changes] The internal
Q_COMPILER_UNICODE_STRINGS macro is now defined if the compiler
supports charNN_t, even if the standard library does not. To check for
availability of std::uNNstring, use the new Q_STDLIB_UNICODE_STRINGS
macro.
Change-Id: I8f210fd7f1799fe21faf54506475a759b1f76a59
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
That's before the return type or static, inline, constexpr or such
keywords (if any).
Perl Script:
s/^(\s+)(.*) Q_REQUIRED_RESULT(;)?(\s*\/\/.*)?$/\1Q_REQUIRED_RESULT \2\3\4/
Change-Id: I7814054a102a407d876ffffd14b6a16182f159e2
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/global/qglobal.cpp
Change-Id: I375fa4afa662fa411a15f212ebd5f2f0dffdba7f
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QSysInfo::productType() returned "osx" for all versions of macOS, even
10.12. Change 3e2bde35786 was incorrect.
[ChangeLog][Important Behavior Changes] QSysInfo::productType() and
QFileSelector behavior on macOS was restored to match what Qt used to
return in version 5.7.0 and earlier. The behavior found in Qt 5.6.2,
5.7.1 and 5.8.0 is removed.
[ChangeLog][Future Compatibility Notice] The identifiers that
QSysInfo::productType() and QFileSelector will use to identify macOS
systems will change in Qt 6.0 to match the Apple naming guidelines which
will be current then.
Task-number: QTBUG-59849
Change-Id: Ib0e40a7a3ebc44329f23fffd14b2b39392210c4f
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I0e1a09998253489388abfffd14b611b1403a0c9f
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: Id69a70a52573241e1b6a05bd62a3fd01a8e78550
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
_mm_cvtps_ph is usually defined as a macro:
qfloat16.h:122:37: error: use of old-style cast [-Werror=old-style-cast]
Change-Id: Icd0e0d4b27cb4e5eb892fffd14b516ec47826c0c
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
|
|\|
| |
| |
| | |
Change-Id: I3bd83a839b16822035ed56a5cffe77bd6bc3f08d
|
| |
| |
| |
| |
| | |
Change-Id: Ic712654c8d4735a59bf02cf6a7e1c689ca9a886c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Turns out that different versions of ICC use different warning numbers.
The Linux and Windows compilers emit 1786, but the macOS one emits 1478.
Don't ask me why.
Change-Id: I523b0abacd5148b2bf08fffd14b475a4c4d89ba1
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/platformsupport/fontdatabases/freetype/qfontengine_ft.cpp
src/platformsupport/fontdatabases/freetype/qfreetypefontdatabase.cpp
src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.cpp
src/widgets/widgets/qtabbar.cpp
Change-Id: Iaa9daee5f7a6490d56257a3824730a35751ceb05
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we call realloc, the alignment of the new block may be different
from the old one. When that happens, we need to memmove the data to the
new position, before we start overwriting things.
Task-number: QTBUG-59804
Change-Id: I27b55fdf514247549455fffd14b07ea78918a3d0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GCC 7 defines __has_cpp_attribute even when invoked as "gcc" (possibly,
Clang does the same, according to a comment in the code, did not test
myself).
Hence, define the fallthrough declaration (as C++11 attributes)
only when compiling as C++, otherwise we pick them up even in C mode,
and they cause build failures.
Change-Id: I3f13205e014bb1dea59ee3664b29111521a7eae3
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Neither the Intel compiler nor Visual C++ have a dedicated switch to
enable F16C support, like GCC and Clang do. So we used the AVX switch
for that in commit 8241d51f7049d48912ce25fbd49ef4d22c58e340, as it was
the closest, lowest denominator. That was incorrect and insufficient.
The Intel compiler silently miscompiles the intrinsics with -xAVX,
making calls to out-of-line functions like _mm_cvtps_ph, which don't
exist. So we actually have to use AVX2 support to generate correct code.
That might be a problem later, since Ivy Bridge supports F16C but not
AVX2.
Visual C++ is able to generate F16C code with just -arch:AVX.
Either way, since there's no dedicated command-line switch, there's also
no dedicated preprocessor macro. We're using __AVX2__ for both
compilers, as that's a sufficient condition to indicate a processor that
supports F16C.
Change-Id: I27b55fdf514247549455fffd14b205b8d8b86da7
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
MSVC, Apple's Clang and Clang prior to 3.9 do not recognize _cvtss_sh
and _cvtsh_ss. So expand the operation to use directly the packed
intrinsics.
Change-Id: I27b55fdf514247549455fffd14b2046fd638593d
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
qsysinfo.h(235): error #1786: enum "QSysInfo::MacVersion" (declared at line 156) was declared deprecated ("Use QOperatingSystemVersion")
Take this opportunity to merge the two groups.
Change-Id: I27b55fdf514247549455fffd14b1c2a1d8eab869
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Aligns with EPERM (Operation not permitted) and ENOENT (No such file
or directory), and is what errno is set to on macOS when opening the
/dev/tty device when running inside e.g. Xcode, where isatty() will
return true.
Change-Id: I09b88eaa3ff611d95ab37f0ff4df9aaaca52747d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| | |
Change-Id: I79ce0b9c5eb931e238394519ba80bf35e4ff3bf7
Reviewed-by: Tasuku Suzuki <tasuku.suzuki@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Clang implements the _cvtss_sh intrinsic by way of a macro, which
uses a C99 extension and that's not allowed in C++ mode:
float16.h:119:11: error: compound literals are a C99-specific feature [-Werror,-Wc99-extensions]
/usr/bin/../lib64/clang/3.9.1/include/f16cintrin.h:76:55: note: expanded from macro '_cvtss_sh'
Reported at https://bugs.llvm.org/show_bug.cgi?id=32491.
Change-Id: I27b55fdf514247549455fffd14b170df75dd4e1f
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Also use canonical contact url.
Change-Id: I43f8c6a2c4949ee0e054045bccc17d82575b072c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
|
|\|
| |
| |
| | |
Change-Id: Icdd71e9713725bda9c305e338f5c8b41a92ed8e8
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix the condition in QWidgetPrivate::resolveLocale() to decide whether
to propagate locale: make it match setLocale_helper()'s condition when
deciding whether to propagate to descendants. This lead to a
QDateTimeEdit's calendar popup not getting told what locale to use
correctly, unless we setLocale() on it overtly, which then blocked
propagation of locale changes to it unless QDateTimeEdit manually
propagated the changes.
Fix the documentation of WA_WindowPropagation to mention locale as
also being propagated (which it was in several places, only neglecting
this one in resolveLocale).
[ChangeLog][QWidget][Qt::WA_WindowPropagation] Propagate locale
consistently, along with font and palette, within the widget
hierarchy. Previously, locale was propagated on ancestral
setLocale(), but not on creation of the descendant.
Task-number: QTBUG-59106
Change-Id: I92270f7789c8eda66a458274a658c84c7b0df754
Reviewed-by: David Faure <david.faure@kdab.com>
|
|\ \ |
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
examples/network/network.pro
mkspecs/features/mac/default_post.prf
src/corelib/io/qfilesystemengine_win.cpp
src/corelib/io/qprocess.cpp
src/corelib/io/qprocess.h
src/corelib/io/qprocess_p.h
src/corelib/io/qprocess_unix.cpp
src/corelib/io/qprocess_win.cpp
src/corelib/thread/qmutex.cpp
src/platformsupport/fontdatabases/windows/windows.pri
src/plugins/platforms/eglfs/eglfsdeviceintegration.pro
tests/auto/corelib/io/io.pro
Change-Id: I8a27e0e141454818bba9c433200a4e84a88d147e
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For the windows file system engine, we add an extra macro to use
library loading if configured to do so, but avoid it on WinRT, as
none of the symbols would be found.
We also QT_REQUIRE_CONFIG(library) in the library headers and
exclude the sources from the build if library loading is disabled.
This, in turn, makes it necessary to clean up some header inclusions.
Change-Id: I2b152cb5b47a2658996b6f4702b038536a5704ec
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Replace all QT_NO_PROCESS with QT_CONFIG(process), define it in
qconfig-bootstrapped.h, add QT_REQUIRE_CONFIG(process) to the qprocess
headers, exclude the sources from compilation when switched off, guard
header inclusions in places where compilation without QProcess seems
supported, drop some unused includes, and fix some tests that were
apparently designed to work with QT_NO_PROCESS but failed to.
Change-Id: Ieceea2504dea6fdf43b81c7c6b65c547b01b9714
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: Ie30fa13eb5f8eb44f0c9c21e9483c8aba40cec02
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
|