This avoids ambiguities in our API when someone e.g. writes
vector.insert(0, ...).
It requires a slight workaround in qlalr, where std::search()
for libc++ doesn't like that our difference_type is qsizetype.
Change-Id: I40aa1040781ffbdd12d04410078207969b3bde53
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove the last places where those got used and avoid
allocations when we resize to 0.
Change-Id: Ib553f4e7ce7cc24c31da15a55a86d18bdf1cc5c3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As a side effect, data() can now return a nullptr. This
has the potential to cause crashes in existig code. To work
around this, return an empty string from QString::data()
and QByteArray::data() for now.
For Qt 6 (and once all our internal issues are fixed), data()
will by default return a nullptr for a null QString, but we'll
offer a #define to enable backwards compatible behavior.
Change-Id: I4f66d97ff1dce3eb99a239f1eab9106fa9b1741a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is no reason for keep using our macro now that we have C++17.
The macro itself is left in for the moment being, as well as its
detection logic, because it's needed for C code (not everything
supports C11 yet). A few more cleanups will arrive in the next few
patches.
Note that this is a mere search/replace; some places were using
double braces to work around the presence of commas in a macro, no
attempt has been done to fix those.
tst_qglobal had just some minor changes to keep testing the macro.
Change-Id: I1c1c397d9f3e63db3338842bf350c9069ea57639
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QString and QStringRef did bounds checking for left/right/mid, whereas
QStringView was asserting on out of bounds.
Relax the behavior for QStringView and do bounds checking on pos/n
as well. This removes a source of potentially hidden errors when porting
from QStringRef (or QString) to QStringView.
Unfortunately, one difference remains, where QByteArray::left/right()
behaves differently (and somewhat more sane) than QString and
QStringRef. We're keeping the difference here, as it has been around
for many years.
Mark left/right/mid as obsolete and to be replaced with the new
first/last/slice methods.
Change-Id: I18c203799ba78c928a4610a6038089f27696c22e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The trait is deprecated in C++17 and removed in C++20. Enforce
the same meaning by using a constexpr variable instead.
Change-Id: Ief13afc3f889af09094391e626037778d879c4f5
Reviewed-by: Mårten Nordheim <marten.nordheim@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>
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>
Just to simplify a few operations, like detecting when a QChar* or char*
coming from a QString or QByteArray, respectively, were null data.
While you're not supposed to dereference the pointer returned by
QVector::data() unless you know that the array is non-empty, that is
permitted for QString and QByteArray. That is, QString().constData()
must return a valid pointer to a null QChar.
Change-Id: I80b4b62f203dc841e5c99c20c51d92ca576e4bfe
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
ICC, GCC and Clang support __attribute__((malloc)) that tells them that
the function returns newly allocated memory which doesn't alias anything
else. Though technically we may return memory that has already been used
(the shared null or such), that should not be a problem.
Change-Id: Id3d5c7bf4d4c45069621ffff13f7f81f8b08ea3d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
GCC 4.9 and later support the __attribute__((alloc_align)) attributes
that indicate the alignment of the data. To make it work on GCC since
4.7 and Clang as of 3.6, we instead use __builtin_assume_aligned(). I
don't know which version of ICC first implemented this, but ICC 15 does
and it also reports itself as GCC 4.9.
Change-Id: I58bd914b9bdd0ed3349ba56fa78220ab06114852
Reviewed-by: Simon Hausmann <simon.hausmann@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>
The macro is not documented, so not part of the public Qt API. It is
made obsolete by the alignof keyword in C++11.
Remove the usage of the macro across qtbase, in particular the
workarounds for compilers that didn't support alignof, and that will
not be supported in Qt 6.
The macro definition is left in place, no need to break existing
code.
Task-number: QTBUG-76414
Change-Id: I1cfedcd4dd748128696cdfb546d97aae4f98c3da
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Some compilers (hello, MSVC) do not produce literal types in Qt
because their constexpr support has been blacklisted.
Therefore, amend the check for literal types in Q_ARRAY_LITERAL:
only do the check if the compiler supports constexpr.
Change-Id: I7cffe00dde447d975aa6a7d02248df9c351508ff
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
The check was a misnomer -- non-POD types can go in unions
since C++11. And we may want them, e.g. types without a trivial
default constructor. What we really want is to check for a
literal type (so that the array payload can be built entirely
at compile time, and put in .rodata). So, amend the check.
Also, make the dummy array constexpr, to be sure that we are
indeed building the payload using constexpr constructors.
That would make the first check redundant, but the fact that
we're still using a macro for constexpr makes me think that
not all compilers support it, so I'm leaving the first check
in...
Change-Id: I9f1473aa74dff5b6b6535ae4cd8325451c0b18e6
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Removes handling of missing Q_COMPILER_NULLPTR, Q_COMPILER_AUTODECL,
Q_COMPILER_LAMBDA, Q_COMPILER_VARIADIC_MACROS and
Q_COMPILER_AUTO_FUNCTION.
We haven't supported any compilers without these for a long time.
Change-Id: I3df88206516a25763e2c28b083733780f35a8764
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In preparation of Qt6 move away from pre-C++11 macros.
Change-Id: I44126693c20c18eca5620caab4f7e746218e0ce3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
all of these iterator classes already have a member operator+, which allows iter+int.
This commits addes non-member operator+, which allows int+iter, and forwards to the member
QList and QArrayData iterators now satisfy RandomAccessIterator concept
Change-Id: I25c1dd8cea299e735d5a5e288dbe23dc1d7a1933
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remaining uses of Q_NULLPTR are in:
src/corelib/global/qcompilerdetection.h
(definition and documentation of Q_NULLPTR)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.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>
This function reallocates a QArrayData block with realloc() but, as
the name says, it's only valid for types that do not increase the
alignment requirements. I don't think it's worth doing this for types
that do increase the alignment requirements, since we don't know the
alignment of the pointer returned by realloc(). If the new pointer
modulo the alignment is different from the old pointer modulo the
alignment, we'd have to memmove data around, which would be quite
inefficient (realloc might have memcpy'ed already and this memmove
would copy data to nearby).
This function is intended to be used especially in QString and
QByteArray, which were already using realloc() on pointers created by
QArrayData::allocate.
Change-Id: I45b61247db2e84797ad794c1049c47a09c1fb29a
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
The C and C++ standards say it's undefined whether the preprocessor
supports macros that expand to defined() will operate as an ifdef.
Clang 3.9 started complaining about that fact.
One solution was to change QT_SUPPORTS to check for zero or one, which
means we need to change the #defines QT_NO_xxx to #define QT_NO_xxx 1.
The C standard says we don't need to #define to 0, as an unknown token
is interpreted as zero. However, that might produce a warning (GCC with
-Wundef), so changing the macro this way is not recommended.
Instead, we deprecate the macro and replace the uses with #ifdef/ndef.
Change-Id: Id75834dab9ed466e94c7ffff1444874d5680b96a
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
This is in preparation of adding -Wzero-as-null-pointer-constant (or similar)
to the headers check.
Task-number: QTBUG-45291
Change-Id: I0cc388ef9faf45cbcf425ad0dc77db3060c104a8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
This shotgun-surgery approach is motivated by trying to get a
clean(er) build for -Wnoexcept on GCC, so it is expected that
for any class touched here, there will be more operations that
can be marked nothrow. But they don't show up in conditional
noexcept clauses, yet, so they are deferred to some later
commit.
Change-Id: I0eb10d75a26c361fb22cf785399e83b434bdf233
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
"Unsharables", given they can't be shared, don't need to detach, so skip the
check altogether and don't try to propagate the flag. It shouldn't be.
Change-Id: Icc483401d5a57708b43d64bd3cebc66c6b934815
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Up to now, Qt had at least 3 different implementations of the mid().
Only QString::mid implementation was not crashing on edge cases and
was protected against overflows, therefore I picked that one as the
base implementation, even if it has weird semantics for an invalid
input.
As a side effect QVector::mid was slightly optimized to not detach in
all cases (which follows current QList behavior). Documentation of
QVector::mid and QList::mid was updated to not mention "copy of data"
which could suggest that the mid() result is detached.
QStringRef::mid was fixed and now it follows general Qt behavior, by
returning a null value for a null input.
Change-Id: Ie9ff5d98372bd193d66508e6dd92b6ed1180ad9b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The ability to set a container to be unsharable has very little use and
it costs us an extra conditional for every refcount up and possibly
down.
This change is a no-op for current Qt 5. It shuffles a few things around
just so Qt can compile if you define QT_NO_UNSHARABLE_CONTAINERS. That
is done to ease the fixing of the code in Qt 6 and to make my life
easier: I'll keep that defined in my local Qt build so I can catch any
misuses of this deprecated API.
The newly deprecated methods are not marked QT_DEPRECATED because the
bootstrapped tools wouldn't build -- they're built with QT_NO_DEPRECATED
defined, which causes build errors.
[ChangeLog][QtCore] The setSharable() and isSharable() functions in Qt
containers has been deprecated and will be removed in Qt 6. New
applications should not use this feature, while old applications that
may be using this (undocumented) feature should port away from it.
Discussed-on: http://lists.qt-project.org/pipermail/development/2014-February/015724.html
Change-Id: I789771743dcaed6a43eccd99382f8b3ffa61e479
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Unit-test this by making the QList, QVector, QHash and QMap unit tests
be duplicated under strict-iterator mode. There's no test for
QLinkedList.
The tst_Collections test does not compile under strict-iterator
mode. It generated over 15000 errors when I tried.
The strict iterators required a small change: the difference_type
typedef needs to match the operators that get distances
(operator-(iterator)) and move the iterator around (+, -, +=, -=, etc.).
Task-number: QTBUG-29608
Change-Id: I834873934c51d0f139a994cd395818da4ec997e2
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
The fix in b8fe5e1bbc (for bug
QTBUG-27277) created two sets of begin() and end() functions for
QVector. That was required because QTypedArrayData::iterator and
QTypedArrayData::const_iterator have non-implicit copy constructors,
which means the variants returning a strict iterator need to pass the
storage pointer as an implicit first parameter. With the fix, the
compiler would emit functions with two different names for each
variant, which couldn't be merged.
If we remove those copy constructors, the compiler might be able to
generate the same code (no implicit first parameter) for both
functions.
Now, enter MSVC. Due to QPolygon, QVector<QPoint> and QVector<QPointF>
are "extern templates". That is, the compiler is not allowed to inline
anything, it must generate calls into QtCore (which we must fix for Qt
6, if we can). That means QtCore would only have one set of begin() /
end() functions. If an application tried to use the other set by
defining QT_STRICT_ITERATORS, you'd get a linker error for:
?begin@?$QVector@VQPoint@@@@QEAA?AViterator@?$QTypedArrayData@VQPoint@@@@V23@@Z
(class QTypedArrayData<class QPoint>::iterator QGenericArray<class QPoint>::begin(class QTypedArrayData<class QPoint>::iterator))
Change-Id: I5c10a7d0a4855f4ba84056d313c6a800ecdcfe37
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Lars Knoll
Giuseppe D'Angelo
Thiago Macieira
Volker Hilsheimer
Allan Sandfeld Jensen
Eric Lemanissier
Kevin Funk
Liang Qi
Jani Heikkinen
Marc Mutz
Matti Paaso
João Abecasis
Jędrzej Nowacki
Frederik Gladhorn
Simon Hausmann