| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Clang 3.8 has support for __attribute__((target(xxx))) and its SIMD
headers can be included unconditionally.
Change-Id: Ic15b7ff417c8412893e5fffd14b5b42b950b48d7
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
|\
| |
| |
| | |
Change-Id: I3bd83a839b16822035ed56a5cffe77bd6bc3f08d
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The end() pointer, like in all other containers, is a sentinel value
that must never be dereferenced. But unlike array-based containers,
end() in QMap is not "last element plus one", but points to a base class
of Node, not a full Node.
Therefore, the casting from QMapNodeBase to QMapNode must not be a
static_cast, reinterpret_cast is required.
libstdc++-v3's red-black tree had the exact same problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
Change-Id: I43f05fedf0b44314a2dafffd14b33697861ae589
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
|
| |
| |
| |
| |
| | |
Change-Id: I09100678ff4443e6be06fffd1482c08125adc0a4
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
POSIX documents that localtime() ensures that tzset() has been called,
but the wording could be understood to mean that it only needs to do so
the first time. Anyway, we're sure that the MS runtime only gets the
timezone information from the Control Panel once. That means Qt-based
applications will not react to a change in the timezone.
Attempt to do that by moving tzset() out of the #if, to apply to all
operating systems.
Task-number: QTBUG-60043
Change-Id: I6ab535fb61094af19fc1fffd14b413541fe5a64c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a small table to illustrate the results exactMatch() and split
out the part on partial matching to a separate section since it
is less common.
Change-Id: Ifbd5c3cbd1d8c0ee9e8b2d58ed13f40776b03762
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some compilers are known to complain about this with a warning. GCC
complains about const on return values on -Wignored-qualifiers (enabled
at -Wextra), so it's not too much of a jump to assume that others do
too. Besides, this is not Qt Library API policy. As maintainer for
QtCore, I'm exercising my prerrogative in specifying certain unspecified
parts of the coding style, like I've done for constructor initializer
lists.
Since all the classes involved are exported (including QVector, through
derived classes), we can't remove the qualifier until Qt 6, since there
are compilers known to encode the qualifier in the mangled name
(suncc). I'm not introducing #ifdef to silence unknown compilers unless
we get an actual complaint.
Change-Id: I33850dcdb2ce4a47878efffd14a876edef843c46
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The SHA3 family is a modified version of Keccak. We were
incorrectly calculating Keccak (and even *testing* Keccak!),
but claiming it was SHA3.
To actually calculate SHA3, we need invoke Keccak on the original
message followed by the two bits sequence 0b01, cf. §6.1 [1].
[1] http://dx.doi.org/10.6028/NIST.FIPS.202
[ChangeLog][QtCore][QCryptographicHash] QCryptographicHash now
properly calculates SHA3 message digests. Before, when asked
to calculate a SHA3 digest, it calculated a Keccak digest instead.
Task-number: QTBUG-59770
Change-Id: Iae694d1a1668aa676922e3e00a292cddc30d3e0d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| | |
Change-Id: Idfa7843ef8a8e3410ae0a8cf5311b8b598299730
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
... by delegating to QConcatenable<const char[N]>.
The only thing that varied was the nested type alias 'type', which
therefore got retained.
Change-Id: I202f899034e1ddd23c6d1978a31be5eb7c195697
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
... to re-use existing buffers.
Change-Id: I7c42529b8cd4400520a59e658ab76f4f8e965cd4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
... to re-use existing buffers.
Change-Id: Ib2bc938f1cf0451c1dbc012b3db022b878e987cb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|\|
| |
| |
| | |
Change-Id: Icdd71e9713725bda9c305e338f5c8b41a92ed8e8
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a warning-turned-Werror in qdistancefield.cpp:
In member function ‘void QVarLengthArray<T, Prealloc>::realloc(int, int) [with T = bool; int Prealloc = 256]’,
inlined from ‘void makeDistanceField(QDistanceFieldData*, const QPainterPath&, int, int)’ at ../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qvarlengtharray.h:275:10:
../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qvarlengtharray.h:390:19: error: ‘void* memcpy(void*, const void*, size_t)’: specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
memcpy(ptr, oldPtr, copySize * sizeof(T));
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Apparently GCC cannot rule out that copySize may be negative in the
call to memcpy. Put GCC on the right track by adding a Q_ASSUME.
Change-Id: I63e3801e52ebe2a7f77e3a97ef03ec3869319c8c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/plugins/platforms/eglfs/eglfs-plugin.pro
Change-Id: Id76cdbb41b7758572a3b8ea4dcb40d49bac968db
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit e0ea0f6178c9dbee2a8c888fde84ad1cd9670c6b optimized QChar <->
QString(Ref) comparisons by adding more overloads to avoid creating
QStrings from QChars just to compare them.
But these new overloads made existing comparisons to QChar ambiguous.
This was known at the time for QChar/int comparisons.
It has since turned out that also comparing to '\0' is ambiguous,
ie. not comparing to int or char per se is ambiguous, but comparing to
nullptr constants is, because QString(const char*) is just as good a
candidate as QChar(char)/QChar(int).
Since we allow QString/QChar comparisons, it seems logical to solve
the problem by adding QChar<->nullptr overloads.
[ChangeLog][QtCore][QChar] Disambiguated comparisons with nullptr
constants such as '\0', which 5.8.0 broke. As a consequence,
QChar<->int comparisons are no longer deprecated, as this was a failed
attempt at fixing the ambiguity.
Change-Id: I680dd509c2286e96894e13078899dbe3b2dd83bc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The constructor is not only disabled under QT_NO_CAST_FROM_ASCII,
but also under QT_RESTRICTED_CAST_FROM_ASCII.
Change-Id: I7bbaf2891913d5256dff7f80c49075ea3326155a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a later month-or-day were to have a name that's a prefix of an
earlier one's name, the code would have selected the longer name as
best match when the text matched is the shorter name, simply because
it found that one first. (Found, on Turkish Cuma(rtesi)? in Thiago's
recent new test, by reversing the loop that iterated the list.)
Make an exact match win and a match of a full name beat any prefix
match of the same length.
Change-Id: I8d954b83ccc25e4f47af2e558036d714685cef5e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Decouple from the callers' offset into a larger list; just search for
an entry in a list, let the caller deal with the offset. Also, defer
a .tolower() to save the need to allocate a copy of each list entry.
Change-Id: I748d5214c2cc6dc592fe2bd41e3f8150f71c335b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Simplifies everything and avoids bugfixes in one not propagating to the
other.
Change-Id: I95c9e502ccc74af3bcf0fffd14a69f0cde60cc8c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The only allowed way to access the variable is now via the public
qGlobalQHashSeed and qSetGlobalQHashSeed functions. The variable was
private API, so we're allowed to remove it.
Task-number: QTBUG-47566
Change-Id: I4a7dc1fe14154695b968fffd14abd331e5810482
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
|
| |
| |
| |
| |
| | |
Change-Id: Ifc3f481ddb902b26c217516412c93a4a39a32b1c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Re-use methods of QStringRef.
Change-Id: I5ff719c08c54246e9cafd4f9aa0823ff6df8433b
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
It won't be for very much longer.
Change-Id: I30e3e0cd8c8ecf0833f759557382a3ded7bdea34
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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
|
| |
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-57649
Change-Id: I15b62e0f9cec482fbb40fffd1490d802c54bf0fe
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QLocale::matchingLocales() simply created each locale using the basic
data, without (unless the matching conditions stipulated Language C)
applying number-options hacks that it applies everywhere else, when
creating the C locale. Thus the C locale in its returned list (if it
wasn't the only entry) ended up with the default number options,
without omiting separators in numbers. Thus QLocale::c() didn't
actually appear as an entry in the list. Discovered while
investigating QTBUG-58947.
Added a dumb autotest that checks various ways of getting the C locale
do actually give us equal locale objects. Fixed matchingLocales() to
apply the same hack as is used elsewhere for the C locale.
Change-Id: I263f31da623052b63171f5b5a83c65802383df21
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes compiling an application using QVector and -Wshorten-64-to-32
on a 64-bit system without getting this warning:
... 5.8/clang_64/lib/QtCore.framework/Headers/qvector.h:695:18:
warning: implicit conversion loses integer precision: 'typename
iterator_traits<QString *>::difference_type' (aka 'long') to 'int'
[-Wshorten-64-to-32]
int offset = std::distance(d->begin(), before);
~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... 5.8/clang_64/lib/QtCore.framework/Headers/qvector.h:731:35:
warning: implicit conversion loses integer precision: 'long' to
'const int' [-Wshorten-64-to-32]
const int itemsToErase = aend - abegin;
~~~~~~~~~~~~ ~~~~~^~~~~~~~
... 5.8/clang_64/lib/QtCore.framework/Headers/qvector.h:740:39:
warning: implicit conversion loses integer precision: 'long' to
'const int' [-Wshorten-64-to-32]
const int itemsUntouched = abegin - d->begin();
~~~~~~~~~~~~~~ ~~~~~~~^~~~~~~~~~~~
Change-Id: I52d85908f4aac20c7e9ac8063ac760ce52f85541
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-59159
Change-Id: I95c9e502ccc74af3bcf0fffd14a69e0cd27ce96b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes compiling an application using QList and -Wshorten-64-to-32
on a 64-bit system without getting this warning:
... 5.8/clang_64/lib/QtCore.framework/Headers/qlist.h:897:26:
warning: implicit conversion loses integer precision: 'long' to 'int'
[-Wshorten-64-to-32]
int removedCount = e - n;
~~~~~~~~~~~~ ~~^~~
Change-Id: I688ed086805c431821c2ee6078fa5aeb631e7a07
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unlike setTimeSpec, this forgot to clear the bit when detaching. So it's
possible that some further use of the flags could incorrectly conclude
that the data was short and then proceed to corrupt the pointer.
The example from QTBUG-59061 caused this because toUTC() -> toTimeSpec()
calls setMSecsSinceEpoch which left the bit set; then addDays() calls
setDateTime(), which calls checkValidDateTime() and that corrupted the
pointer. This problem was more visible on 32-bit systems because no
QDateTime was short (except for default constructed ones), but it
can happen on 64-bit with sufficiently large dates.
Task-number: QTBUG-59061
Change-Id: Ibc5c715fda334a75bd2efffd14a562a375a4e69b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's a Qt 3 compatibility vehicle, and as such inherits the now-alien
property to distinguish empty and null strings. Particularly worrisome
is the following asymmetry:
QString("") == QString::null // false
QString("") == QString(QString::null) // true
Instead of fixing this behavior, recognize that people might use it as
a weird way to call isNull(), albeit one that once was idiomatic, and
simply deprecate everything that deals with QString::null.
[ChangeLog][QtCore][QString] QString::null is now deprecated. When
used to construct a QString, use QString() instead. When used to
compare to a QString, replace with QString::isNull().
Change-Id: I9f7e84a92522c75666da15f49324c500ae93af42
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The data is 256 bytes, so might as well align it on a 16-byte boundary
to facilitate copying (if that happens). We should consider similar for
QByteArrayMatcher in 6.0.
Change-Id: I74966ed02f674a7295f8fffd14a8c64526d734bb
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
|
| |
| |
| |
| |
| |
| | |
Change-Id: I74966ed02f674a7295f8fffd14a8c6389da538c1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Latest PCRE2 versions require a macro to be defined before
including pcre2.h, so do it.
Task-number: QTBUG-59226
Change-Id: I472ff557e29d1212fdcd99454778551323be4d4b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
Requires no further changes.
Change-Id: Ib280fa69a752aefa1c29fc5f0eb292e99b96270a
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Improves performance when appending temporaries, esp. since
the aliasing fix in the lvalue overload in 0f730ef made that
overload correct, but a bit slower across reallocs.
The unit tests already also pass rvalues, so the function is
covered in the existing tests.
[ChangeLog][QtCore][QVarLengthArray] Added rvalue overloads
of append() and push_back().
Change-Id: If3a6970f03a160cba5b42d33d32d3d18948f6ce3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
mkspecs/features/moc.prf
Change-Id: Ia71c8e3b3185f7c999bf226d0675051b10b8740b
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix a couple incorrect references to the integer precision classes.
Update snippet to use floating point precision classes.
Task-number: QTBUG-51630
Change-Id: I9b08cfb68937a8e1179ee414d7981956ef7bc106
Reviewed-by: Martin Koller <kollix@aon.at>
Reviewed-by: Michael Brüning <michael.bruning@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The QSystemLocale constructor remembers the most-recently-constructed
instance - a dodgy enough proposition at the best of times - and
shares it with much of the rest of QLocale. There is a global static
instance, actually of a derived singleton class, to which it is
usually set on program start-up. However, the constructor deleted the
remembered instance before remembering any new instances; there was no
way this could not lead to bad consequences. So let's not do that.
Change-Id: Ie8f3d655c9d4f75f6ec00a5861d98d6020ecc633
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The this pointer cannot be null, so we can't do d->staticFunction while
d is a null pointer. This was caught by Clang 3.8's ubsan.
Change-Id: I3c0d39b88cca83d827a69ed1544a4412b18ac907
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The _next variable need the acquire and release fence in next()
to synchronize with the equivalent operations in release() (which
already have the them)
The ordering on the _v[block] is not enough as this does not
synchronize the same object.
Task-number: QTBUG-58917
Change-Id: I17cc39e6791433348b6227363dbea92bcf03700d
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Like the lvalue QVector::append() overload, when we reallocate,
we need to take a copy of the function's argument because the
reference will get stale upon reallocation.
Add a test.
[ChangeLog][QtCore][QVarLengthArray] Fixed a bug involving
appending an item already in the container to the container
again.
Change-Id: I06eeed6cb383dd5924e47a302bb3d1666d04c8e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Remove the dead QByteArray(data, size) fall-back. We've been
requiring lambdas since Qt 5.7.
Change-Id: I4d9023ab4583f2ee80a74a828fba0d95c2fdb0df
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's only used in the autotests, and it private API, so
downgrade from Q_CORE_EXPORT to Q_AUTOTEST_EXPORT.
Fix a use of QTimeZonePrivate functions unprotected by
QT_BUILD_INTERNAL in tst_qtimezone.cpp.
Change-Id: I70eaea06f8fcf2983aeafb6894c3a5d2a4b272a7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's nothing wrong with cloning a const QTimeZonePrivate, so make
clone() const.
Also, if you're cloning a QTzTimeZonePrivate, you already know that
you get a QTzTimeZonePrivate back. C++ supports covariant return types
for this reason, so use them.
Change-Id: I60e19e89b1b7bad080c552f1baca314ab0a6295e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Don't init m_icu with 0. It's a QSharedDataPointer, which inits to
nullptr anyway.
- The copy ctor didn't do anything out of the ordinary, so = default it.
It's also only used in the implementation of clone(), so make it private.
Removes three #if QT_CONFIG blocks.
We can't use ctor delegation here, because systemTimeZoneId() is a
virtual function.
Change-Id: I2cd06c3349686b6f21c897acb5c12185a36d5b9f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
MSVC 2013 complained:
src/corelib/tools/qbytearraymatcher.h(143) : warning C4351: new behavior: elements of array 'QStaticByteArrayMatcher<6>::m_pattern' will be default initialized
Fix the same way as 9a07ab9234ccb4ed0d6aa3a64b4b2c888635dae5: by suppressing
the warning.
Change-Id: Ic41f7eabe7e39709d76e6062f5891cdcfaa6e1ed
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|