summaryrefslogtreecommitdiffstats
path: root/src/corelib/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* QBitArray: refactor operator~() to write to an uninitialized bufferThiago Macieira2023-12-072-11/+22
| | | | | | | No functionality change otherwise. Change-Id: I85b3fc2dd45c4693be13fffd179627b2747c132b Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QSpan: add some C++20 reminder code commentsMarc Mutz2023-12-071-1/+3
| | | | | Change-Id: I1cd698bde290cbd37d13103cd6832a739d9c548b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Long live QSpan as public API!Marc Mutz2023-12-074-401/+1067
| | | | | | | | | | | Provide qspan_p.h as backward-compatibility header. [ChangeLog][QtCore][QSpan] New Qt equivalent of std::span. Fixes: QTBUG-115022 Change-Id: I1cc27dc0aa1f7406f0a41d7a75f176cd7f858feb Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QSpan: fix an MSVC warning-turned-error:Marc Mutz2023-12-071-1/+1
| | | | | | | | | | | | qspan_p.h(35): error C2220: the following warning is treated as an error qspan_p.h(35): warning C4245: 'initializing': conversion from 'int' to 'const size_t', signed/unsigned mismatch Add an explicit (functional-style) cast to silence it. Pick-to: 6.6 Change-Id: Id29fda3def1c60415b3e0fe72eaf82c8bc57d363 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add documentation for the private API QAtomicScopedValueRollbackRym Bouabid2023-12-071-0/+124
| | | | | | | | Task-number: QTBUG-115107 Pick-to: 6.6 6.5 Change-Id: Icdb09d803f1d789b91ae5c1806470d71adb59067 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Refuse to relocate non-copy/move-constructible typesMarc Mutz2023-12-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a type was explicitly made non-copyable and non-movable, refuse attempts to mark it as relocatable. Trivial relocatability is an optimization for move+destroy, so we shouldn't allow working around the class author's wish to have a non-movable type by a user making it Q_RELOCATABLE_TYPE. Therefore, add a static_assert() to Q_DECLARE_TYPEINFO that fires when a non-copy/move-constructible type is made Q_RELOCATABLE_TYPE. Also add a similar static assertion to QTypeInfoMerger: All members of a class T may be Q_RELOCATABLE_TYPE. But that doesn't mean that T itself is: class T { QString m_s; QByteArray m_b; Q_DISABLE_COPY(T) public: ~~~~ }; so check that T is actually copyable (or movable) when QTypeInfoMerger would have have yielded isRelocatable. Since Q_DECLARE_TYPEINFO and QTypeInfoMerger are not the only ways in which a user can mark a type as relocatable (manual QTypeInfo specialization is another option, and required, for certain template classes), also check in q_uninitialized_relocate_n(). [ChangeLog][QtCore][QTypeInfo/QTypeInfoMerger] No longer allows marking as Q_RELOCATABLE_TYPE a type that is neither movable nor copyable. Change-Id: If6b3e5c1bfb6538bd280262eefbb08ba3c810e4c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QSpan: ensure interoperability with std::spanMarc Mutz2023-12-071-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We accepted QSpan as a NIH-type instead of waiting for C++20 and std::span, because we said that there's no impedance mismatch between the two, as they both implicitly convert into each other. But we actually never checked that they do. Fix this omission by adding constructors that treat std::span exactly the same as QSpan itself, and adding the respective static_assert()s to tst_QSpan to check that (within the constraints imposed by the standard on std::span), they actually do convert into each other. The only two problematic cases are that fixed-size std::span constructors are explicit, so span is only constructible, not convertible, from QSpan. Likewise, for an rvalue QSpan to be acceptable to the std::span constructor, QSpan needs to opt-in to enable_borrowed_range (while we're at it, do enable_view, too). We so far have rejected adding these opt-ins for our own container classes because we wanted to avoid the compile-time overhead of including the huge <ranges> header into such central headers as those that define our containers. But std::span itself has to specialize these traits, and its range contructor has to use them, so they must be available from <span>, too, possibly the stdlib puts the definition into a much smaller header. So just assume we can specialize it after including just <span>, provided __cpp_lib_concepts is also defined. Pick-to: 6.6 Change-Id: I2202869b60c98047256b0fbcb12336f5d8e550ba Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QSpan: don't truncate QSpan::extentMarc Mutz2023-12-071-1/+1
| | | | | | | | | | | | | | | | | My notes inform me that my intent was for QSpan::extent to be size_t, for compatibility with both its template argument and std::span::extent. So fix it to be size_t instead of qsizetype. While extents that go beyond numeric_limits<qsizetype>::max() will be unusable in practice, QSpan doesn't actually allocate memory, so declaring one should be possible, if only for compatibility with std::span, without getting into a situation where E != extent. Pick-to: 6.6 Change-Id: Ic8ae3a1c03801b4a23b7ba56388372cac64f9e5e Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QSpan: make it a bit more QDoc-friendlyMarc Mutz2023-12-071-9/+12
| | | | | | | | | | | | | Hide the base class; the documentation isn't supposed to show this implementation detail. Don't use auto return types for the begin/end family of member functions; QDoc doesn't resolve them, but just shows auto, which, without seeing the implementation, is pretty useless. Pick-to: 6.6 Change-Id: If75cc1e7de9c5c1490cb37241739449df4e5d0c2 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QSharedPointer: Remove support code for tracking weak-pointerFabian Kosmale2023-12-062-6/+9
| | | | | | | | | | | | | | In Qt 6, it is no longer possible to create a weak pointer from a plain QObject pointer. Consequently, we don't need the work-aronuds introduced for QTBUG-22622. Except that we still need to keep the functions as they are exported. Mark them as QT6_ONLY, so that they'll be gone automatically come Qt 6. Amends e40320c552a9ccd4c1879a4da13c8d909b2cd21e. Change-Id: I568da04008374c891a111eee49f6679dabdfdee4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Doc: Settle on 'function' instead of 'method' in QMAC documentationKai Köhne2023-12-051-3/+3
| | | | | | | | | | Function is the more popular term in the documentation. Method is also a tad confusing, because QCryptographicHash calls the algorithm 'method'. Pick-to: 6.6 Change-Id: I9922f837b04311a4ef45e1c6de6b8e12a32e4f1e Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* Doc: Improve documentation for QMessageAuthenticationCodeKai Köhne2023-12-041-8/+19
| | | | | | | | | | | | | | | * Mention 'HMAC' as something people will search for * Change description to actually reflect code snippet (where the key is passed to the constructor) * At least mention that the security of the HMAC depends also on the length of the key, as the code snippet uses an artificial/short key. Not sure whether we should further expand on this, or link to some other source? Pick-to: 6.5 6.6 Fixes: QTBUG-119499 Change-Id: I2768d9a9d553957e1a778c798d82a73468bee16f Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Doc: Fix \fn template arguments for Qt CoreLuca Di Sera2023-11-304-11/+11
| | | | | | | | | Upcoming changes to QDoc require accurate definition for template arguments in \fn commands. Task-number: QTBUG-118080 Change-Id: I64d50919bc6ffab61ef5ead553d1da99d63a9f21 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Doc: Fix template information for a qHash overloadLuca Di Sera2023-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc parses a project, it parses the source code to extract the user-provided documentation and perform sanity checkings based on the code itself on it. When QDoc parses an "\fn" command as part of this process, it tries to understand, based on its intermediate representation built on the information extracted from the code-base, which "documentable element" the "\fn" refers to. When QDoc performs this "matching" process, it takes into consideration only a certain amount of information. For example, no checking is performed over the template declaration of a callable. Due to some upcoming documentation, where two callables are indistinguishable to the current process, as they differ only in their template declaration, QDoc will start to take into consideration the template declaration of a callable when matching. This implies that an "\fn" command should now provide information parity, with regards to template declaration for callables, with the code-base so that QDoc can perform the match correctly. The documentation for `qHash(std::nullptr_t, size_t)` was providing a unnecessary template declaration. Hence, the incorrect additional information was removed from the `\fn` command. Task-number: QTBUG-118080 Change-Id: Iea406abbeb7aabd66e5b2ab092212d56b03cf42f Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* QPodArrayOps: don't set the new size in eraseIf() until after copyingThiago Macieira2023-11-171-1/+1
| | | | | | | | These are POD types, so there's nothing to be unwound in case of exceptions (and the only one that could happen is the Q_CHECK_PTR). Change-Id: I79e700614d034281bf55fffd178f91fe21685f03 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Doc: Fix template information for a QList constructorLuca Di Sera2023-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc parses a project, it parses the source code to extract the user-provided documentation and perform sanity checkings based on the code itself on it. When QDoc parses an "\fn" command as part of this process, it tries to understand, based on its intermediate representation built on the information extracted from the code-base, which "documentable element" the "\fn" refers to. When QDoc performs this "matching" process, it takes into consideration only a certain amount of information. For example, no checking is performed over the template declaration of a callable. Due to some upcoming documentation, where two callables are indistinguishable to the current process, as they differ only in their template declaration, QDoc will start to take into consideration the template declaration of a callable when matching. This implies that an "\fn" command should now provide information parity, with regards to template declaration for callables, with the code-base so that QDoc can perform the match correctly. The documentation for `QList::QList(InputIterator, InputIterator)` is not in sync with the intended target template declaration. Hence, add the missing information to the relevant "\fn" command. Task-number: QTBUG-118080 Change-Id: I576a3b71ba39cec0d51f08f7db9771401e1fa340 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Doc: Fix template information for a QScopedArrayPointer constructorLuca Di Sera2023-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc parses a project, it parses the source code to extract the user-provided documentation and perform sanity checkings based on the code itself on it. When QDoc parses an "\fn" command as part of this process, it tries to understand, based on its intermediate representation built on the information extracted from the code-base, which "documentable element" the "\fn" refers to. When QDoc performs this "matching" process, it takes into consideration only a certain amount of information. For example, no checking is performed over the template declaration of a callable. Due to some upcoming documentation, where two callables are indistinguishable to the current process, as they differ only in their template declaration, QDoc will start to take into consideration the template declaration of a callable when matching. This implies that an "\fn" command should now provide information parity, with regards to template declaration for callables, with the code-base so that QDoc can perform the match correctly. The documentation for `QScopedArrayPointer::QScopedArrayPointer(D*)` is not in sync with the intended target template declaration. Hence, add the missing information to the relevant "\fn" command. Task-number: QTBUG-118080 Change-Id: Icf4178989952bbc7dac9a0e8b7cfd031eed3a9d2 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Doc: Fix template information in "qsharedpointer.cpp"Luca Di Sera2023-11-171-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc parses a project, it parses the source code to extract the user-provided documentation and perform sanity checkings based on the code itself on it. When QDoc parses an "\fn" command as part of this process, it tries to understand, based on its intermediate representation built on the information extracted from the code-base, which "documentable element" the "\fn" refers to. When QDoc performs this "matching" process, it takes into consideration only a certain amount of information. For example, no checking is performed over the template declaration of a callable. Due to some upcoming documentation, where two callables are indistinguishable to the current process, as they differ only in their template declaration, QDoc will start to take into consideration the template declaration of a callable when matching. This implies that an "\fn" command should now provide information parity, with regards to template declaration for callables, with the code-base so that QDoc can perform the match correctly. Some of the documented callables in "qsharedpointer.cpp" are not in sync with the template declaration of their intended target. Hence, add the missing information to the relevant "\fn" commands. Task-number: QTBUG-118080 Change-Id: Iadac55e944aa425205b9d1cd8b4189ffacb4a089 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Add QUniqueHandle - a general purpose RAII wrapper for non-memory typesJøger Hansegård2023-11-151-0/+225
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When interfacing with C-style APIs, such as the Windows API, resources are often represented using handle objects. Lifetime management of such resources can be cumbersome and error prone, because typical handle objects (ints) do not give any help to release resources, and to manage ownership. Although std::unique_ptr can be retro-fitted with a custom deleter, and helps transfer of ownership, it is inherently a pointer type. It can therefore be clumsy to use with C-style APIs, particularly if the invalid (uninitialized) handle value is not a nullptr. Also, the std::unique_ptr does not work well when an allocating function returns the handle as a pointer argument. The QUniqueHandle addresses these issues by providing a movable only value type that is designed as a RAII handle wrapper. A similar handle wrapper exists in the Windows SDK, as part of the WRL library. Unfortunately, this is Microsoft specific, and is not supported by MINGW. Since the QUniqueHandle is platform independent, it can be used also with non- Microsoft platforms, and can be useful with other C-style APIs such as FFmpeg or SQLite. Pick-to: 6.6 6.5 Change-Id: Ibfc0cec3f361ec004febea5f284ebf75e27c0054 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Doc: Fix template information for QTypeRevision membersLuca Di Sera2023-11-131-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc parses a project, it parses the source code to extract the user-provided documentation and perform sanity checkings based on the code itself on it. When QDoc parses an "\fn" command as part of this process, it tries to understand, based on its intermediate representation built on the information extracted from the code-base, which "documentable element" the "\fn" refers to. When QDoc performs this "matching" process, it takes into consideration only a certain amount of information. For example, no checking is performed over the template declaration of a callable. Due to some upcoming documentation, where two callables are indistinguishable to the current process, as they differ only in their template declaration, QDoc will start to take into consideration the template declaration of a callable when matching. This implies that an "\fn" command should now provide information parity, with regards to template declaration for callables, with the code-base so that QDoc can perform the match correctly. The documentation for of the members of `QTypeRevision` is not in sync with the intended target template declaration. Hence, add the missing information to the relevant "\fn" commands. Task-number: QTBUG-118080 Change-Id: Id121fb926cdd1a7905be1693f8d9fb90834a99e0 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Doc: Fix template information for a QSet constructorLuca Di Sera2023-11-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc parses a project, it parses the source code to extract the user-provided documentation and perform sanity checkings based on the code itself on it. When QDoc parses an "\fn" command as part of this process, it tries to understand, based on its intermediate representation built on the information extracted from the code-base, which "documentable element" the "\fn" refers to. When QDoc performs this "matching" process, it takes into consideration only a certain amount of information. For example, no checking is performed over the template declaration of a callable. Due to some upcoming documentation, where two callables are indistinguishable to the current process, as they differ only in their template declaration, QDoc will start to take into consideration the template declaration of a callable when matching. This implies that an "\fn" command should now provide information parity, with regards to template declaration for callables, with the code-base so that QDoc can perform the match correctly. The documentation for `QSet::QSet(InputIterator, InputIterator)` is not in sync with the intended target template declaration. Hence, add the missing information to the relevant "\fn" command. Task-number: QTBUG-118080 Change-Id: I7e20331af3ca0c8d09ffdb6acf3292b46ca79651 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* QBitArray: move a few methods more into the class bodyThiago Macieira2023-11-101-7/+4
| | | | | | | | | This reduces the size of the header. I renamed the arguments for fill() because "size" would shadow a member function. Change-Id: I85b3fc2dd45c4693be13fffd1795b706b92e0965 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* QBitArray: fix GCC 13 warnings by improving codeThiago Macieira2023-11-081-25/+27
| | | | | | | | | | | | | | | | | | | | | | | | GCC 13 has been complaining that QBitArray could be accessing past the end of an array (specifically, the 1-element array QByteArray::_empty). That's caused by the 'QByteArray::data() const' being: #if QT5_NULL_STRINGS == 1 return d.data() ? d.data() : &_empty; #else return d.data(); #endif A way to avoid this is to use operator[], which doesn't attempt to hide null pointers (it has an assertion). This is accomplished by writing nicer, more readable code, which is a nice benefit. Fixes: QTBUG-118631 Pick-to: 6.6 Change-Id: I85b3fc2dd45c4693be13fffd179579615a6ac98d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QCryptographicHash: fallback to non-OpenSSL implementation for KeccakJan Grulich2023-11-081-21/+44
| | | | | | | | | | | Current versions of OpenSSL 3 don't support Keccak hashes as these are going to be introduced with OpenSSL 3.2 so we should rather fallback to the non-OpenSSL implementation instead of using SHA3. Fixes: QTBUG-118814 Pick-to: 6.5 6.6 Change-Id: Iedeb81cd76d43d920fc10e1efdac261bc12a394c Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QCryptographicHash: Do not rely on auto-loading of the default providerJan Grulich2023-11-061-2/+5
| | | | | | | | | | | | | | | When using OpenSSL implementation, we were assuming the default provider will be automatically loaded, but this is not going to happen after it gets unloaded. Even the documentation says that automatic loading of the default provider occurs max once and if it's explicitly unloaded, it will not be automatically loaded again. In our case we are explicitly loading and unloading the provider after MD4 hash is used so using it afterwards we will always fail. Fixes: QTBUG-118227 Pick-to: 6.5 6.6 Change-Id: I8107b9ab02321b57978c3d25a061672fd2a7aee8 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* qarraydatapointer: use use std::exchange moreAnton Kudryavtsev2023-11-011-4/+3
| | | | | | | to simplify code Change-Id: I7fc6dd92922eb30a16260544223c1dbfc3162188 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QSP/QWP: introduce owner_before, owner_equal, owner_hashGiuseppe D'Angelo2023-10-263-0/+103
| | | | | | | | | | | | | | | | | | | | | | | | While at the moment we don't have aliasing support in QSharedPointer, introduce owner-based comparisons and hashing. This also fulfills some use cases in lieu of operator== for QWeakPointer (which got deprecated by bb23a05905d7dc0e416a646e40592436daa939f2). I'm using C++26/P1901's spelling of owner_equal, instead of Boost.SmartPtr's spelling (owner_equal*s*). Given the niche use case, the lack of interoperability with Qt's own containers, as well as the Standard comparison objects' semantics (std::owner_less, std::owner_equal), I don't think we should be giving these a Qt-ish name as it would be pretty useless. [ChangeLog][QtCore][QSharedPointer] Added owner_before, owner_equal, owner_hash. [ChangeLog][QtCore][QWeakPointer] Added owner_before, owner_equal, owner_hash. Done-with: Fabian Kosmale <fabian.kosmale@qt.io> Change-Id: I8b792ae79f14cd518ba4a006edaa17786a8352a0 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QString/QBA: add lvalue and rvalue overloads to first/last/sliced/choppedThiago Macieira2023-10-251-0/+20
| | | | | | | | | | | | Those ought to have been the original implementation, when they were added in commit 38096a3d7040edac4f769270d2402ff4e39d7694, for Qt 6.0. Because these classes are exported, we need to provide the previous only implementations for MSVC. All other compilers would provide inline or emit local, out-of-line copies. Change-Id: Ifeb6206a9fa04424964bfffd178836a2ae56157d Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QArrayDataPointer: add an allocating constructorThiago Macieira2023-10-253-12/+19
| | | | | | | | It's by far the most common use, so having to call two things is just cumbersome. Change-Id: I79e700614d034281bf55fffd178f454c4e31929e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Revert "QWeakPointer: deprecate its relational operators"Volker Hilsheimer2023-10-251-8/+0
| | | | | | | | | | | | | | This reverts commit bb23a05905d7dc0e416a646e40592436daa939f2. Reason for revert: this change resulted in a flood of build-breaking warnings in submodules that need to be cleaned up before we try again. Also, the discussion following this change shows that this needs more clarification of the implications and options. Until that is concluded, the status quo is acceptable. Change-Id: Id8f67ed585517935c31e29d48099b1c84b787b74 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QWeakPointer: deprecate its relational operatorsGiuseppe D'Angelo2023-10-221-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They're fundamentally broken and should never ever be used. * op==(weak, weak) is heterogeneous, but at the same time it's unconstrained (!), may trigger UB (!) by doing a static_cast to a type which isn't the actual type of the pointee, and may outright crash (!) if the pointee has been deleted and there's virtual inheritance. * op==(weak, strong) compares the control blocks, i.e. does "owner_equal" comparison, not pointer comparison. Now QSP doesn't have support for aliasing, so the pointers stored by the smart pointers themselves always point at the owner object. Yet: given a QSharedPointer<T> that is the last owning pointer to T and a QWeakPointer<T> that tracks it, if one resets the shared pointer, then op==(wp, sp) will yield false (wp still points to the control block, sp does not), but op==(wp.lock(), sp) will yield true (both shared pointers are null). That doesn't make any sense. I'm leaving op==(wp, std::nullptr_t) in as a shorthand to check if the weak pointer is expired, but might deprecate that as well in a future commit. [ChangeLog][QtCore][QWeakPointer] The (in)equality operators of QWeakPointer have been deprecated. Always upgrade a QWeakPointer to a QSharedPointer (for instance, via lock()) before doing a comparison. Change-Id: Ia2f5f5e9e5558e1558b6084542532515c80b78b0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QAtomicScopedValueRollback: fix UB (passing rel/acq_rel to std::atomic::load())Marc Mutz2023-10-171-2/+20
| | | | | | | | | | | | | It's explicitly undefined behavior to pass release/acq_rel memory_order to load(), so don't. This is private API, so no ChangeLog needed. Reported-by: Fabian Kosmale <fabian.kosmale@qt.io> Task-number: QTBUG-115107 Pick-to: 6.6 6.5 Change-Id: Iee119303d790c31937238ef92d900a25020e9713 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Add missing return type to QList/QVarLengthArray::assignLuca Di Sera2023-10-132-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc reads an `\fn` command it saves it to a file to parse it with Clang, with the objective of using the produced AST to perform certain sanity checks on the documented element. Generally, `\fn` commands that do not represent correct C++ code with are accepted as long as Clang is still able to build an AST Node that QDoc can work with, not resulting in any issue in the output documentation. For example, an `\fn` that doesn't state a return type might be able to be parsed correctly enough by Clang to produce a sensible Node for the function that QDoc is interested into. The documentation for the various overloads for QList::assign and QVarLenghtArray::assign makes use of this possibility by not stating a return type. Up to Clang 15 this was not an issue, and a correct-enough AST was produced when the `\fn` commands for those methods were parsed. On Clang 16, Clang chokes on the missing return type, being unable to recognize the function definition and produce an AST that QDoc can work with. This has the effect of losing those documented element in the output documentation. To avoid the issue, a return type is now added to the relevant `\fn` commands. Change-Id: Ic1434aaf71c39840c64ce04fbd503c4542dc4f42 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QSpan: add C++23 c{,r}{begin,end}()Marc Mutz2023-10-121-0/+6
| | | | | | | | | It was weird that they were missing. Now that C++23 added them to std::span, add them to QSpan, too. Pick-to: 6.6 Change-Id: I4a9b1fdeda66bc7b133c8f7b3b269656e5faffa3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QSet: de-pessimize binary operatorsMarc Mutz2023-10-122-18/+23
| | | | | | | | | | | | | | | | | | Overload the binary QSet operators |, &, + and - for rvalue LHSs, so chained operations like e.g. in qgesturemanager.cpp: QSet<QGesture *> endedGestures = finishedGestures + canceledGestures + undeliveredGestures + maybeToCanceledGestures; become as efficient as chained op+= calls. Make the operators hidden friends as a drive-by. [ChangeLog][QtCore][QSet] The binary operators &, |, + and - are now hidden friends, and chaining them has been made a lot more efficient. Change-Id: I55d2247b11d088eb1ef88608f89d2bf9e1daeb58 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QSpan: remove a stale static constexpr `extent` from a base classMarc Mutz2023-10-121-2/+1
| | | | | | | | | | | | | It's not needed, and might trigger -Wshadow on some compilers. Only the public QSpan class has the `extent` static data member, everything else uses the template argument, `E`, directly. Amends f82cf6333e4e21c96d8b6bb272392f8142ead2b7. Pick-to: 6.6 Change-Id: If378119aff1e352d1e90854b570720444cd532a0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
* QArrayData: remove contradicting const qualifier from needsDetach()Thiago Macieira2023-10-111-1/+1
| | | | | | | | | | The documentation above says it's intentionally not const and that's how I had designed it. It was added by accident on with the noexcept qualifier on commit c129362b4d9512bd33004d430bc3b817546cb1b7 ("Add a couple of noexcept"). Change-Id: I8f3ce163ccc5408cac39fffd178c7fd237c6e079 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Doc: Fix warnings and linking issuesTopi Reinio2023-10-091-5/+3
| | | | | | | | | | | | | | | | | | | | Remove or replace links to examples that were removed or moved under manual tests. Replace code snippets that were quoting the now-missing examples. Fix documentation of QSet::removeIf(). Fix typo in documentation macro: Unknown command '\examplecateogry'. Add qtopengl, qtshadertools dependencies to Qt Widgets documentation project to enable correct linking to those topics. Mark all documentation sets in qtbase as free of warnings. Pick-to: 6.6 6.5 Change-Id: I058cd5f2063aa933ea310bceff906f05422a7cb2 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* QMap/MultiMap/Hash/MultiHash: synchronize documentationChristian Ehrlicher2023-10-043-6/+16
| | | | | | | | | | | Synchronize the documentation of the four container classes: - document the return type of insert() and replace() - don't reference QMultiHash/Map from QHash/Map except in the details paragraph Task-number: QTBUG-117757 Change-Id: I93ee7eec0c298854e05e83a43f1c7cffd0610d72 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QCryptographicHash: don't forget to unload OpenSSL providersJan Grulich2023-10-021-5/+15
| | | | | | | | | | | | | Automatically unload loaded crypto providers on cleanup. In most cases we don't load them, but when we do (e.g. when MD4 is used), we would be leaking memory. Fixes: QTBUG-115233 Pick-to: 6.5 6.6 Change-Id: I91318d391ab35d00647d1e9e2408fc987811a2d3 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QAtomicScopedValueRollback: fix a typoMarc Mutz2023-10-011-1/+1
| | | | | | | Pick-to: 6.6 6.5 Task-number: QTBUG-115107 Change-Id: I9ca5d143b5c89443fc40859c035be43cde3d73c4 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QAtomicScopedValueRollback: make store_part() staticMarc Mutz2023-10-011-1/+1
| | | | | | | | | ... because we can. Pick-to: 6.6 6.5 Task-number: QTBUG-115107 Change-Id: I23b5edc6111615cbd0352847b2f1a1667948c40a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add a verify() method to all sequential containersAhmad Samir2023-09-281-18/+12
| | | | | | | | | | | | | | | | | | | A helper method encasuplating the asserts related to index into the container and length, modelled after the QVLA::verify(). `pos <= size` is OK because if pos == size, the e.g. sliced()'ed container is just going to be empty. Normalize how verify() is used, the first arg is an index and the second a length. This method is constexpr even in QString/QByteArray merely for consistency with similar methods in other string classes (this necessitates using `d.size` in verify() in QString/QBA because size() isn't constexpr). Change-Id: I90e3c56d76c802259297a06d11d46ee342a1daf2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QWeakPointer: optimize the converting constructorGiuseppe D'Angelo2023-09-261-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The converting constructor of QWeakPointer<T> from a QWeakPointer<X> needs to adjust the X* received by the "source" to a T*. In case of non-virtual inheritance, this adjustment can be done statically, by applying an offset to the pointer. In case of virtual inheritance, we instead need to dereference the pointer (=access the pointee), get its vtable, and from there find where (=the offset at which) the T subobject is located. This latter scenario requires the pointee to be alive throughout this operation. Since QWeakPointer isn't an owning smart pointer, it's perfectly possible that the pointee has already been deleted (the "source" QWeakPointer<X> is dangling) or is being deleted (e.g. from another thread that has just released the last QSharedPointer). For this reason the converting constructor of QWeakPointer employs a protection: it will lock() itself, and extract the raw pointer from the QSharedPointer so obtained. This ensures that we won't access a dangling pointer or a pointee about to be deleted. We can however limit this (relatively expensive) protection only to the case where there is virtual inheritance. In the other cases we don't need it. This commit overloads the converting constructor for QWeakPointer to deal with the two scenarios separately, and only lock() in case of virtual inheritance. Change-Id: I7194b90478cf35024e60cff542091308e4131ec2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QWeakPointer: fix the converting constructor from rvaluesGiuseppe D'Angelo2023-09-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When constructing a QWeakPointer<T> from a rvalue QWeakPointer<X>, even if X* is convertible to T*, actually doing the conversion requires access to the pointee's vtable in case of virtual inheritance. For instance: class Base { virtual ~Base(); }; class Derived : public virtual Base {}; Now given a `Derived *ptr`, then a conversion of `ptr` to `Base *` is implicit (it's a public base), but the compiler needs to dereference `ptr` to find out where the Base sub-object is. This access to the pointee requires protection, because by the time we attempt the cast the pointee may have already been destroyed, or it's being destroyed by another thread. Do that by going through a shared pointer. (This matches the existing code for the converting assignment.) This requires changing the private assign() method, used by QPointer, to avoid going through a converting move assignment/construction, because one can't upgrade a QWeakPointer tracking a QObject to a QSharedPointer. Given it's the caller's responsibility to guard the lifetime of the pointee passed into assign(), I can simply build a QWeakPointer<T> and use ordinary (i.e. non-converting) move assignment instead. Change-Id: I7743b334d479de7cefa6999395a33df06814c8f1 Pick-to: 6.5 6.6 Fixes: QTBUG-117483 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QCommandLineParser: Warn invalid value callsAleix Pol2023-09-211-3/+9
| | | | | | | | | | | If the QCommandLineOption doesn't have a valueName, the parser won't read the argument, therefore returning an empty value. If the developers are calling ::value on the option, they clearly think it's expected to get a value but won't ever be getting one, so we better warn them about it. Change-Id: I434b94c0b817b5d9d137c17f32b92af363f93eb8 Reviewed-by: David Faure <david.faure@kdab.com>
* qcommandlineparser: use const method moreAnton Kudryavtsev2023-09-091-1/+1
| | | | | | | to avoid implicit detach Change-Id: If01c2d777ceb61e9f919ff0109d054bb7e74a418 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QList: use new assign() in operator=(std::initializer_list)Dennis Oberst2023-09-071-4/+1
| | | | | | | | | | | | | operator=(~) and assign(~) share similar names but, until now, have not shared the same functionality. This patch introduces the usage of QList::assign() within the non-sharing assignment operator to effectively boost efficiency by reusing the available capacity. Task-number: QTBUG-106201 Change-Id: I01a0511af336f2f410158a07d91e5759c8ff46db Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QArrayDataPointer: remove Q_CHECK_PTR in assign(it, it) againDennis Oberst2023-09-071-2/+0
| | | | | | | | | | | | | | | | | | | | | | | This commit reverts 2d77051f9dfd11ae292ad4bac2f28c5f7a0e7f83. When requesting an allocation of size 0, we will actually get a nullptr. qarraydata.cpp: ~~~ if (capacity == 0) { *dptr = nullptr; return nullptr; } This will let the Q_CHECK_PTR trigger falsely. Such an occurrence was initially detected during the cmake_automoc_parser build-step. Found-by: Marc Mutz <marc.mutz@qt.io> Task-number: QTBUG-106196 Pick-to: 6.6 Change-Id: Icb68c5dd518c9623119a61d5c4fdcff43dc4ac5d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove redundant QPair includesAhmad Samir2023-09-061-1/+1
| | | | | | | | Nothing in those files uses QPair; and a local build finished fine without them. Task-number: QTBUG-115841 Change-Id: I669cfecaa9129bce6b31e464826287f138b159db Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-28 10:07:25 +0000