setFilterRegExp retains the caseSensitivity() while setFilterRegularExpression did not.
Change setFilterRegularExpression to also retain the case sensitivity.
Fixes: QTBUG-83313
Pick-to: 5.15
Change-Id: I46f494d320aee99d50612f01f63558c693276989
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: David Faure <david.faure@kdab.com>
MidButton had its // ### Qt 5: remove me
upgraded to Qt 6 at 5.0; but it dates back to 4.7.0
Replace the many remaining uses of MidButton with MiddleButton in the
process.
Pick-to: 5.15
Change-Id: Idc1b1b1816673dfdb344d703d101febc823a76ff
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Export some private functions from QUtf8 to resolve
undefined symbols in Qt5Compat after moving QStringRef.
Task-number: QTBUG-84437
Change-Id: I9046dcb14ed520d8868a511d79da6e721e26f72b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The string representation of std::pair<T1,T2> is now always
"std::pair<T1,T2>". This is in line with how we translate QPair,
avoiding typename mismatches that would previoulsy occur, because the
full name of pair on libc++ was "std::__1::pair".
Fixes: QTBUG-84924
Change-Id: Ia6c044a7327d69e4b4f4a31496c6b2408d85ebb9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Just like any other container, it's legitimate for the user to
pass key/values belonging to the same container.
Q(Multi)Map::remove(Key) are already safe (either they call
erase() directly on std::(multi)map, where it does the right thing,
or they skip elements while detaching).
However, QMultiMap::remove(Key, T) wasn't safe in this regard
(the implementation is hand rolled), so take copies before start
erasing.
Change-Id: I87767d608b83216a6ff264fb6c8f145fdb5934f8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Added functions that tell how much free space is available at the
beginning and at the end of the storage
Updated preconditions of operations to use freeSpace* functions
Also, changed casts uint(this->size) to size_t(this->size)
Task-number: QTBUG-84320
Change-Id: Iad94c1060a00f62068da9d1327e332a00d4f4109
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Refactored certain bits of qarraydataops.h: picked exception-related
building blocks and put them into one place, (somewhat) documented
the usage, added tests
Personally, the existing code seemed rather complicated to analyze
(and do mental experiments for corner cases), especially when staring
at the whole thing for a while or "returning back" from some other work
and I still have my doubts that everything works correctly. Testing the
building blocks that are used should:
a) increase trust into existing code (provided the usage is correct)
b) give more use cases of how to use the building blocks, which in turn
would allow to compare and contrast tests vs implementation
Task-number: QTBUG-84320
Change-Id: I313a1d1817577507fe07a5b9b7d2c90b0969b490
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Updated insert() methods:
* Refined Q_ASSERT() checks
* Fixed implementation issues (some of which resulted in
actual crashes)
* Allowed to insert at the end. This is safe as far as I can
tell and actually would allow to simplify considerable chunks
of code (mainly, copyAppend versions to just return
insert at the end)
Updated tests accordingly
Change-Id: I0ba33ae5034ce8d5ff95b753894e95d71ba00257
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Extended existing tests with QArrayData's allocation options
Added extra tests on array operations covering append, insert,
emplace, erase and truncate. "Raw" QArrayDataPointer is used instead of
test-specific SimpleVector to check the behavior without some custom
logic in-between
The change targets future updates to array operations in the light of
prepend optimization: as the array operations would become more complex,
these tests should give a much better coverage (specifically due to
likely non-trivial implementation details and optimizations)
Task-number: QTBUG-84320
Change-Id: I6581e2cb48f81b82ee5052d1dcea3da2819df47a
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Check that we can successfully instantiate the data
stream operator for a container before we actually try.
This is required so we can automate registration of debug
stream operators with QMetaType.
Change-Id: Ib100a5242470d7fc8067058cc4d81af2fa9354b0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Check that we can successfully instantiate the debug
stream operator for a container before we actually try.
This is required so we can automate registration of debug
stream operators with QMetaType.
Change-Id: I3943e7a443751d250c33b2ca1b9cf29207cfe6c4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It was marked internal anyway. Use the constructor taking a
QMetaType instead.
Change-Id: I15b9cd0911aac063a0f0fe0352fa2c84b7f7c691
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Both normal and relaxed constexpr are required by our new minimum of
C++17.
Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
A few new files were added with old-school defines.
Change-Id: Ieb2c71e094e55102f3f39fb9551823f36863f5f4
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
After reimplementing Qt JSON support on top of CBOR, there were
unintended behavior changes when converting QVariant{, List, Map} to
QJson{Value, Array, List} due to reusing the code for converting
QVariant* types to CBOR types, and from CBOR types to corresponding JSON
types. In particular, conversions from QVariant containing QByteArray to
JSON has been affected: according to RFC 7049, when converting from
CBOR to JSON, raw byte array data must be encoded in base64url when
converting to a JSON string. As a result QVariant* types containing
QByteArray data ended up base64url-encoded when converted to JSON,
instead of converting using QString::fromUtf8() as before.
There were also differences when converting QRegularExpression.
Reverted the behavior changes by adding a flag to internal methods for
converting CBOR to JSON, to distinguish whether the conversion is done
from QVariant* or CBOR types. These methods now will fall back to the old
behavior, if the conversion is done using QJson*::fromVariant*().
Additionally fixed QJsonValue::fromVariant conversion for NaN and
infinities: they should always convert to QJsonValue::Null. This works
correctly when converting from variant to QJsonArray/QJsonObject, but has
been wrong for QJsonValue.
Added more tests to verify the expected behavior.
[ChangeLog][Important Behavior Changes] Restored pre-5.15.0 behavior
when converting from QVariant* to QJson* types. Unforeseen consequences
of changes in 5.15.0 caused QByteArray data to be base64url-encoded; the
handling of QRegularExpression was also unintentionally changed. These
conversions are now reverted to the prior behavior. Additionally fixed
QJsonValue::fromVariant conversions for NaN and infinities: they should
always convert to QJsonValue::Null.
Fixes: QTBUG-84739
Change-Id: Iaee667d00e5363906eedbb67948b7b39c9d0bc78
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
isNull() would forward to the contained type and check that type's
isNull() method for some of the builtin types. Remove that behavior
and only return true in isNull(), if the variant is invalid, doesn't
contain data or contains a null pointer.
In addition, implement more consistent behavior when constructing
a QVariant using the internal API taking a copy from a void *.
isNull() should return true in both cases. This mainly changes behavior
for some corner cases and when using our internal API.
[ChangeLog][Important Behavior Changes] QVariant::isNull()
no longer returns true when the variant contains an object of some
type with an isNull() method, that returns true for the object;
QVariant::isNull() now only returns true when the variant contains
no object or a null pointer.
Change-Id: I3125041c4f8f8618a04aa375aa0a56b19c02dcf5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Comparing two variants will not try to convert the types
of the variant anymore. Exceptions are when both types are
numeric types or one type is numeric and the other one a
QString. The exceptions are there to keep compatibility with
C++ and to not completely break QSettings (which needs automatic
conversions from QString to numeric types).
[ChangeLog][Important Behavior Changes] Comparing two
variants in Qt 6 will not try attempt any type conversions before
comparing the variants anymore. Instead variants of different type
will not compare equal, with two exceptions: If both types are numeric
types they will get compared according to C++ type promotion rules. If
one type is a QString and the other type a numeric type, a conversion
from the string to the numeric tpye will be attempted.
Fixes: QTBUG-84636
Change-Id: I0cdd0b7259a525a41679fb6761f1e37e1d5b257f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove the compare method in the QVariant::Handler struct. Rely
on the generic support provided by QMetaType instead.
[ChangeLog][Important Behavior Changes][QVariant] QVariant will now use builtin support in
QMetaType to compare its content. This implies a behavioral change
for some graphical types like QPixmap, QImage and QIcon that will
never compare equal in Qt 6 (as they do not have a comparison
operator).
Change-Id: I30a6e7116c89124d11ed9052537cecc23f78116e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Change-Id: Ibdc95e9af7bd456a94ecfffd16066c47ea9766d0
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
[ChangeLog][QtCore][QJsonDocument] Fixed a bug that caused
QJsonDocument's equality operator to crash if one of the operands was
default-constructed and the other wasn't.
Pick-to: 5.15
Fixes: QTBUG-85969
Change-Id: I5e00996d7f4b4a10bc98fffd1629f835f570ef6b
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Use the actual minimum value, rather than minus the maximum, and adapt
the overflow expectations so that they're correct west of Greenwich as
well as east.
Change-Id: I7a5f4510db0fdea3855b5b2bd4c4a86882030efd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Due to a limitation of mktime(), we would have declared it invalid.
Tidied up qt_mktime() slightly in the process.
Change-Id: I25469e314afee6e0394e564bc69a98883005d4ec
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Removed isCompressed(), deprecated since 5.15, and (since 5.13)
addSearchPath() and searchPath().
Change-Id: I4b6fb8077c02bbe322334e474eaf0a2a7caf0004
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QString's fromUtf16() prefers char16_t data over ushort.
Change-Id: Ib20c5afa09ceabb4e91fe434b6a057edb4739a53
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
mkspecs/features/qt.prf adds a dependency on the system threading
library if the Qt Core thread feature is enabled. Because qt.prf is
loaded by any public or internal Qt project, it's essentially a public
dependency for any Qt consumer.
To mimic that in CMake, we check if the thread feature is enabled, and
and set the Threads::Threads library as a dependency of Qt6::Platform,
which is a public target used by all Qt modules and plugins and Qt
consumers.
We also need to create a Qt6Dependencies.cmake file so we
find_package(Threads) every time find_package(Qt6) is called.
For the .prl files to be usable, we have to filter out some
CMake implementation specific directory separator tokens
'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call
target_link_libraries() with a target created in a different scope
(I think).
As a result of this change, we shouldn't have to hardcode
Threads::Threads in other projects, because it's now a global public
dependency.
Task-number: QTBUG-85801
Task-number: QTBUG-85877
Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Receiving an rvalue still requires to check whether the parameter
is detached, otherwise we can't steal its backing std::map.
Change-Id: Ie88dbf39fd777112ad7bb20a46d5c2d65be8eb3d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... 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>
Avoids the conversion from UTF-8 for uses that are not dumping a string.
Mass conversion of Qt sources left for future opportunity.
Fixes: QTBUG-85811
Change-Id: I4ca4a35b687b46c39030fffd1626ae6c3294cacf
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We can end up in a situation where a (soon to be destroyed) observer is
owned by a binding which is about to be deleted. If in that situation
the binding is destroyed first, we end up with a dangling pointer
and ensuing memory corruption. Instead, we now first transfer the
ownership of the observer and only destroy the binding afterwards.
Fixes: QTBUG-85824
Change-Id: I721c0319281ada981ae7896bd2e02e9a0cc901b8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Fixes warning by Clang:
warning: 'const volatile' type qualifiers on return type have no effect
[-Wignored-qualifiers]
const volatile unsigned long long * const volatile func_KVPKVull() {...}
^~~~~~~~~~~~~~~
Change-Id: Ia4aae6521c84f4a18d92ad5035af5b247d283140
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Made QPromise::swap public, added free standing swap() for
QFutureInterface and QPromise. Updated QPromise special member
functions. Extended tests
Task-number: QTBUG-84977
Change-Id: I5daf6876df306d082441dbcdf5ae4dee3bfc0ead
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
We already had append(const QList &) and now there's an overload
taking an rvalue reference.
Change-Id: Id2fbc6c57badebebeee7b80d15bb333270fa4e19
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I don't know why std::shared_ptr allows this, but why not.
[ChangeLog][Important Behavior Changes] QSharedPointer objects will now
call custom deleters even when the pointer being tracked was null. This
behavior is the same as std::shared_ptr.
Fixes: QTBUG-85285
Pick-to: 5.15
Change-Id: I24006db8360041f598c5fffd161c260df0313b55
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
‘t’
Specifies that the argument is a ‘ptrdiff_t’.
This modifier was introduced in ISO C99.
We use qsizetype, which is the same width as ptrdiff_t, so it makes no
difference in va_arg().
Change-Id: Iea47e0f8fc8b40378df7fffd16255730109413a5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Deprecated in 5.15 in favor of CBOR.
Fixes: QTBUG-81239
Change-Id: I711d4bd7dd1247f58e77ac9fa53304cbe5028918
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Our hardware optimized conversions of float to qfloat16 rounds to even
where our table based conversion truncated to zero.
The rounding is not in this patch exactly round to even like the
hardware implementation but much closer.
Change-Id: I4c5e72c15fef9079d3660680b2727ff7ba4e768a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
BLAKE2 does not specify requirements about specific hash sizes and
since QCryptographicHash does not support dynamic hash sizes, only the
most common hash sizes could be covered by this.
The supported hash sizes were chosen to match the ones supported by the
Linux kernel.
The new hashing algorithms for QCryptographicHash are:
* BLAKE2b (160 bit, 256 bit, 384 bit, 512 bit)
* BLAKE2s (128 bit, 160 bit, 224 bit, 256 bit)
[ChangeLog][QtCore][QCryptographicHash] Added BLAKE2b and BLAKE2s
hashing algorithms.
Fixes: QTBUG-78198
Change-Id: Id9e0180a974093982fdf1cdd6180988a2e5e9f4f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We already have the information in the QMetaTypeInterface, and provide
functions to access sizeof. Adding alignof support seems natural, and
should make it easier to handle over-aligned types.
This should also be helpful in QVariant.
Change-Id: I166be76f4b7d2d2e524a3a1e513bd2f361e887c1
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The tests are testing deprecated functionality, which we
still want to test.
Change-Id: Iad6ed35800896170c17fe019c7a6ecda22398ac3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
