summaryrefslogtreecommitdiffstats
path: root/src/corelib/doc/snippets
Commit message (Collapse)AuthorAgeFilesLines
* QFutureInterface: add a warning when an existing continuation is overwrittenIvan Solovev12 hours1-0/+14
| | | | | | | | | ... and also extend the documentation to explain this case explicitly. Fixes: QTBUG-107545 Pick-to: 6.5 6.2 Change-Id: I9414cc677b037989de60e97871485018e5c8a569 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Corelib: s/Q_OS_MAC/Q_OS_DARWIN/wg except for doc and definitionEdward Welbourne8 days1-1/+1
| | | | | | | | | | I got tired of being told off by the inanity 'bot for faithfully reflecting existing #if-ery in new #if-ery. Retain only the documentation and definition of the deprecated define. Change-Id: I47f47b76bd239a360f27ae5afe593dfad8746538 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Doc: Update docs to reflect method being renamedAndreas Eliasson2023-03-081-1/+1
| | | | | | | | | The new method has been renamed from markDirty to notify. Fixes: QTBUG-111267 Pick-to: 6.5 6.5.0 6.4 Change-Id: Ib7926a315cfd11ca6930c785290089b7031d34ff Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMessageAuthenticationCode: use SHA-256 instead of insecure SHA-1 in doc sippetMarc Mutz2023-02-231-3/+3
| | | | | | Pick-to: 6.5 Change-Id: I5b39229abbb3e21d90fd83f5f3bcbe1afe609526 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMessageAuthenticationCode: remove lazy initialization of messageHashMarc Mutz2023-02-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This just complicates the code, for the small benefit of avoiding a messageHash seeding from an empty key that then has to be reset. This lazy initialization is in the way of using QCH's SmallByteArray for the key, which this author thinks is the more important optimization, because it will allow passing keys by QByteArrayView, removing the impedance mismatch between QMAC and QCH. Since the QMAC API doesn't distinguish between the absence of a key, and the presence of a null (ie. empty) key, we can't not call initMessageHash() when the key is empty, so we should suggest to pass the actual key to the constructor as often as possible, and use setKey() only to change the key afterwards. [ChangeLog][QtCore][QMessageAuthenticationCode] No longer delays processing of the key to the first setData() or result() call. While passing a default-constructed key to the constructor and then calling setKey() continues to work, for optimal performance, we suggest to pass the actual key as a constructor argument and call setKey() only to change the key. Pick-to: 6.5 Change-Id: If0a078f37a16f8306f77d2b2bd5dacf23ce5c3e2 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Rename QBA::{to,from}Uint8Array() → {to,from}EcmaUint8Array()Marc Mutz2023-02-211-2/+2
| | | | | | | | | Found in API review: from/toUintArray() is too generic a name, make sure its name gives enough context. Pick-to: 6.5 Change-Id: Ie10ff06ae11a5e168c4c91b60a9698a41d0429fc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Avoid potential data races caused by qt_ntfs_permission_lookupMate Barany2023-02-081-0/+15
| | | | | | | | | | | | | | | | | qt_ntfs_permission_lookup is a global, non-atomic variable which could cause problems in case of multiple threads. Introduce a new atomic variable to handle permission lookups but instead of manual incrementation/decrementation, implement a class to manage the variable. Since the atomic variable is not directly available to the user, implement helper functions to increase/decrease/check the status of the variable. Task-number: QTBUG-105804 Change-Id: If6cbcdd653c7f50ad9853a5c309e24fdeb520788 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* IPC: add native key support to QSystemSemaphoreThiago Macieira2023-01-221-2/+2
| | | | | | | | | | | And deprecate the non-native key support API. Qt 7 may not even store the old, non-native Qt. Documentation in a new commit, when the dust settles. Change-Id: I12a088d1ae424825abd3fffd171d2b549eeed040 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Documentation: Port code snippets to new connection syntaxFriedemann Kleint2023-01-111-1/+1
| | | | | | | Pick-to: 6.5 6.4 6.2 Task-number: PYSIDE-2182 Change-Id: I5f800cf3a4a7afefbc36a79372fc35449fa953f0 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QUrl/doc: explain that the scheme-less URL is probably not intendedThiago Macieira2023-01-061-0/+8
| | | | | | | | | It is a valid URL reference, which is not what people may want. Fixes: QTBUG-109855 Pick-to: 6.4 6.5 Change-Id: I69ecc04064514f939896fffd173783ce2228c1d2 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Slow Deprecation of FILENAME_VARIABLE, replacement by OUTPUT_SCRIPTAmir Masoud Abdol2023-01-051-1/+1
| | | | | | | | | | | | | As discussed in the latest CMake API Review, we are deprecating the FILENAME_VARIABLE variable name everywhere, and replacing it with OUTPUT_SCRIPT. [ChangeLog][CMake] The FILENAME_VARIABLE option of qt_generate_deploy_script and qt_generate_deploy_app_script is now deprecated, use OUTPUT_SCRIPT option instead. Change-Id: Ic8be33eefbc48540166ea0fcf1d1948b052d4b8a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* QStringBuilder: document issues with using "auto" keywordAhmad Samir2023-01-011-0/+23
| | | | | | | | Cleanup QStringBuilder API docs. Task-number: QTBUG-104354 Change-Id: I00029c8f4bfdf35869396ac14d7d9ba0da34cdb5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: Allow contents of resources to be replaced by empty filesUlf Hermann2022-12-171-0/+4
| | | | | | | | | | | | | | | This makes it possible to process QML files using qmlcachegen, and retain the file nodes in the resource file system, but remove their actual content from the binary. To do so, you need to mark your files with the QT_DISCARD_FILE_CONTENTS source file property. Fixes: QTBUG-87676 Fixes: QTBUG-103481 Fixes: QTBUG-102024 Fixes: QTBUG-102785 Change-Id: I93d5a2bfca1739ff1e0f74c8082eb8aa451b9815 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: hjk <hjk@qt.io>
* Adapt QDateTime to route QTimeSpec uses via QTimeZoneEdward Welbourne2022-12-091-0/+8
| | | | | | | | | | | | | | | | | | | | | | Free most APIs using QTimeZone from feature timezone and route all APIs taking a naked QTimeSpec via these, in preparation for their eventual deprecation. Since qtimezone.h includes qdatetime.h (and MSVC blocks our ability to remove the need for that), qdatetime.h's declarations can't use a default value for QTimeZone parameters; so add overloads taking no zone (or spec) to handle that. [ChangeLog][QtCore][QDateTime] All QDateTime APIs involving a Qt::TimeSpec can now be routed via QTimeZone's lightweight time description support, saving the need to have different code paths for different time specs. In the process, QDateTime gains a timeRepresentation() method to return a QTimeZone reporting the (possibly lightweight) time description it uses. (The older timeZone() method always returns a non-lightweight QTimeZone, whose timeSpec() is Qt::TimeZone.) Task-number: QTBUG-108199 Change-Id: I23e43401eb2dbe9b7b534ca6401389920dd96b3c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Doc: Add documentation for qCFatal()Kai Köhne2022-12-051-0/+14
| | | | | Change-Id: Iad9ea51285300eb06fdd7e68dd747702cb0a80e5 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* wasm: add native QByteArray conversion functionsMorten Sørvig2022-12-051-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add functions which converts to and from JavaScript data arrays: static QByteArray::fromUint8Array(emscripten::val array) emscripten::val QByteArray::toUint8Array() const with corresponding internal qstdweb API: static Uint8Array Uint8Array::copyFrom(const QByteArray &buffer) QByteArray Uint8Array::copyToQByteArray() const Both functions will make a copy of the data, i.e. there is no shared reference counting. They take and return Uint8Array typed array views, via emscripten::val JavaScript object references. Unlike other native conversion functions, these have the special property that the data referenced by the native Uint8Array exists outside the heap memory area. This means we can’t e.g. memcpy the data. However, the heap is itself a JavaScript ArrayBuffer, and we can create a Uint8Array view to the buffer owned by the QByteArray, and then use JavaScript API to copy. See the qstdweb::Uint8Array::copy() implementation. That also means that a fromRawUint8Array() variant (which does not copy) is not possible to implement, since we can’t create a pointer to the source data. The inverse toRawUint8Array() is implementable - it would return a Uint8Array view which references the heap’s ArrayBuffer. However, this may turn out to be ill-advised, since Emscripten will create a new ArrayBuffer if/when it resizes the heap. In any case this left for a future expansion. Change-Id: Icaf48fd17ea8686bf04cb523cc1eb581ce63ed34 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* Brush up the container documentationFriedemann Kleint2022-12-021-6/+6
| | | | | | | | | Make the code snippets consistent, update the comparison table and fix some sentences. Pick-to: 6.4 6.2 Change-Id: Ic8baaa56805392855736164efa03d065330309fa Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Documentation: Fix information on how to iterate over listsFriedemann Kleint2022-11-241-18/+0
| | | | | | | | | | | | Remove the outdated code used for QStringList and point QStringList and QList to the containers page. Pick-to: 6.4 6.2 Task-number: QTBUG-108687 Change-Id: I6fae6410ca759f91da85832ddb9f24e8a0ce202b Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Documentation: Expand documentation on how to iterate Qt containersFriedemann Kleint2022-11-241-0/+21
| | | | | | | | | | Introduce a section on iteration and add range-based for and index. Pick-to: 6.4 6.2 Task-number: QTBUG-108687 Change-Id: Icb1ff55049361769f7c0b042d42f70148dd07c2e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Documentation: Modernize the Qt container doc snippetsFriedemann Kleint2022-11-241-23/+15
| | | | | | | | | | | Use auto and initializer lists. Avoid repeated instantiations of end(). Pick-to: 6.4 6.2 Task-number: QTBUG-108687 Change-Id: I8482638cda63e21feaa7ca21370e7947dfb4b606 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Modernize QMessageBox documentation and exampleTor Arne Vestbø2022-11-181-2/+2
| | | | | | Change-Id: Iebcdf53646f1a42c327414edf21ac93a7d1c0a56 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QHash: tame HasQHashSingleArgOverload ODR violationsGiuseppe D'Angelo2022-11-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qhashfunctions.h defines a catch-all 2-arguments qHash(T, seed) in order to support datatypes that implement a 1-argument overload of qHash (i.e. qHash(Type)). The catch-all calls the 1-argument overload and XORs the result with the seed. The catch-all is constrained on the existence of such a 1-argument overload. This is done in order to make the catch-all SFINAE-friendly; otherwise merely instantiating the catch-all would trigger a hard error. Such an error would make it impossible to build a type trait that detects if one can call qHash(T, size_t) for a given type T. The constraint itself is called HasQHashSingleArgOverload and lives in a private namespace. It has been observed that HasQHashSingleArgOverload misbehaves for some datatypes. For instance, HasQHashSingleArgOverload<int> is actually false, despite qHash(123) being perfectly callable. (The second argument of qHash(int, size_t) is defaulted, so the call *is* possible.) -- Why is HasQHashSingleArgOverload<int> false? This has to do with how HasQHashSingleArgOverload<T> is implemented: as a detection trait that checks if qHash(declval<T>()) is callable. The detection itself is not a problem. Consider this code: template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; class MyClass {}; size_t qHash(MyClass); static_assert(HasQHashSingleArgOverload<MyClass>); // OK Here, the static_assert passes, even if qHash(MyClass) (and MyClass itself) were not defined at all when HasQHashSingleArgOverload was defined. This is nothing but 2-phase lookup at work ([temp.dep.res]): the detection inside HasQHashSingleArgOverload takes into account the qHash overloads available when HasQHashSingleArgOverload was declared, as well as any other overload declared before the "point of instantiation". This means that qHash(MyClass) will be visible and detected. Let's try something slightly different: template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; size_t qHash(int); static_assert(HasQHashSingleArgOverload<int>); // ERROR This one *does not work*. How is it possible? The answer is that 2-phase name lookup combines the names found at definition time with the names _found at instantiation time using argument-dependent lookup only_. `int` is a fundamental type and does not participate in ADL. In the example, HasQHashSingleArgOverload has actually no qHash overloads to even consider, and therefore its detection fails. You can restore detection by moving the declaration of the qHash(int) overload *before* the definition of HasQHashSingleArgOverload, so it's captured at definition time: size_t qHash(int); template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; static_assert(HasQHashSingleArgOverload<int>); // OK! This is why HasQHashSingleArgOverload<int> is currently returning `false`: because HasQHashSingleArgOverload is defined *before* all the qHash(fundamental_type) overloads in qhashfunctions.h. -- Now consider this variation of the above, where we keep the qHash(int) overload after the detector (so, it's not found), but also prepend an Evil class implicitly convertible from int: struct Evil { Evil(int); }; size_t qHash(Evil); template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; size_t qHash(int); static_assert(HasQHashSingleArgOverload<int>); // OK Now the static_assert passes. HasQHashSingleArgOverload is still not considering qHash(int) (it's declared after), but it's considering qHash(Evil). Can you call *that* one with an int? Yes, after a conversion to Evil. This is extremely fragile and likely an ODR violation (if not ODR, then likely falls into [temp.dep.candidate/1]). -- Does this "really matter" for a type like `int`? The answer is no. If HasQHashSingleArgOverload<int> is true, then a call like qHash(42, 123uz); will have two overloads in its overloads set: 1) qHash(int, size_t) 2) qHash(T, size_t), i.e. the catch-all template. To be pedantic, qHash<int>(const int &, size_t), that is, the instantiation of the catch-all after template type deduction for T (= int) ([over.match.funcs.general/8]). Although it may look like this is ambiguous as both calls have perfect matches for the arguments, 1) is actually a better match than 2) because it is not a template specialization ([over.match.best/2.4]). In other words: qHash(int, size_t) is *always* called when the argument is `int`, no matter the value of HasQHashSingleArgOverload<int>. The catch-all template may be added or not to the overload set, but it's a worse match anyways. -- Now, let's consider this code: enum MyEnum { E1, E2, E3 }; qHash(E1, 42uz); This code compiles, although we do not define any qHash overload specifically for enumeration types (nor one is defined by MyEnum's author). Which qHash overload gets called? Again there are two possible overloads available: 1) qHash(int, size_t). E1 can be converted to `int` ([conv.prom/3]), and this overload selected. 2) qHash(T, size_t), which after instantiation, is qHash<MyEnum>(const MyEnum &, size_t). In this case, 2) is a better match than 1), because it does not require any conversion for the arguments. Is 2) a viable overload? Unfortunately the answer here is "it depends", because it's subject to what we've learned before: since the catch-all is constrained by the HasQHashSingleArgOverload trait, names introduced before the trait may exclude or include the overload. This code: #include <qhashfunctions.h> enum MyEnum { E1, E2, E3 }; qHash(E1, 42uz); static_assert(HasQHashSingleArgOverload<MyEnum>); // ERROR will fail the static_assert. This means that only qHash(int, size_t) is in the overload set. However, this code: struct Evil { Evil(int); }; size_t qHash(Evil); #include <qhashfunctions.h> enum MyEnum { E1, E2, E3 }; qHash(E1, 42uz); static_assert(HasQHashSingleArgOverload<MyEnum>); // OK will pass the static_assert. qHash(Evil) can be called with an object of type MyEnum after an user-defined conversion sequence ([over.best.ics.general], [over.ics.user]: a standard conversion sequence, made of a lvalue-to-rvalue conversion + a integral promotion, followed by a conversion by constructor [class.conv.ctor]). Therefore, HasQHashSingleArgOverload<MyEnum> is true here; the catch-all template is added to the overload set; and it's a best match for the qHash(E1, 42uz) call. -- Is this a problem? **Yes**, and a huge one: the catch-all template does not yield the same value as the qHash(int, size_t) overload. This means that calculating hash values (e.g. QHash, QSet) will have different results depending on include ordering! A translation unit TU1 may have #include <QSet> #include <Evil> QSet<MyEnum> calculateSet { /* ... */ } And another translation unit TU2 may have #include <Evil> #include <QSet> // different order void use() { QSet<MyEnum> set = calculateSet(); } And now the two TUs cannot exchange QHash/QSet objects as they would hash the contents differently. -- `Evil` actually exists in Qt. The bug report specifies QKeySequence, which has an implicit constructor from int, but one can concoct infinite other examples. -- Congratulations if you've read so far. ========================= === PROPOSED SOLUTION === ========================= 1) Move the HasQHashSingleArgOverload detection after declaring the overloads for all the fundamental types (which we already do anyways). This means that HasQHashSingleArgOverload<fundamental_type> will now be true. It also means that the catch-all becomes available for all fundamental types, but as discussed before, for all of them we have better matches anyways. 2) For unscoped enumeration types, this means however an ABI break: the catch-all template becomes always the best match. Code compiled before this change would call qHash(int, size_t), and code compiled after this change would call the catch-all qHash<Enum>(Enum, size_t); as discussed before, the two don't yield the same results, so mixing old code and new code will break. In order to restore the old behavior, add a qHash overload for enumeration types that forwards the implementation to the integer overloads (using qToUnderlying¹). (Here I'm considering the "old", correct behavior the one that one gets by simply including QHash/QSet, declaring an enumeration and calling qHash on it. In other words, without having Evil around before including QHash.) This avoids an ABI break for most enumeration types, for which one does not explicitly define a qHash overload. It however *introduces* an ABI break for enumeration types for which there is a single-argument qHash(E) overload. This is because - before this change, the catch-all template was called, and that in turn called qHash(E) and XOR'ed the result with the seed; - after this change, the newly introduced qHash overload for enumerations gets called. It's very likely that it would not give the same result as before. I don't have a solution for this, so we'll have to accept the ABI break. Note that if one defines a two-arguments overload for an enum type, then nothing changes there (the overload is still the best match). 3) Make plans to kill the catch-all template, for Qt 7.0 at the latest. We've asked users to provide a two-args qHash overload for a very long time, it's time to stop working around that. 4) Make plans to switch from overloading qHash to specializing std::hash (or equivalent). Specializations don't overload, and we'd get rid of all these troubles with implicit conversions. -- ¹ To nitpick, qToUnderlying may select a *different* overload than the one selected by an implicit conversion. That's because an unscoped enumeration without a fixed underlying type is allowed to have an underlying type U, and implicitly convert to V, with U and V being two different types (!). U is "an integral type that can represent all the enumerator values" ([dcl.enum/7]). V is selected in a specific list in a specific order ([conv.prom]/3). This means that in theory a compiler can take enum E { E1, E2 }, give it `unsigned long long` as underlying type, and still allow for a conversion to `int`. As far as I know, no compiler we use does something as crazy as that, but if it's a concern, it needs to be fixed. [ChangeLog][Deprecation Notice] Support for overloads of qHash with only one argument is going to be removed in Qt 7. Users are encouraged to upgrade to the two-arguments overload. Please refer to the QHash documentation for more information. [ChangeLog][Potentially Binary-Incompatible Changes] If an enumeration type for which a single-argument qHash overload has been declared is being used as a key type in QHash, QMultiHash or QSet, then objects of these types are no longer binary compatible with code compiled against an earlier version of Qt. It is very unlikely that such qHash overloads exist, because enumeration types work out of the box as keys Qt unordered associative containers; users do not need to define qHash overloads for their custom enumerations. Note that there is no binary incompatibity if a *two* arguments qHash overload has been declared instead. Fixes: QTBUG-108032 Fixes: QTBUG-107033 Pick-to: 6.2 6.4 Change-Id: I2ebffb2820c553e5fdc3a341019433793a58e3ab Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Layouts docs: pass parent widget in the ctorAhmad Samir2022-10-212-9/+6
| | | | | | | | | This is a follow up from commit 1e904ab342c1aaa; changing more documentation to pass a widget * in the ctor of a layout, rather than creating a parent-less layout then calling setLayout(). Change-Id: I4fc59c6cfa46ccd279a153acd67335a6daf22ff9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Long live Q_UNREACHABLE_RETURN()!Marc Mutz2022-10-151-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a combination of Q_UNREACHABLE() with a return statement. ATM, the return statement is unconditionally included. If we notice that some compilers warn about return after __builtin_unreachable(), then we can map Q_UNREACHABLE_RETURN(...) to Q_UNREACHABLE() without having to touch all the code that uses explicit Q_UNREACHABLE() + return. The fact that Boost has BOOST_UNREACHABLE_RETURN() indicates that there are compilers that complain about a lack of return after Q_UNREACHABLE (we know that MSVC, ICC, and GHS are among them), as well as compilers that complained about a return being present (Coverity). Take this opportunity to properly adapt to Coverity, by leaving out the return statement on this compiler. Apply the macro around the code base, using a clang-tidy transformer rule: const std::string unr = "unr", val = "val", ret = "ret"; auto makeUnreachableReturn = cat("Q_UNREACHABLE_RETURN(", ifBound(val, cat(node(val)), cat("")), ")"); auto ignoringSwitchCases = [](auto stmt) { return anyOf(stmt, switchCase(subStmt(stmt))); }; makeRule( stmt(ignoringSwitchCases(stmt(isExpandedFromMacro("Q_UNREACHABLE")).bind(unr)), nextStmt(returnStmt(optionally(hasReturnValue(expr().bind(val)))).bind(ret))), {changeTo(node(unr), cat(makeUnreachableReturn, ";")), // TODO: why is the ; lost w/o this? changeTo(node(ret), cat(""))}, cat("use ", makeUnreachableReturn)) ); where nextStmt() is copied from some upstream clang-tidy check's private implementation and subStmt() is a private matcher that gives access to SwitchCase's SubStmt. A.k.a. qt-use-unreachable-return. There were some false positives, suppressed them with NOLINTNEXTLINE. They're not really false positiives, it's just that Clang sees the world in one way and if conditonal compilation (#if) differs for other compilers, Clang doesn't know better. This is an artifact of matching two consecutive statements. I haven't figured out how to remove the empty line left by the deletion of the return statement, if it, indeed, was on a separate line, so post-processed the patch to remove all the lines matching ^\+ *$ from the diff: git commit -am meep git reset --hard HEAD^ git diff HEAD..HEAD@{1} | sed '/^\+ *$/d' | recountdiff - | patch -p1 [ChangeLog][QtCore][QtAssert] Added Q_UNREACHABLE_RETURN() macro. Change-Id: I9782939f16091c964f25b7826e1c0dbd13a71305 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QString/doc: correct the record on const char* optimizationsThiago Macieira2022-10-021-0/+3
| | | | | | | | | | | This portion of the documentation was there since the Qt 4.5 import of the repository and may have been correct at the time. They haven't been for some time and definitely aren't now. So be clear that even if there are overloads, some of them are bad ideas. Pick-to: 6.2 6.3 6.4 Change-Id: I810d70e579eb4e2c8e45fffd1719adefb6f9f3bf Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QMetaType: Support custom unary converters with optional<To> return typeArno Rehn2022-09-271-0/+8
| | | | | | | | | | | | | | | To indicate success of a conversion, the public API has previously only supported registering member functions of the form To (From::*)(bool *). When adding custom converters for types that cannot be modified, this is usually not a possibility. As an alternative, this patch adds support for std::optional in the UnaryFunction overload of QMetaType::registerConverter. If the returned optional has no value, the conversion is considered failed. Task-number: QTBUG-92902 Change-Id: Ibac52d2cb9b5a2457081b4bebb0def1f03e3c55d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Update the animation framework overviewVenugopal Shivashankar2022-09-201-5/+89
| | | | | | | | | | | - Clarify how the object ownership works - Language clean up - Update the snippets Pick-to: 6.4 6.3 6.2 Task-number: QTBUG-106071 Change-Id: I7caf42a150ef82dee920df4d03db6fd988796bd4 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* CMake: Introduce qt_generate_deploy_scriptJoerg Bornemann2022-09-111-0/+27
| | | | | | | | | | | | | | | | | | Should the deployment script that qt_generate_deploy_app_script not be sufficient, the new function qt_generate_deploy_script can be used to generate a custom deployment script. Before, one had to add quite some boilerplate code to generate a custom deployment script. The qt_generate_deploy_app_script function now uses qt_generate_deploy_script internally. The TARGET option of qt_generate_deploy_script is currently only used for controlling the base name of the generated deployment script. We will do more with the target in a subsequent commit. Fixes: QTBUG-105731 Change-Id: I85bfc50dac1f0b0b1aae0f657f803e9e30f53616 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* QMetaObject/Doc: document the variadic invoke{,Method} and newInstanceThiago Macieira2022-09-011-0/+33
| | | | | Change-Id: Ic6547f8247454b47baa8fffd170dc646d4f73152 Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
* QMetaType/Doc: update some wording about type registrationThiago Macieira2022-08-291-5/+5
| | | | | | | | | | | | | | | Type registration isn't necessary any more, unless you're trying to look up a name back to ID or QMetaType object. It hasn't been since 6.0. Drive-by update the example not to use deprecated API. Drive-by remove the paragraph about requirements that aren't accurate any more. Pick-to: 6.4 Task-number: QTBUG-104858 Change-Id: Ic6547f8247454b47baa8fffd170eecb66719fa65 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Remove qmake-only reference in Q_IMPORT_PLUGIN descriptionKai Köhne2022-08-241-4/+0
| | | | | | | | | | The Static Plugins page describes handling of qmake and CMake already in greater detail. No need to replicate it here. Pick-to: 6.4 Task-number: QTBUG-88044 Change-Id: I2cae85c0b0d20585b563bab9e263121181adeb8c Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-08-232-2/+2
| | | | | | | Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* [docs] Fix return value of QStringIterator::next()Marc Mutz2022-08-111-1/+1
| | | | | | | | | | It's char32_t these days, not uint. Task-number: QTBUG-103531 Pick-to: 6.4 6.3 6.2 Change-Id: Iaa03f97d0d1266a6763eb858edb45ae0f2a4729d Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Move q{,Utf8, Utf16}Printable to qstring.hSona Kurazyan2022-08-042-10/+8
| | | | | | | Task-number: QTBUG-99313 Change-Id: I76ef84e4c90ab04a3e04c165ba46800e27ea6122 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QAbstractNativeEventFilter: Fix the Mac example class nameLaszlo Papp2022-08-041-1/+1
| | | | | | Change-Id: I838350883fa6bd8c80f87fba18f006afd905ed61 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add license headers to cmake filesLucie Gérard2022-08-032-0/+6
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* QAbstractNativeEventFilter: Add a Windows exampleLaszlo Papp2022-08-021-0/+20
| | | | | Change-Id: Ic378174e7f192abc27524cbcd925705c8bb46502 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove outdated docs for qOverload()Sona Kurazyan2022-08-011-5/+0
| | | | | Change-Id: Ie641b1f7100e7053e1fe0299a0b2b0bd708326af Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Doc: Document how to treat qt_add_big_resources args as source filesCristian Adam2022-06-161-0/+5
| | | | | | | | | | | | | | The arguments to qt_add_big_resources are not known to CMake as source files. They need to be added explicitly to a CMake target in order for Qt Creator to treat them as source files and in the case of a qrc file to expand the contents in the project view. Fixes: QTBUG-104320 Pick-to: 6.4 6.3 Change-Id: Iea755d998e8f9814a82983272731b0c654f80644 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Fix doc and example of QLoggingCategory::installCategory()Edward Welbourne2022-06-131-7/+10
| | | | | | | | | | | | | | | | | | | | | Snippet [22] was unused and the example using snippet [21] neglected to show how its oldCategoryFilter got initialized, which is what [22] does. But it turns out the example code was crashy in any case, as it left the oldCategoryFilter uninitialized (albeit probably null) until the call to installFilter() had returned, and installFilter() calls the new filter, so the new filter needs to check oldCategoryFilter before calling it. The doc also failed to explain why it's OK to not defer to the prior filter in these calls during installFilter(), so revise the doc and example so that the latter behaves sensibly and readers of the former are likely to use the function safely. This amends commit 8f0654ceb878b6c8a08c7f5b790027c26e007c13 which added the snippets and the use of one of them, but not the other. Fixes: QTBUG-49704 Pick-to: 6.4 6.3 6.2 5.15 Change-Id: Iddb8d97b0bef417d8f16e7910730cfa59ea3e715 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* QMap: remove more docs referring to multiple values for the same keyGiuseppe D'Angelo2022-05-291-16/+0
| | | | | | | | Such semantics have been dropped from Qt 6. Change-Id: I12f3478833afafa34f9075faf9ed030d06cd86f9 Pick-to: 6.2 6.3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use SPDX license identifiersLucie Gérard2022-05-16164-8039/+331
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Add support for unwrapping QFuture<QFuture<T>>Sona Kurazyan2022-04-211-0/+34
| | | | | | | | | | | | | | | | Added QFuture::unwrap() for unwrapping the future nested inside QFuture<QFuture<T>>. QTBUG-86725 suggests doing the unwrapping automatically inside .then(), but this will change the return type of .then() that used to return QFuture<QFuture<T>> and might cause SC breaks. Apart from that, QFuture::unwrap() might be helpful in general, for asynchronous computations that return a nested QFuture. [ChangeLog][QtCore][QFuture] Added QFuture::unwrap() for unwrapping the future nested inside QFuture<QFuture<T>>. Task-number: QTBUG-86725 Change-Id: I8886743aca261dca46f62d9dfcaead4a141d3dc4 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Replace uses of _qs with _s in sources and examplesSona Kurazyan2022-04-191-1/+1
| | | | | | Task-number: QTBUG-101408 Change-Id: I48360ba3b23965cd3d90ac243c100a0656a4cde8 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QDate: add conversions for std::chrono calendaring classesGiuseppe D'Angelo2022-04-131-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | std::chrono::year_month_day and related classes offer very convenient to specify dates. This patch adds implicit constructors to QDate to support this convenience, e.g.: // YYYY-MM-DD, DD-MM-YYYY, MM-DD-YYYY formats: QDate d1 = 1985y / December / 8; QDate d2 = 8d / December / 1985; QDate d3 = December / 8d / 1985; // Indexed weekday: QDate d4 = 2000y / January / Monday[0]; QDate d5 = 2000y / January / Monday[last]; and so on. These are all implemented using the conversion from the std calendaring classes to sys_days. Conversions between sys_days and QDate are also added, since they're basically "for free". I don't expect "ordinary" users to stumble upon it, but it's worthy mentioning that std::chrono::year *does* have a year zero (hence, year_month_day in year 0 or below are offset by one with the corresponding QDate). I've left a note in the documentation. [ChangeLog][QtCore][QDate] QDate (and therefore QDateTime) is now constructible using the year/month/day/week classes available in the std::chrono library. Moreover, it now features conversions from and to std::chrono::sys_days. Change-Id: I2a4f56423ac7d1469541cbb6a278a65b48878b4a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Doc: Document QT_NO_[SIGNALS_SLOTS_]KEYWORDS definesJoerg Bornemann2022-03-291-0/+5
| | | | | | | Pick-to: 6.2 6.3 Fixes: QTBUG-70564 Change-Id: I8ed1a30567dabdcb95cdfce009f1d9e0645d3226 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QtCore: Replace remaining uses of QLatin1String with QLatin1StringViewSona Kurazyan2022-03-262-2/+2
| | | | | | | Task-number: QTBUG-98434 Change-Id: Ib7c5fc0aaca6ef33b93c7486e99502c555bf20bc Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QtCore: replace QLatin1String/QLatin1Char with _L1/u'' where applicableSona Kurazyan2022-03-256-21/+31
| | | | | | | | | | | As a drive-by, did also minor refactorings/improvements. Task-number: QTBUG-98434 Change-Id: I81964176ae2f07ea63674c96f47f9c6aa046854f Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
* Add QByteArray::percentDecoded() as an instance methodEdward Welbourne2022-03-181-2/+7
| | | | | | | | | | | | | Percent-decoding was previously only present as a static method taking a QBA parameter; it might as well be an instance method of that parameter. Change most QBA tests to use it rather the static method. [ChangeLog][QtCore][QByteArray] percentDecoded() is now available as an instance method of the byte array to be decoded, equivalent to the static QByteArray::fromPercentEncoding(). Change-Id: I982101c44bdac5cc4041e85598d52ac101d38fa1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Associative containers: add a way to obtain a key/value rangeGiuseppe D'Angelo2022-03-043-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our associative containers' iterator's value_type isn't a destructurable type (yielding key/value). This means that something like for (auto [k, v] : map) doesn't even compile -- one can only "directly" iterate on the values. For quite some time we've had QKeyValueIterator to allow key/value iteration, but then one had to resort to a "traditional" for loop: for (auto i = map.keyValueBegin(), e = keyValueEnd(); i!=e; ++i) This can be easily packaged in an adaptor class, which is what this commmit does, thereby offering a C++17-compatible way to obtain key/value iteration over associative containers. Something possibly peculiar is the fact that the range so obtained is a range of pairs of references -- not a range of references to pairs. But that's easily explained by the fact that we have no pairs to build references to; hence, for (auto &[k, v] : map.asKeyValueRange()) doesn't compile (lvalue reference doesn't bind to prvalue pair). Instead, both of these compile: for (auto [k, v] : map.asKeyValueRange()) for (auto &&[k, v] : map.asKeyValueRange()) and in *both* cases one gets references to the keys/values in the map. If the map is non-const, the reference to the value is mutable. Last but not least, implement pinning for rvalue containers. [ChangeLog][QtCore][QMap] Added asKeyValueRange(). [ChangeLog][QtCore][QMultiMap] Added asKeyValueRange(). [ChangeLog][QtCore][QHash] Added asKeyValueRange(). [ChangeLog][QtCore][QMultiHash] Added asKeyValueRange(). Task-number: QTBUG-4615 Change-Id: Ic8506bff38b2f753494b21ab76f52e05c06ffc8b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2023-03-28 21:12:15 +0000