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>
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>
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>
Had to teach the update program to accept category Lm as for
Joining_Transparent, for the sake of a new ArabicShaping.txt entry.
Added three new Unicode versions, several new scripts and a new
word-break class.
Updated UCD's test data for tst_QTextBoundaryFinder. This left 57
tests failing; I have commented out the data rows for those tests,
pending someone with more knowledge addressing this.
Task-number: QTBUG-79631
Task-number: QTBUG-79418
Change-Id: Ic33d3b3551195d47a84d98e84020f57a68f0b201
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The support for unsharable containers has been deprecated
since Qt 5.3.0, so let's finally remove support for them.
Change-Id: I9be31f55208ae4750e8020b10b6e4ad7e8fb3e0e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In Qt6 QList is just a typedef to QVector. To keep Qt5 behavior
compatibility we need to register aliases, otherwise some type name
based operations would not work. The patch adds automatic
registration of QList metatype alias for every QVector.
The patch doesn't cover usage of already typedef'ed and aliased
QList and QVector, but that should be quite esoteric, especially
after introduction of automatic QList and QVector type registration.
Change-Id: I84672dda2b159d94e76cdc6034861e7d7ef52533
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This is almost 100% source compatible with Qt 5. Exceptions are
* Stability of references for large or non movable types
* taking a PMF for types that are now overloaded with r-value references
in QVector
* The missing prepend optimization in QVector (that is still planned
to come for Qt 6)
Change-Id: I96d44553304dd623def9c70d6fea8fa2fb0373b0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
