Those serve no purpose anymore, now that the .pro files are gone.
Task-number: QTBUG-88742
Change-Id: I39943327b8c9871785b58e9973e4e7602371793e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Q_MOVABLE_TYPE was conceived before C++ had move semantics. Now, with
move semantics, its name is misleading. Q_RELOCATABLE_TYPE was
introduced as a synonym to Q_MOVABLE_TYPE. Usage of Q_MOVABLE_TYPE
is discouraged now. This patch replaces all usages of Q_MOVABLE_TYPE
by Q_RELOCATABLE_TYPE in QtBase. As the two are synonymous, this
patch should have no impact on users.
Pick-to: 6.0
Change-Id: Ie653984363198c1aeb1f70f8e0fa189aae38eb5c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
QList::insert() should never need to call a destructor. This
requires that we construct the new items in the list in order
and increment the size each time we constructed a new item.
Not having a code path that potentially calls destructors should
avoid the generation of lots of additional code for those
operations. In addition, the forward and backwards code paths
are now unified and only require somewhat different setup of
some variables at the start.
This gives us strong exception safety when appending one item,
weak exception safety in all other cases (in line with std::vector).
Change-Id: I6bf88365a34ea9e55ed1236be01a65499275d150
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Types that throw in their destructors are strongly discouraged in C++,
and even the STL doesn't define what happens if such types are stored
in their containers.
Make this more explicit for Qt and disallow storing those types in our
containers. This will hopefully preempty any potential future bug
reports about us not handling such a case. It also helps simplify
some code in QList and other cases and makes it possible to explicitly
mark more methods as noexcept.
Some care needs to be taken where to add the static asserts, so that
we don't disallow forward declarations of types stored in containers.
Place the static assert into the destructor of the container where
possible or otherwise into the templated d-pointer.
Change-Id: If3aa40888f668d0f1b6c6b3ad4862b169d31280e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QChar should not be convertible from any integral type except from
char16_t, short and possibly char (since it's a direct superset).
David provided the perfect example:
if (str == 123) { ~~~ }
compiles, with 123 implicitly converted to QChar (str == "123"
was meant instead). But similarly one can construct other
scenarios where QString(123) gets accidentally used (instead of
QString::number(123)), like QString s; s += 123;.
Add a macro to revert to the implicit constructors, for backwards
compatibility.
The breaks are mostly in tests that "abuse" of integers (arithmetic,
etc.). Maybe it's time for user-defined literals for QChar/QString,
but that is left for another commit.
[ChangeLog][Potentially Source-Incompatible Changes][QChar] QChar
constructors from integral types are now by default explicit.
It is recommended to use explicit conversions, QLatin1Char,
QChar::fromUcs4 instead of implicit conversions. The old behavior
can be restored by defining the QT_IMPLICIT_QCHAR_CONSTRUCTION
macro.
Change-Id: I6175f6ab9bcf1956f6f97ab0c9d9d5aaf777296d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This time based on grepping to also include documentation, tests and
examples previously missed by the automatic tool.
Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
... and QMultiMap as std::multimap.
Just use the implementation from the STL; we can't really claim that
our code is much better than STL's, or does things any differently
(de facto they're both red-black trees).
Decouple QMultiMap from QMap, by making it NOT inherit from
QMap any longer. This completes the deprecation started in 5.15:
QMap now does not store duplicated keys any more.
Something to establish is where to put the
QExplictlySharedDataPointer replcement that is in there as an
ad-hoc solution. There's a number of patches in-flight by Marc
that try to introduce the same (or very similar) functionality.
Miscellanea changes to the Q(Multi)Map code itself:
* consistently use size_type instead of int;
* pass iterators by value;
* drop QT_STRICT_ITERATORS;
* iterators implictly convert to const_iterators, and APIs
take const_iterators;
* iterators are just bidirectional and not random access;
* added noexcept where it makes sense;
* "inline" dropped (churn);
* qMapLessThanKey dropped (undocumented, 0 hits in Qt, 1 hit in KDE);
* operator== on Q(Multi)Map requires operator== on the key type
(we're checking for equality, not equivalence!).
Very few breakages occur in qtbase.
[ChangeLog][Potentially Source-Incompatible Changes] QMap does not
support multiple equivalent keys any more. Any related functionality
has been removed from QMap, following the deprecation that happened
in Qt 5.15. Use QMultiMap for this use case.
[ChangeLog][Potentially Source-Incompatible Changes] QMap and
QMultiMap iterators random-access API have been removed. Note that
the iterators have always been just bidirectional; moving
an iterator by N positions can still be achieved using std::next
or std::advance, at the same cost as before (O(N)).
[ChangeLog][Potentially Source-Incompatible Changes] QMultiMap does
not inherit from QMap any more. Amongst other things, this means
that iterators on a QMultiMap now belong to the QMultiMap class
(and not to the QMap class); new Java iterators have been added.
Change-Id: I5a0fe9b020f92c21b37065a1defff783b5d2b7a9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
This improves the readability and avoids code duplication
in tst_Collections::forwardDeclared. Also some warnings
are fixed:
* qSort is deprecated.
* The = operator for LargeStatic needs to be implemented
explicitly when a copy constructor is given.
* QMap::insertMulti is deprecated, a MultiMap is required.
Task-number: QTBUG-82978
Change-Id: I577f851394edfaa30154bd3417ce391635cc546d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
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>
Also removed add_subdirectory calls for subdirs which no longer exist.
Change-Id: I759f408ca812e1721dde495b0e23feffdeeb9c60
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is required, so that QHash and QSet can hold more
than 2^32 items on 64 bit platforms.
The actual hashing functions for strings are still 32bit, this will
be changed in a follow-up commit.
Change-Id: I4372125252486075ff3a0b45ecfa818359fe103b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
A brand new QHash implementation using a faster and more memory efficient data
structure than the old QHash.
A new implementation for QHash. Instead of a node based approach as the old
QHash, this implementation now uses a two stage lookup table. The total
amount of buckets in the table are divided into spans of 128 entries.
Inside each span, we use an array of chars to index into a storage area
for the span.
The storage area for each span is a simple array, that gets (re-)allocated
with size increments of 16 items. This gives an average memory overhead of
8*sizeof(struct{ Key; Value; }) + 128*sizeof(char) + 16 for each span.
To give good performance and avoid too many collisions, the array keeps its
load factor between .25 and .5 (and grows and rehashes if the load factor goes
above .5).
This design allows us to keep the memory overhead of the Hash very small, while
at the same time giving very good performance. The calculated overhead for a
QHash<int, int> comes to 1.7-3.3 bytes per entry and to 2.2-4.3 bytes for
a QHash<ptr, ptr>.
The new implementation also completely splits the QHash and QMultiHash classes.
One behavioral change to note is that the new QHash implementation will not
provide stable references to nodes in the hash when the table needs to grow.
Benchmarking using https://github.com/Tessil/hash-table-shootout shows
very nice performance compared to many different hash table implementation.
Numbers shown below are for a hash<int64, int64> with 1 million entries. These
numbers scale nicely (mostly in a linear fashion with some variation due to
varying load factors) to smaller and larger tables. All numbers are in seconds,
measured with gcc on Linux:
Hash table random random random random reads full
insertion insertion full full after iteration
(reserved) deletes reads deletes
------------------------------------------------------------------------------
std::unordered_map 0,3842 0,1969 0,4511 0,1300 0,1169 0,0708
google::dense_hash_map 0,1091 0,0846 0,0550 0,0452 0,0754 0,0160
google::sparse_hash_map 0,2888 0,1582 0,0948 0,1020 0,1348 0,0112
tsl::sparse_map 0,1487 0,1013 0,0735 0,0448 0,0505 0,0042
old QHash 0,2886 0,1798 0,5065 0,0840 0,0717 0,1387
new QHash 0,0940 0,0714 0,1494 0,0579 0,0449 0,0146
Numbers for hash<std::string, int64>, with the string having 15 characters:
Hash table random random random random reads
insertion insertion full full after
(reserved) deletes reads deletes
--------------------------------------------------------------------
std::unordered_map 0,4993 0,2563 0,5515 0,2950 0,2153
google::dense_hash_map 0,2691 0,1870 0,1547 0,1125 0,1622
google::sparse_hash_map 0,6979 0,3304 0,1884 0,1822 0,2122
tsl::sparse_map 0,4066 0,2586 0,1929 0,1146 0,1095
old QHash 0,3236 0,2064 0,5986 0,2115 0,1666
new QHash 0,2119 0,1652 0,2390 0,1378 0,0965
Memory usage numbers (in MB for a table with 1M entries) also look very nice:
Hash table Key int64 std::string (15 chars)
Value int64 int64
---------------------------------------------------------
std::unordered_map 44.63 75.35
google::dense_hash_map 32.32 80,60
google::sparse_hash_map 18.08 44.21
tsl::sparse_map 20.44 45,93
old QHash 53.95 69,16
new QHash 23.23 51,32
Fixes: QTBUG-80311
Change-Id: I5679734144bc9bca2102acbe725fcc2fa89f0dff
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QLinkedList has been moved to Qt5Compat. Remove and stop mentioning
it in docs, examples (the docs & examples for QLinkedList itself will
be moved to Qt5Compat) and remove the corresponding tests.
Also remove QT_NO_LINKED_LIST, since it's not needed anymore.
Task-number: QTBUG-81630
Task-number: QTBUG-80312
Change-Id: I4a8f1105cb60aa87e7fd67e901ec1a27c489aa31
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QHash and QMultiHash are separate classes in the future, and
the iterator is not random access.
Change-Id: I7e1a4162ca964001c8da81a2fd7c41ccae27bdb3
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Split QHash and QMultiHash, and get rid of some compiler warnings.
Change-Id: I48991f097f408ad5c1aa349443e26ab816e0b736
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>
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 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>
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>
The macro is not documented, so can be considered private API.
Pre-C++11 compilers that don't support alignas will no longer be
supported with Qt 6.
The macro definition for the standard case of compilers supporting
the alignof keyword is left in place.
Task-number: QTBUG-76414
Change-Id: I7d722e4faf09ae998a972d3ed914de808ab316d7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
The error was due to a compiler optimization bug, which is fixed
in 16.3.0.
This reverts commit 305f2c3aa6.
Fixes: QTBUG-77239
Change-Id: Idfb86ad5c3ec026518f0713c41f7ad744ab4d5db
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QLinkedList is still used in several tests. Add exceptions for
these subdirs.
Change-Id: I50ccd2a0892129d4a47aa4e2400211690da9a82d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
- Replaced the usages of deprecated APIs of corelib by corresponding
alternatives in the library code and documentation.
- Modified the tests to make them build when deprecated APIs disabled:
* Made the the parts of the tests testing the deprecated APIs to
be compiled conditionally, only when the corresponding methods are
enabled.
* If the test-case tests only the deprecated API, but not the
corresponding replacement, added tests for the replacement.
Task-number: QTBUG-76491
Task-number: QTBUG-76539
Task-number: QTBUG-76541
Change-Id: I62ed4a5b530a965ec3f6502c6480808f938921aa
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
... except for tests, which manually undefine the macro.
Like QT_NO_FOREACH, this is a technical way to keep JSI-free
modules JSI-free going forward.
Change-Id: Icf1342da00a700f42f9e32a253d1cdb94c38dd7e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Fix warnings:
Using QCharRef with an index pointing outside the valid range of a QString. The corresponding behavior is deprecated, and will be changed in a future version of Qt.
introduced by qtbase/c2d2757bccc68e1b981df059786c2e76f2969530 (5.14).
Change-Id: Ie6f0e2e3bb198a95dd40e7416adc8ffb29f3b2ba
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is part of the migration of qtbase from QRexExp to
QRegularExpression.
Task-number: QTBUG-72587
Change-Id: Iff9d4be685bf360ad921e29a82cb878ae5c46180
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>
Users should use range constructors instead to do the conversion.
Keep conversion methods between QList and QVector as these will turn
into a no-op in Qt 6, whereas forcing people to use range constructors
would lead to deep copies of the data.
Change-Id: Id9fc9e4d007044e019826da523e8418857c91283
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
- Alignment test was not compiling or passing on GCC / arm
- Using C++11 alignas() enforces maximum limit for the alignment, which
at least on GCC / arm is __BIGGEST_ALIGNMENT__ multiplied by 8
- On GCC 6.2.0 / x86_84, maximum alignment accepted by alignas is 128
- On GCC 5.3.0 / arm, maximum alignment accepted by alignas is 64
- This change calculates biggest tested alignment on ARM targets
and compilers supporting alignas() to the value calculated
from __BIGGEST_ALIGNMENT__
Task-number: QTBUG-55492
Change-Id: If2b70000ff9cdc5ae8c5a00e39f79efcc6ba1221
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)
Change-Id: I42a473ddc97101492a60b9287d90979d9eb35ae1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Probably correct.
The question is just why this code has survived for so many years.
Change-Id: Iaf01850476f9b066243abebb9ee6c5928d7ada19
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Move some code (like registrations of meta types) from init() to
initTestCase() in the process.
Change-Id: I57db5156647cfadab554fbed853b2e68b2815f3b
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Prefer QCOMPARE over QVERIFY for equality and use QLatin1String().
Change-Id: If226a0fc7b25be3e6774c7e36ca1e6f99234e5dd
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
