Conflicts:
src/corelib/tools/qvector.h
Make QVector(DataPointer dd) public to be able to properly merge
5b4b437b30 from 5.15 into dev.
src/widgets/kernel/qapplication.cpp
tests/auto/tools/moc/allmocs_baseline_in.json
Done-With: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Change-Id: I929ba7c036d570382d0454c2c75f6f0d96ddbc01
It used to be "iterator", causing a qdoc warning:
src/corelib/serialization/qjsonobject.cpp:1405: (qdoc) warning: clang found diagnostics parsing \fn int QJsonObject::const_iterator::operator-(const_iterator other) const
error: out-of-line definition of 'operator-' does not match any declaration in 'QJsonObject::const_iterator'
Add a small test.
Change-Id: Id65effffa720ed1e0fb0ee6937dcc4298f3ef363
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
In Qt6 there is a behavior change with extra stuff after the seconds -
it's no longer allowed and will result in an invalid QTime.
This was introduced with bf65c27789 but
the autotests were not adjusted for it.
Change-Id: Ia78f4f2a8019e46d9d0e8e8b8918a3ab2d4638e2
Reviewed-by: Liang Qi <liang.qi@qt.io>
If a type has both a converter to QVariantList and to
QSequentialIterableImpl registered, we would have chosen the
QSequentialIterableImpl version. In the case of types like QJSValue,
this is more costly. With this change we therefore uses the direct
conversion if it has been registered.
The same applies to QAssociativeIterableImpl and
QVariantHash/QVariantMap.
Change-Id: I9c0b5068efe4bfbc5e0598a200e6db59201e9974
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
It makes sense for it (instead of triggering the QAbstractItemModel
base class implementation, which doesn't do anything). Safe to override
virtuals in this case -- code calling the old version could not do
anything useful, so at least new code gets those functions properly
implemented for free.
Change-Id: Iefe1ff25e15d877435e93ab28289ad2579616f72
Task-number: QTBUG-48076
Reviewed-by: Luca Beldi <v.ronin@yahoo.it>
Reviewed-by: David Faure <david.faure@kdab.com>
Add a light-weight associative container, API-wise very similar to QMap,
that's based on two sorted continuous containers (QVector by default).
The class is internal for now.
Change-Id: Ife12576c4abb39a3ea2acb0a1ba0faca91b3a4c5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
In Qt6 there is a behavior change with extra stuff after the seconds -
it's no longer allowed and will result in an invalid QDateTime.
This was introduced with bf65c27789 but
the autotests were not adjusted for it.
Change-Id: Iee6a9a7ac6cbb2754a68e082bb7074d17fac9d9c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When QLocale::Country is set to QLocale::India numbers are written so that
after first three from the right and then after every second will be comma.
E.g. 10000000 is written as 1,00,00,000
Task-number: QTBUG-24301
Change-Id: Ic06241c127b0af1824104f94f7e2ce6e2058a070
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Reviewed-by: Teemu Holappa <teemu.holappa@qt.io>
QString(View)s can be built or manipulated in ways that make them
contain/refer to improperly encoded UTF-16 data. Problem is,
we don't have public APIs to check whether a string contains
valid UTF-16. This knowledge is precious if the string is to be fed in
algorithms, regular expressions, etc. that expect validated input
(e.g. QRegularExpression can be faster if it can assume valid UTF-16,
otherwise it has to employ extra checks).
Add a function that does the validation.
[ChangeLog][QtCore][QStringView] Added QStringView::isValidUtf16.
[ChangeLog][QtCore][QString] Added QString::isValidUtf16.
Change-Id: Idd699183f6ec08013046c76c6a5a7c524b6c6fbc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It is useful to use an array of bit as an integer value.
I add also a prarameter to set endianness when converting
value to UInt32.
[ChangeLog][QtCore][QBitArray] Added toUInt32() to return
the bit array's value as a uint32_t.
Change-Id: I9d8c7a33f11e7ce94cb67aa9a50b11fa42d56168
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QStringListMode::moveRows() had an issue when the destination was before
the source row.
Change-Id: Icf64e5b4cdd6a39faf3ba4ccc3883196b247ccbd
Reviewed-by: Luca Beldi <v.ronin@yahoo.it>
Reviewed-by: David Faure <david.faure@kdab.com>
We're now using the same infrastructure for QVector,
QString and QByteArray.
This should also make it easier to remove the shared null
in a follow-up change.
Change-Id: I3aae9cf7912845cfca8e8150e9e82aa3673e3756
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
QItemSelectionModel::columnIntersectsSelection() should honor the parent
according to the docs. For rowIntersectsSelection() this was fixed a
long time ago but columnIntersectsSelection() was forgotten.
Sync the both functions and use range-based for loops as a drive-by.
Fixes: QTBUG-80644
Change-Id: Iaf08f85e2225204d1e6564fa4bb0bc826352ed53
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
As opposed to unite(), this inserts one map into the other
without duplicating elements.
Task-number: QTBUG-35544
Change-Id: Ie8ab350b29148851a3176cef1007e8a4ca82c273
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We did some changes in the .cpp files of some tests when converting
the build system to CMake, but didn't adjust the .pro files which
caused tests to fail when doing a qmake build.
Make the required changes. Was discovered when doing a test
wip/cmake -> dev merge.
Change-Id: I407a982412cb44df592a38a4cb997968bdfe3304
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This flag is used in QSequentialIterable and QAssociativeIterable to indicate
that the data pointer in VariantData should be deleted after the variant has
been constructed.
The use case for this is
https://codereview.qt-project.org/c/qt/qtdeclarative/+/284151, where we have
a proxy iterator and cannot easily return a pointer to already owned data, as
it is hard to manage its lifetime in the iterator. In contrast, it is clear
that we can release the memory in the QSequentialIterable functions, as it has
already been copied into the QVariant there.
Change-Id: I2b33497d991cd4f752153e0ebda767b82e4bb851
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This saves us from having to bootstrap rcc in regular (non-cross)
compilations, as it can now link to QtCore. Actually un-bootstrapping
rcc is left as an exercise for the reader.
This commit discovered that MSVC cannot handle constexpr arrays bigger
than 256 kB, at which point it simply starts claiming that the constant
expressions using it are not constexpr. ICC has a similar problem at
64 kB, but it tells you why ("note: type "const unsigned char [65537]"
too large for constant-expression evaluation").
Note also that this requires gzip or zstd to be in PATH for compression
to happen. RCC linked to zlib, which is always present due to the
bundled copy. gzip's presence is not likely to be a problem on Unix
systems, but could be for Windows users, especially MSVC ones. If gzip
is not present, QtCore's size will increase by about 1910 kB of
read-only (sharable) data.
Change-Id: I2b1955a995ad40f3b89afffd15a3e65a94670242
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
ISO date format doesn't allow spaces within a date, although 3339 does
allow a space to replace the T between date and time. Sixteen tests
added to check this all failed. So clean up the handling of spaces in
the parsing of ISO date-time strings.
[ChangeLog][QtCore][QDateTime] ISO 8601: parsing of dates now requires
a punctuator as separator (it previously allowed any non-digit;
officially only a dash should be allowed) and parsing of date-times no
longer tolerates spaces in the numeric fields: an internal space is
only allowed in an ISO 8601 date-time as replacement for the T between
date and time.
Change-Id: I24d110e71d416ecef74e196d5ee270b59d1bd813
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
even if we are currently inside processEvents (apparently called manually
and not from QEventLoop::exec()). A carefully crafted application
(see, for example, the linked QTBUG or even updated auto-test)
can trigger itself into failing to exit the current (potentially nested)
event loop. We can harden our Cocoa event dispatcher to detect
such condition and properly propagate 'interrupt' to where it'll
do its job, indeed, interrupting the real event loop (aka [NSApp run]).
This mainly means we have to undo what bool blocker would erroneously do.
Also, long live (as people love to say these days) to another tricky
(somewhat) auto-test (surely, it's not flaky!).
Fixes: QTBUG-79477
Change-Id: I794f0cda23e24d36be67f2bb63d52b74be057c31
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Preparations to move QString over to use QArrayDataPointer instead
of it's own private struct.
Change-Id: I7796a595393394083f6a85863e3c710ebbdea149
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The goal here is to move things over to QArrayDataPointer. This prepares
for it.
Change-Id: I32f54a47594274799600c618f7341c200ceaa306
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
We already detach immediately since change
c2d2757bcc. That basically removes
the main purpose of having QChar/ByteRef, and we can just as well
get rid of those classes for Qt 6.
Change-Id: I8dc566a1948ddc29c0cb8a77ec7310654a7219a4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
That allows us to pass by value for all fundamental and pointer types.
This requires some magic to remove methods taking a T&& to avoid
ambiguous overloads for QVector<int/qsizetype>. Remove them for all
cases where parameter_type is T, as copying or moving will do
exactly the same thing for those types.
Change-Id: I8133fecd3ac29bb8f6ae57376e680bc3d616afbf
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Those members are not required anymore and now part of the
object itself.
Change-Id: If9eb5355ca8f2cf9528f6f63ca4e172acc9f9aed
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Don't store our string data as QByteArrayLiterals anymore, but revert
back to simply storing them as an array of char* and offsets into that
array.
This is required to be able to inline size and begin into QByteArray
itself. Once that change is done, we can then avoid creating copies of
the string data again.
Change-Id: I362a54581caefdb1b3da4a7ab922d37e2e63dc02
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
I'd have preferred to use QArrayDataPointer<ushort> for QString, but
that option wasn't the best one. QArrayDataPointer try to do some
operations using QArrayDataOps and that would expand to unnecessary
code. What's more, the existing code expected to be able to modify and
access the d pointer.
Instead, this commit introduces QStringPrivate (named differently from
QStringData to catch potential users), which contains the three
members. This POD class is also used in QJsonValue to store the
"inlined" QString. QHashedString in qtdeclarative will need a similar
solution.
Change-Id: I33f072158e6e2cd031d4d2ffc81f4a8dbaf4e616
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Add QGenericArray to simplify operations. This class can be shared by
other tool classes. If there is nothing else to share it, we can move
the code onto qvector.h. The one candidate is QList.
All tests pass and valgrind is good.
Change-Id: Ieaa80709caf5f50520aa97312ab726396f5475eb
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This test hardcodes the allocation behaviour instead of testing what
it should be testing. Unfortunately, it can't test the actual problem
directly since the problem was "it crashed when using vectors with 1
billion elements".
Change-Id: Iec6a26ae490b8fdd4a7db1269e3bae85fc77ee52
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This requires that the allocation functions return two pointers: the d
pointer and the pointer to the actual data.
Ported QArrayDataPointer & SimpleVector to the inlined size & data.
For now, the size and offset members are not yet removed from
QArrayData, to let QVector, QByteArray and QString compile unmodified.
Change-Id: I8489300976723d75b8fd5831427b1e2bba486196
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Instead of using the reference count to store whether the data is
sharable and whether the header is immutable, move the settings to the
flags member. This allows us to save one comparison per deref() or
needsDetach(). It also allows for the possibility of mutable data
pointed to by a static header.
Change-Id: Ie678a2ff2bb9bce73497cb6138b431c465b0f3bb
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The next change will stop using some values in the reference counter as
settings from the data.
Change-Id: I94df1fe643896373fac2f000fff55bc7708fc807
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The Mutable flag now contains the information on whether the data this
QArrayData points to is mutable. This decouples the mutability /
immutability setting from the allocation and from the type of data,
opening the way for mutable raw or foreign data.
There are still plenty of places in the source code that check the
size of the allocation when it actually wants d->isMutable(). Fixing
this will require reviewing all the code, so is left for later.
The needsDetach() function is moved to QArrayData and
de-constified. It returns true when a reallocation is necessary if the
data is to be modified.
Change-Id: I17e2bc5a3f6ef1f3eba8a205acd9852b95524f57
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
These flags allow us to determine what type of data QArrayData is
carrying. There are currently only two supported types:
- raw data type: constructed via fromRawData or static data
- allocated data type: regular data done via heap allocation
The QArrayData object is usually allocated on the heap, unless its own
reference count is -1 (indicating static const QArrayData). Such
object should have a type of RawDataType, since we can't call free().
Add GrowsBackward for completeness as well as the StaticDataFlags
default for static data.
Change-Id: Icc915a468a2acf2eae91a94e82451f852d382c92
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In almost all cases, use d->allocatedCapacity() or
d->constAllocatedCapacity() instead of d->alloc, since they do the
same thing (right now). In the future, the functions will be
changed. There is a separate const version because most const code
should not need to know the allocation size -- only mutating code
should need to know that
There are a few cases where d->alloc was replaced with a better
alternative, like d->size. The one case that remains in the code will
be replaced by a different test when it's available.
Change-Id: I48135469db4caf150f82df93fff42d2309b23719
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Instead of stealing one bit from the alloc field, let's use a full
32-bit for the flags. The first flag to be in the field is the
CapacityReserved (even though the allocate() function will store some
others there, not relevant for now).
This is done in preparation for the need for more flags necessary
anyway.
Change-Id: I4c997d14743495e0d4558a6fb0a6042eb3d4975d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Rename to QArrayData::ArrayOptions in preparation for these flags
being in the array itself, instead of used just for allocating new
ones.
For that reason, rename QArrayData::Default to
DefaultAllocationFlags. And introduce QArray::DefaultRawFlags to mean
the flags needed for creating a raw (static) QArrayData.
Also rename QArrayData::Grow to GrowsForward, so we may add
GrowsBackward in the future.
Change-Id: I536d9b34124f775d53cf810f62d6b0eaada8daef
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The test passed mostly by accident so far, as the created QByteArray
was shorter than what the test assumed.
Change-Id: I06858801d83a504eadc73ec2be281c88f8ffad5d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In prevision to Qt6 which is going to discourrage the use of the integer id,
add some missing API to the staticless QMetaType API:
- Add a way to construct a QMetaType from a type without calling qMetaTypeId:
QMetaType::fromType<T>()
- Add equality operators
- Add a QMetaType::name() function
- Add a default constructor (by adding a default parameter to the existing ctor)
Change-Id: I95487c1c31bdf0d773717daa9d5452cbced30673
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Since I can't #include qobjectdefs from qnamespace because of circular dependency,
move the Qt macro in the qtmetamacros.h header.
Deprecate QObject::staticQtMetaObject since now one can just use Qt::staticMetaObject
Change-Id: I11982aa17c2afa2067486b113f8052672f3695eb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Cite RFC 3339 as basis for allowing a space in place of the T, too.
The RFC mentions that ISO 8601 accepts t and z for T and Z, so test
for them case-insensitively. Add a test for this.
Change-Id: Iba700c8d74d485df154d27300aab7b1958e1ccef
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If milliseconds were followed by a space, the space was included in
the count of "digits" read as the fractional part; since we read (up
to) four digits (so that we round correctly if extras are given), a
harmless apce could cause scaling down by too large a power of ten.
Since QString::toInt() ignores leading space, we were also allowing
interior space at the start of the milliseconds, which we should not,
so catch that at the same time. Added tests, including one for the
rounding that's the reason for reading the extra digit, when present.
Fixes: QTBUG-80445
Change-Id: I606b29a94818a101f45c8b59a0f5d1f78893d78f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDateTime is a friend of QTimeZone, so can access its internals; but
it must check the zone is valid before doing so.
Expanded tst_QDateTime::invalid() and made it data-driven to catch the
failure cases.
Commented on a test-case that caught a mistake in my first attempt at
this, and on QDateTimeParser's surprising reliance on a quirk of
QDateTime::toMSecsSinceEpoch()'s behavior.
Fixes: QTBUG-80146
Change-Id: I24856e19ff9bf402152d17d71f83be84e366faad
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
QByteArray::fromBase64 was liberal in its input, simply skipping
over invalid characters. As a side-effect of this, it had
no error reporting, meaning it could not be used to convert
fromBase64 _and_ validate the input in one go.
Add more option flags to make fromBase64 strictly validate
its input. Since we want to know whether it has succeeded
or not, and the existing fromBase64 overloads do not
allow for that, introduce a new function that returns
an optional-like datatype.
While at it: base64 decoding can be done in-place; add an
rvalue overload to enable this use case.
[ChangeLog][QtCore][QByteArray] Added the new fromBase64Encoding
function.
[ChangeLog][QtCore][QByteArray] Added new flags to make
fromBase64 / fromBase64Encoding strictly validate their input,
instead of skipping over invalid characters.
Change-Id: I99cd5f2230f3d62970b28b4cb102913301da6ccd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We forgot to reset the flags when replacing the element, so we ended up
with an integer with HasByteData after:
testMap[0] = QStringLiteral("value");
testMap[0] = 42;
Fixes: QTBUG-80342
Change-Id: Ia2aa807ffa8a4c798425fffd15dabfa066ea84b0
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
As opposed to unite(), this inserts one hash into the other
without duplicating elements.
Change-Id: Ifc786c48f5dc3ab18c29782e73eac3c1a3ef8981
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
macOS fails to create a zone for the name its own systemTimeZone
claims to have (see new comment). So make sure we do consistently
recognize the name systemTimeZoneId() returns, using systemTimeZone
from which we got its name.
Add minimal testing of system time-zone.
Fixes: QTBUG-80173
Change-Id: I42f21efbd7c439158fee954d555414bb180e7f8f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The ones we reject used a zero offset while the one that does parse
(though it shouldn't - revised comment) has a one hour offset. Made
them all use that offset and added a partner test that has no invalid
characters, so ensure the success of the invalid character tests isn't
due to falsely rejecting the valid date/time text to which the invalid
characters are added.
Task-number: QTBUG-80038
Change-Id: I6e3dd79b981af6803e60877229c56599cfd719cb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The qdatetime implementation's rfcDateImpl() uses regexes which did
not match its comments; nor did either the regexes or the comments
match what was documented. A review of relevant RFCs suggests we
should revise this in future, probably at Qt 6.
The documentation also only addressed the formats recognized when
parsing a date-time, without indicating how they are serialised or how
dates and times are handled separately.
Added a note to the tests for the read-only formats, to remind the
reader that the RFCs merely recommend recognising these - be
permissive in what you expect and strict in what you deliver.
Change-Id: I0f0bec752e7a50bde98cceceb7e0d11be15c6a6f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We already did that when parsing from CBOR binary data, so the code was
already present.
[ChangeLog][QtCore][QCborValue] The constructor taking a CBOR tag and a
value to be tagged now attempts to convert to a QCborValue extended
type. For example, if the tag is 0 (UnixTime_t) and the payload is a
number, the resulting object will become tag 1 (DateTime) and the
payload will be the the ISO-8601 date/time string.
Fixes: QTBUG-79196
Change-Id: I6edce5101800424a8093fffd15cdf650fb2fc45c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This was used to support QFlags f = 0 initialization, but with 0 used
as a pointer literal now considered bad form, it had been changed many
places to QFlags f = nullptr, which is meaningless and confusing.
Change-Id: I4bc592151c255dc5cab1a232615caecc520f02e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Allegedly Apple has fixed the bug that made this necessary, so we
should be able to include these two test-cases once more.
This reverts commit ba9585bd02.
Fixes: QTBUG-69875
Change-Id: I5ac6019c0d647691eda6cdbb2a53e7471859d4a3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Android uses its own time-zone naming, which includes a zone called
"Canada/East-Saskatchewan", whose second component is 17 characters
long. This violates a rule in the IANA naming scheme for zones, that
limits components to 14 characters each. So tweak the isValidId()
check to allow Android its long names.
Android has added Outer Mongolian time-zones, which are as borked as
many others in 1970, so blacklist those transitionEachZone() tests.
Fixes: QTBUG-69128
Change-Id: I46f674f095431335b16900860d83b624257ae3bb
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
They were tucked away in the back-end of the isTimeZoneIdAvailable()
test, but a separate isValidId() test had been added more recently,
which made some (arguably all) of them redundant. Reworked this test
in the process, so that the QSKIP() happens in _data() once instead of
in the test that's never run because there are no data rows.
Change-Id: Icaa6227ace9a1aa944d085691cdcfb3adf4a51dc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
On NTFS, a junction point can be created and deleted by the mklink and
rmdir commands, respectively. If a directory is not identified
correctly as a junction, then applications will likely try to remove
it using recursive methods, leading to fatal data loss.
With this change, Qt can identify file system entries as junctions,
allowing applications to use the correct file system operation to
remove it.
The test needs to delay the cleaning up of junctions and files it
creates until the checks are complete; since they might fail and make
the test function return prematurely, use a scope guard.
[ChangeLog][QtCore][QFileInfo] Add QFileInfo::isJunction so that
applications can recognize NTFS file system entries as junctions
Task-number: QTBUG-75869
Change-Id: I3c208245afbd9fb7555515fb776ff63b133ca858
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Fixes parsing writing and pass-through of integers with
higher precision than double can handle.
Note this adds extra precision compared to JavaScript, but the
JSON files read and written this way are still valid, and the extra
precision in reading and writing this way is used by many JSON
libraries.
Fixes: QTBUG-28560
Change-Id: I30b2415c928d1c34c8cb4e4c6218602095e7e8aa
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is no excuse for copying several KiBs of data just to iterate
over it, yet that's exactly what Q_FOREACH does.
Besides, this use of Q_FOREACH is being deprecated. In my tree, it's
already a hard error.
Change-Id: I07240c37626f7d284781e8c4be05eef3c7a54f39
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The assumption when calling QStringRef::toString() on a null
QStringRef (i.e. when QStringRef::isNull() is true) is that
QStringRef::toString().isNull() will also return true. With the
current implementation we return a null QString() only when the
QStringRef references a nullptr QString. We need to do the same
also when QStringRef references a QString with null private data.
Change-Id: I4177a5ea187ae758d7c46fe76a9d0583140e90cb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The concept was a nice idea to avoid accidental detach() calls
in implicitly shared containers, but it conflicts with a C++11
compatible API for them, with signatures for modifying methods
taking a const_iterator as argument and returning an iterator
(e.g. iterator erase(const_iterator)).
Change-Id: Ia33124bedbd260774a0a66f49aedd84e19c9971b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
