The variadic templates are supposed to be removed from the
overload set when any of the parameters is a literal string type,
as otherwise we get conflicts with the legacy overload taking
class names and signatures as const char *. The detection of
a literal string types was missing a few specializations, so that
we ended up with the wrong overload being called, and class
names getting interpreted as method names instead.
Add the missing specializations, and add more test coverage
for using the old overloads.
Task-number: QTBUG-122235
Pick-to: 6.7
Change-Id: I5488f2009c8f62d74fac6754844f57cf64011414
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Lauri Pohjanheimo <lauri.pohjanheimo@qt.io>
The class had operator==(), operator!=() and operator <() defined as
public member functions, so use QT_CORE_REMOVED_SINCE and
removed_api.cpp to get rid of these methods and replace them with hidden
friends.
Use QT_TEST_ALL_EQUALITY_OPS macro in unit-tests.
Use new \compares command in the documentation to describe the
comparison operators provided by QUrl.
Task-number: QTBUG-120303
Change-Id: Ic4fa2335292cc4b75ad2373832c0b89d768f529c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
P2447 has been merged in C++26, backport the same functionality.
This makes QSpan<const T> a proper replacement for a const QList<T>&
parameter, because now both can be built via a braced-init-list.
// void f(const QList<int> &l); // old
void f(QSpan<const int>); // new
f({1, 2, 3}); // now OK
This is, technically speaking, SiC: in the presence of both `f`
overloads, the code above would have called the QList one. Now instead
the call is ambiguous.
We've been there already -- this is QString and QStringView all over
again, and the solution is the same: get rid of the owning container
overload. I'd rather have this construction *sooner* rather than *later*
in order to minimize the fallout.
And just like QString vs QStringView, there's nothing really doable to
prevent instant-dangling situations:
QStringView v = getString(); // dangles
QSpan<const int> s = {1, 2, 3}; // ditto
except for using QSpan (QStringView) as a *parameter type only*.
Note that QSpan with dynamic extent was already convertible from
std::initializer_list through its ranged constructor. However this fact
alone doesn't unlock the above syntax. QSpan with a static extent was
also convertible for the same reason. (This is non-standard:
std::span's range constructor for static extents is explicit, but QSpan
doesn't follow that design choice and makes the constructors implicit
instead.)
Found in API-review.
Pick-to: 6.7
Change-Id: I160ab5b292b0c2568cd9a7ad1b4430085f475c29
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Task-number: QTBUG-121787
Change-Id: Iee9f4fca676e77ab9d8ed485a28ce5ea8803be15
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
According to QUIP-18 [1], all tools file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: Icd5d5be2e04819617e68ff142924de1773bebbad
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Which will be used to represent timer IDs. Thanks to Marc for the idea
to use "a strongly typed int".
QTimer got a new id() method that returns Qt::TimerId (can't overload
timerId()). Various classes in qtbase have a member named timerId(), but
a new method is needed anyway in QTimer so id() it is (this is the
reason QChronoTimer only has id() and no timerId()). Besides
timer.timerId() has an extra "timer".
This commit fixes the inconsistency between QObject using `0` timer id
to indicate "failed to start", while QTimer::timerId() returned `-1` to
indicate "timer is inactive". QTimer::id(), being a new method and all,
now returns Qt::TimerId::Invalid, which has value `0`, so that the
values match between the two classes. Extend the unittests to ensure
QTimer::timerId()'s behavior is preserved.
[ChangeLog][Core][QObject] Added Qt::TimerId enum class, that is used to
represent timer IDs.
Change-Id: I0e8564c1461884106d8a797cc980a669035d480a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The interval in QTimer is a QProperty of type int, which means it's
limited to the number of milliseconds that would fit in an int (~24
days), this could cause overflow if a user constructs a QTimer with an
interval > INT_MAX milliseconds. And it can't be easily changed to use
qint64/std::chrono::nanoseconds:
- changing the getters to return qint64 means user code would have
narrowing conversions
- the bindable QProperty interval can't be changed to qint64 during
Qt6's lifetime without the risk of breaking user code
- adding a new bindable QProperty that is qint64/nanoseconds is an
option, but it has the complication of what to do with the int
interval; set it when setInterval(milliseconds) is used by using
saturation arithmetic? and what about notifying observers of the
changed interval?
Thus the idea of creating a new stop-gap class, QChronoTimer, as a
cleaner solution. Both classes use QTimerPrivate.
During the lifetime of Qt6, QTimer's interval range is about 24 days,
whereas QChronoTimer's interval range is about 292 years
(duration_cast<years>nanoseconds::max()).
Currently the plan is to fold QChronotTimer back into QTimer in Qt7.
Mark all QPropertyS in the new class as FINAL since they aren't
intended to be overridden; this offers a performance boost for QML[1].
[1] https://lists.qt-project.org/pipermail/development/2024-February/044977.html
[ChangeLog][QtCore] Added QChronoTimer, which uses a
std::chrono::nanoseconds intervals, as a replacement for QTimer.
Fixes: QTBUG-113544
Change-Id: I71697f4a8b35452c6b5604b1322ee7f0b4453f04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Ultimately this is the best way to keep the log history of the code.
Change-Id: I3413deffdb093a3239d65b6ca939e744224e722a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Then we will automatically handle invalid leading characters instead
of throwing away the whole sequence when it cannot be converted.
Added a test that was failing before.
Drive-by change: add a comment explaining why we
have the stack allocated buffer.
Task-number: QTBUG-118834
Change-Id: I647a58f2ba95e2e7ed4ea6a964d99ecc0c91fad3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some machine in CI is failing some of these sometimes and
I would like to know by how much.
Pick-to: 6.7
Change-Id: I88b41d5cde81419f7c11f7038101962630eb31ef
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Also extend unit-test to use new test helper functions.
Remove the now-redundant test for three-way comparison, because it is
covered by the test helper functions.
Task-number: QTBUG-117661
Change-Id: I242b560c281245e04e34353c80000a20998fc677
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Replace the existing friend relational operators with the macros.
Add the previously-missing relational opertors with QChar and char16_t.
This allows to remove the last dummy relational operators and the
macros to generate them in tst_qstringapisymmetry.
Because of a bug in libstdc++[0], we have to explicitly keep the
QBA vs QBA relational operators even in C++20 mode. This problem is
specific to QByteArray, because it is convertible to const void *.
[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114153
Task-number: QTBUG-117661
Change-Id: Iac7f81cd3274331b7c7695a51803321b511361c0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace the existing friend relational operators with the macros.
Add the previously-missing QChar vs `const char *` relational operators.
These require out-of-line helper methods, because we need to interpret
the `const char *` array as utf-8.
The `const char *` relational operators cause ambiguities when
comparing QChar with 0 (previously it was only handled by the nullptr_t
overloads). As we have it in several places in our tests, I'd assume
that the users can also do it. To resolve the ambiguities, mark the
new relational operators as Q_WEAK_OVERLOADs.
This allows to remove the dummy QChar vs `const char *` relational
operators from tst_qstringapisymmetry, but at the same time requires
that we introduce new dummy operators for QByteArray vs char16_t
comparison. These will be fixed in a follow-up patch.
For QLatin1Char - convert to uchar before doing the comparison, to
match the behavior of QLatin1StringView and QChar. Extend QChar's
unit tests.
Task-number: QTBUG-117661
Change-Id: I9213fe05a5efdb96d48688f07bec9519f9887a77
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This allows to remove the dummy relational operators from
tst_qstringapisymmetry.
Task-number: QTBUG-108805
Change-Id: I7cb3154d6fcb571cafab6b318806f74bc8300448
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add QU8SV vs QSV, QU8SV vs QChar, and QU8SV vs char16_t relational
operators.
This allows to get rid of the dummy relational operators in
tst_qstringapisymmetry.
Task-number: QTBUG-117661
Change-Id: If95d7418efd13c505ed0e3bef748b86ff55e623a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The comparison with QStringView works as is, there is no need to add
explicit operators.
Add the missing relational operators with QUtf8StringView. Once it
is added, comparison of QString with u8"string literal" becomes
ambiguous, so explicitly add operators for `const char8_t*` as well.
This also makes the comparison with u8 string literals faster,
because it now uses a view instead of constructing a QString.
Adding QUtf8StringView overloads also makes comparison with
`const char *` ambiguous if QT_RESTRICTED_CAST_FROM_ASCII is defined.
To fix that, mark the overload as Q_WEAK_OVERLOAD. Luckily, we can
just use the third Attributes parameter of the macro for that.
Provide more unit-tests to cover the new relational operators.
Task-number: QTBUG-117661
Change-Id: I60d1f4ad7ea607472deeb5c250e62f2bb7019268
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use the comparison helper macros to replace the member relational
operators for comparison with QByteArray and const char *.
As QString and QByteArray are exported, we cannot simply remove the
inline methods, so wrap them into QT_CORE_REMOVED_SINCE.
Add relational operators with QByteArrayView.
Provide more unit-tests for the comparison with the byte array types.
This enables operator<=> for QString vs byte arrays in C++20 builds.
Task-number: QTBUG-117661
Change-Id: I305343e1b6c5d78b10f2976573db4e904ba6b44b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace the hidden friend relational operators with hidden friend
helper functions and comparison helper macros.
Provide more unit-tests for the updated types.
This enables operator<=> in C++20 builds.
Task-number: QTBUG-117661
Change-Id: I17329cd6422f272a435fc1da241203581eef7fbb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Even though undocumented, it's public API, doesn't hurt to carry
along, and improves compiler coverage in the test, so let's not remove
it.
Found in 6.7 API review
Amends 95e6fac0a5.
Pick-to: 6.7
Change-Id: Ia935036a69e0e678f22ac86b48a2c1c5e8c46733
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Both QByteArrayView and std::string_view are Literal Types, so the
conversion between them should be constexpr.
Amends 96d67da420.
Found in API-review.
Pick-to: 6.7
Change-Id: Ic513ce32aa2a743ca890dc05a683a62c0f3a7d50
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
This class offers a forward-only const_iterator, that matches the system
low-level functions' logic (e.g. readdir()/dirstream logic). This
iterator is a std::input_iterator_tag.
QDirIterator uses Java-style iterators that have a couple of issues:
- They don't fit the logic of the underlying native system functions
(readdir()/__dirstream and co.), there is no way to know if there is a
next entry except by advancing the iterator (calling readdir()) first
- As a consequence of the above, two QFileInfo objects, current and next,
had to be used to fit that paradigm; and the code always
iterated/stat'ed an extra entry past the one we want, e.g. when
filtering
The next step is porting QAbstractFileEngineIterator and its subclasses
to be like QFileSystemIterator, i.e. replace hasNext()/next() with a `bool
advance()` virtual method. This is easier to reason about than the
Java-style iterators, and is more in-line with the new class.
Discussed-on: https://lists.qt-project.org/pipermail/development/2023-December/044745.html
Change-Id: I8e696cefdca18d8c78f803efdb83a73dd43eb720
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
To make it easier to follow the history in git.
Change-Id: I094056c1ec130aeef77aa2d20289ab766bc25083
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Rename the toType() overloads taking an out-parameter to appendToType(),
because that gives a better understanding of the usecase.
Found in 6.7 API review
Amends 8af346c1f6 and
1d9137e13f.
Pick-to: 6.7
Change-Id: Ic1a462e9507123a59e6086bfb48b8b61ab79abb8
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QString/QByteArray] Added slice() methods that work
like sliced(), but modify the string/byte-array they are called on.
Task-number: QTBUG-99218
Change-Id: I3075562983ef123d9aa022a2304c7e774cf2ea42
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Changed type of `id`, `int` -> `size_t`, to match `liveCount`, in
`CountedObject` struct.
Fixes: QTBUG-122301
Change-Id: I85513d5ff6a4f0c3fb53f77e55c43b1284d1b1a8
Reviewed-by: Matthias Rauter <matthias.rauter@qt.io>
Change type of variables `int` -> `size_t`, to match assigned value.
Fixes: QTBUG-122300
Change-Id: I5b99bd6a3b307ba2ec4ef79bcc517da60ae36413
Reviewed-by: Matthias Rauter <matthias.rauter@qt.io>
One more method for STL compatibility.
This one is particularly subtle as it's required by the
`reservable-container` concept:
https://eel.is/c++draft/ranges#range.utility.conv.general-3
Without this concept, ranges::to won't reserve() before copying the
elements (out of a sized range which isn't a common_range).
Implementation notes: there were already a couple of constants denoting
the maximum QByteArray and QString size. Centralize that implementation
in QTypedArrayData, so that QList can use it too.
The maximum allocation size (private constant) needs a even more central
place so that even QVLA can use it. Lacking anything better, I've put it
in qcontainerfwd.h.
Since our containers aren't allocator-aware, I can make max_size() a
static member, and replace the existing constants throughout the rest of
qtbase. (I can't kill them yet as they're used by other submodules.)
[ChangeLog][QtCore][QList] Added max_size().
[ChangeLog][QtCore][QString] Added max_size().
[ChangeLog][QtCore][QByteArray] Added max_size().
[ChangeLog][QtCore][QVarLengthArray] Added max_size().
Change-Id: I176142e31b998f4f787c96333894b8f6653eb70d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As the comment says, on most RISC platforms, the return address need not
be on the stack in the first place. In fact, in all ones currently
supported by Qt, it's passed in a register to the callee, which has the
option of simply saving it in a callee-save register when calling leaf
functions. Even if it is using a frame pointer, the compiler can simply
use any register. That means unwinding the stack is not possible in the
absence of either debug information or stack-unwind information, neither
of which backtrace(3) will use.
Strictly speaking, even on x86 the compiler can use the RBP register for
any purpose and thus make getting the backtrace() impossible, but in
practice it seems to work.
Fixes: QTBUG-121389
Pick-to: 6.7
Change-Id: I5dd50a1a7ca5424d9e7afffd17acbd01ef916f5d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add implict constructor, treat the list like any other container.
Simplify the test code, and explicitly constructor-initialize when
we want an array and might have an array, so that we don't end up
with constructing arrays of arrays.
Change-Id: I14615f897cf8a2188510cfe1085ffc70a2396d5d
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
QUrlQuery had operator==() and operator!=() defined as public member
functions, so use QT_CORE_REMOVED_SINCE and removed_api.cpp to get
rid of these methods and replace them with a hidden friend.
Use QT_TEST_ALL_EQUALITY_OPS macro in unit-tests.
Use new \compares command in the documentation to describe the
comparison operators provided by QUrlQuery.
Task-number: QTBUG-120303
Change-Id: I083487a134887010ebbb78906d2c1982f2ad41b5
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Since we support QString and QList specializations, we should also
support QStringList directly. That's a bit more involved as we need
to specialize the code path for QString, which is not convertible to
or from jobject. But once we have mapped the type to jstring it
follows the implementation for lists of objects.
We now need to generate temporary local references when
converting a QString to a jstring, so manage a local frame. We do
so explicitly in chunks of 100 local references.
Change-Id: I7ae5cf7d0ba0099992c36f3677980c346526804b
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This didn't work yet because the partial specialization of the
JNITypeForArgImpl factory was missing. Add a test case for
QJniArray<double> and QList<double>.
What doesn't work (yet) is QStringList for a native Java function
taking a String[]. That will be added in a follow-up commit.
Change-Id: I4d3fa0ecc04b98b9749f8358792f86c02ddbbc14
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Replace operator==() and operator!=() private friends with
comparesEqual().
Use QT_TEST_ALL_EQUALITY_OPS macro in unit-tests.
Use new \compares command in the documentation to describe the
comparison operators provided by QStorageInfo.
Task-number: QTBUG-120303
Change-Id: I6434dc8382f6554b9e60840bac4abaeb95b70db6
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
QProcessEnvironment had operator==() and operator!=() defined as public
member functions, so use QT_CORE_REMOVED_SINCE and removed_api.cpp to
get rid of these methods and replace them with a hidden friend.
Use QT_TEST_ALL_EQUALITY_OPS macro in unit-tests.
Use new \compares command in the documentation to describe the
comparison operators provided by QProcessEnvironment.
Task-number: QTBUG-120303
Change-Id: I4c57f6cfb9589e82a37eea6993e079212b34cecd
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Now when QLatin1StringView implements relational operators with
QByteArrayView in terms of new comparison helper macros and helper
methods taking QByteArrayView, we can easily re-use these helper
methods to provide comparison with QByteArray and const char *.
QLatin1StringView already provided almost all of these operations,
partly as hidden friend functions, partly as inline methods.
Since the class is not exported, and the methods were inline, we
can just remove all of them and replace them with the comparison
helper macros.
This should speed up the relational operators, because they do not
construct string objects using QString::fromUtf8() anymore, but use
QUtf8StringView instead.
This also adds the previously missing QByteArray vs QLatin1StringView
relational operators.
Task-number: QTBUG-117661
Change-Id: I17a9185127ae130dab9409c6340a58f5d39f5a10
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by using the new comparison helper macors.
Note that by providing helper functions for QByteArrayView,
we can support all three types: QByteArray, QByteArrayView, and
const char *.
Use the regular QT_NO_CAST_FROM_ASCII and
QT_RESTRICTED_CAST_FROM_ASCII guards to disable the operators
if the cast from ASCII is forbidden.
Also use QT_ASCII_CAST_WARN on each operator.
This allows to enable related tests in tst_qstringapisymmetry.
Task-number: QTBUG-117661
Task-number: QTBUG-108805
Change-Id: I0d77c30245d8b5ac4b8cfd98d650c1885aca2005
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by using the new comparison helper macros.
Also, convert the existing QByteArrayView relational operators to use
these macros.
An attempt to define the helper functions comparesEqual() and
compareThreeWay() as hidden friends leads to compilation errors, because
the QByteArrayView(QLatin1StringView) constructor gets somehow disabled.
Apparently, it cannot satisfy the
QtPrivate::IsContainerCompatibleWithQByteArrayView trait anymore.
I could not find a reason for that, so I just defined the helper
functions as static inline private members of QByteArrayView. This fixes
the issue.
This allows to enable related tests in tst_qstringapisymmetry.
Task-number: QTBUG-108805
Change-Id: I35a69e99db8c61531ec726dab5b242b857f69e85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by using the new comparison helper macors.
This allows to enable related tests in tst_qstringapisymmetry.
Task-number: QTBUG-108805
Change-Id: I2cef8f4a25889b74a921fea47995d59c3a49d368
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by using the new comparison helper macros.
First the relational operators between QU8SV and QBAV where added,
and this resulted in the ambiguities when comparing QU8SV vs QBA.
So, the relational operators between QU8SV and QBA are also added
in the same commit. This, in turn, resulted in ambiguities when
comparing QU8SV and const char *, so add these relational operators
as well.
Use the regular QT_NO_CAST_FROM_ASCII and
QT_RESTRICTED_CAST_FROM_ASCII guards to disable the operators if
the cast from ASCII is forbidden. Also use QT_ASCII_CAST_WARN on
each operator.
This allows to enable related tests in tst_qstringapisymmetry.
Task-number: QTBUG-117661
Task-number: QTBUG-108805
Change-Id: If7919496fdf4519fd2a9398397a39210aadba077
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by using the new comparison helper macros.
The operators are marked as QT_ASCII_CAST_WARN, like the pre-existing
relational operators with QByteArray and const char *.
This allows to enable related tests in tst_qstringapisymmetry.
Task-number: QTBUG-117661
Task-number: QTBUG-108805
Change-Id: Ic9bcddffc25585edb7375c3e651d49d040a60454
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some of relational operators in Qt are marked with QT_ASCII_CAST_WARN
(see e.g. String, QLatin1StringView).
If we want to convert these operators to the new comparison helper
macros, we need a way to preserve this attribute.
My tests show that simply adding the attribute to the helper
comparesEqual() and compareThreeWay() functions does not work, so we
need to explicitly add it to each of the generated operators.
Change-Id: I2940a70fe191326e8a2ebfb05b8da6e0f21a845c
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
... by using the new comparison helper macros.
This allows to remove dummy comparison operators from
tst_qstringapisymmetry.
This is also a pre-requisite for a follow-up commit that introduces
relational operators between QLatin1StringView and QByteArrayView.
Task-number: QTBUG-117661
Task-number: QTBUG-108805
Change-Id: I5837b457a777fddff1071bc252982e68d004fa94
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously the test consisted of just one cpp file. An attempt to add
more test cases to the file resulted in the minGW compiler complaining
about a too large object file:
Fatal error: tst_qcomparehelpers.cpp.obj: file too big
This patch splits the implementation into a header and a cpp file.
This itself does not fix the issues, but now we can add the new test
cases in a separate cpp file. This patch also adds some comments
that advocate doing so.
Pick-to: 6.7
Change-Id: I451987370fa4e18b7ad81dfc064ea016f1d0da47
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Creating a QList of a given size, or resizing it to a given size, will
always value-initialize its elements. This commit adds support for
uninitialized construction and resizes. The intended use case is using a
QList as storage-to-be-overwritten:
QList<int> list(size, Qt::Uninitialized);
fillWithData(list.data(), list.size);
How do we define "uninitialized":
1) if T is constructible using Qt::Uninitialized, use that;
2) otherwise, default-construct T.
In detail:
1) covers (Qt-ish) datatypes that have a default constructor that
initializes them, but also a dedicated constructor that doesn't
initialize (e.g. QPoint, QQuaternion, ...).
2) covers everything else. Default initialization of scalars and
trivially constructible datatypes will leave them uninitialized.
A type which isn't trivially constructible will still get its default
constructor called (and possibly actually gets initialized); we can't
really do better than that, as we still have to construct objects and
start their lifetimes.
[ChangeLog][QtCore][QList] Added support for uninitialized construction
and resizing.
Change-Id: I32c285c7dddbf7e01475943f24e14e824bb13090
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This gives users of the class easy access to the Prealloc template
argument, without having to write a pattern-matcher like
template <typename T>
constexpr qsizetype preallocated_size_v;
template <typename T, qsizetype N>
constexpr qsizetype preallocated_size_v<QVarLengthArray<T,N>> = N;
first.
[ChangeLog][QtCore][QVarLengthArray] Added PreallocatedSize nested
constant, equal to the Prealloc template argument.
Change-Id: I928eaa5e62967445cdd7b0c2759567483fdb8997
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Replace QTestPrivate::testEqualityOperators() helper function with
QT_TEST_EQUALITY_OPS macro to get a reasonable debug output in case of
failure.
Task-number: QTBUG-120303
Change-Id: I1ca23cabfe62ab78e012cf95fd2add631fc88a64
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
QFileInfo had operator==() and operator!=() defined as public member
functions, so use QT_CORE_REMOVED_SINCE and removed_api.cpp to get
rid of these methods and replace them with a hidden friend.
Use QT_TEST_ALL_EQUALITY_OPS macro in unit-tests.
Task-number: QTBUG-120303
Change-Id: Ie290df230b0f608a0965dccba9184382291cad8e
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The only backend that requires longer wait times is
QPollingFileSystemWatcherEngine; lower the interval of the polling
engine for the unittests (using the same objectName() trick that is used
to force using a specific watcher engine).
Remove the comment about FAT32 filesystems, there is no where on the CI
where this test fails so far.
Before:
Totals: 23 passed, 0 failed, 0 skipped, 0 blacklisted, 127027ms
After:
Totals: 23 passed, 0 failed, 0 skipped, 0 blacklisted, 666ms
Change-Id: I96378f810463fa5c4ebdc13946ea23810e80f144
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDir had operator==() and operator!=() defined as public member
functions, so use QT_CORE_REMOVED_SINCE and removed_api.cpp to get
rid of these methods and replace them with a hidden friend.
Use QTestPrivate::testEqualityOperators() helper function in unit-tests.
Task-number: QTBUG-120303
Change-Id: I86c2ba18b8b114efd9f62fc2fd628bc9065b04b2
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Volker Hilsheimer
Rym Bouabid
Giuseppe D'Angelo
Lucie Gérard
Ahmad Samir
Mårten Nordheim
Ivan Solovev
Marc Mutz
Isak Fyksen
Thiago Macieira