| Commit message (Collapse) | Author | Age | Files | Lines |
---|
||||||||||||||||||||||||| | Coverity complained that the Qt::strong_ordering(std::strong_ordering) ctor may leave m_order uninitialized, which is true if you assume that 'stdorder' could be anything else but {less, greater, equal}, which, however, should not happen™. Standardize on the pattern that QPartialOrdering(Qt::partial_ordering) was using: init m_order to equivalent, and then check for the other possible states. I would have preferred adding 'else Q_UNREACHABLE()', but these are constexpr functions, so we'd need the GCC 8 protection, and then the else would have a body longer than one line, and I don't know whether violating the coding style and adding {} only on the else would fly with reviewers, so that's done in a follow-up. Amends several changes (this code has seen a lot of churn over time). Pick-to: 6.9 6.8 Coverity-Id: 475148 Change-Id: I3d88cdaaffbdfb8720161470b5f89046a3a15088 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||||| | User binary has this export when Qt is build statically, we should only export it in shared Qt builds. Change-Id: Iaa08e2a668bee6f094a49f20a0033c5eecdc1cbc Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||||||| | As a drive-by, fix the copyright headers. Amends 03d5daf9437d8b46db2e89e3a9763ea701fa681c. Change-Id: Ie27ecb62097e9bcb33cc0ceb10c97743bce0b0e0 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||||||||||||| | These are hidden members, and visible under the QFlags class in the Clang AST - even though semantically they belong to the parent (global) scope. Adjust the \fn signatures accordingly and remove the \relates commands as unnecessary; QDoc recognizes the `friend` qualifier and marks the functions as related non-members of QFlags automatically. Pick-to: 6.9 6.8 6.5 Fixes: QTBUG-133923 Change-Id: Iaca74971bde8b313c573e75688bf57d3ff42b59d Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||| | Fixes: QTBUG-135866 Change-Id: Idfa884dad04ed83660ebadd9f23ecc46ef3b14ed Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> |
||||||||||||||||||||||||||||||||||||| | Large graphical Qt applications heavily rely on heap allocations. Jemalloc is a general-purpose malloc(3) implementation designed to reduce heap fragmentation and improve scalability. It also provides extensive tuning options. Add a -jemalloc configure option, disabled by default. When enabled, Qt and user code link to jemalloc, overriding the system's default malloc(). Add cooperation with jemalloc for some Qt key classes: QArrayData (used by QByteArray, QString and QList<T>), QBindingStoragePrivate, QDataBuffer (used by the Qt Quick renderer), QDistanceFieldData, QImageData, QObjectPrivate::TaggedSignalVector, QVarLengthArray. This cooperation relies on two jemalloc-specific optimizations: 1. Efficient allocation via fittedMalloc(): Determine the actual allocation size using nallocx(), then adjust the container’s capacity to match. This minimizes future reallocations. Note: we round allocSize to a multiple of sizeof(T) to ensure that we can later recompute the exact allocation size during deallocation. 2. Optimized deallocation via sizedFree(): Use sdallocx(), which is faster than free when the allocation size is known, as it avoids internal size lookups. Adapt the QVarLengthArray auto tests on capacity. Non-standard functions docs are at https://jemalloc.net/jemalloc.3.html [ChangeLog][QtCore] Added optional support for the jemalloc allocator, and optimized memory allocations and deallocations in core Qt classes to cooperate with it. Change-Id: I6166e64e66876dee22662d3f3ea3e42a6647cfeb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||||||| | Use the same algorithm as convertToDouble. We don't really need convertToDouble, as we plan to truncate anyhow (convertToDouble returns `false` if truncation caused loss of precision, so we can't use it to distinguish an out-of-bounds value), and these are debug-only checks. Change-Id: I70d70c05ce3f4996bd74361e6f78c02064232a57 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||||||||||||||||||||||| | The __has_cpp_attribute() refers to the attributes supported by the C++ language. GCC returns its knowledge of the C++ attribute in C, even when the C code doesn't support it. N2335[1] added the C++ attribute syntax to the C language and N2553[2] added the __has_c_attribute() query syntax. Known attributes: From https://en.cppreference.com/w/c/language/attributes#Standard_attributes: * [[deprecated]] (from N2334) * [[fallthrough]] (from N2408) * [[nodiscard]] (from N2267, with message in N2448) * [[maybe_unused]] (from N2662) * [[noreturn]] (from N2764, which also deprecates _Noreturn) Drive-by remove C++11 & 14 support from [[nodiscard]] [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2335.pdf [2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2553.pdf Pick-to: 6.9 Change-Id: Ifd32b2557683218e0d26fffd5b58dedf7911f77a Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> |
|||||||||||||||||||||||| | We don't need two independent Q_GLOBAL_STATIC variables: one for the default category and the other for the logging registry. We can simply save one in the other. However, we can do better than even that. QLoggingCategory currently doesn't hold any allocated resources: the const char *name points to a static string and the void *d is always null. That means the constructor and destructor only serve to register and unregister the category with QLoggingRegistry, so we transfer that responsibility to QLoggingRegistry itself (the un-registering is implicit in the registry's own destruction). The benefit of this is that the default QLoggingCategory can never be found in a destroyed state, however late user code may be running after ::exit() was called. We have had a number of these issues of De-Initialization Order Fiasco, especially since the changes to QThreadData destruction timing. Pick-to: 6.9 Change-Id: I2b6ea597ac257837669afffde2684c7b44a42e92 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> |
||||||| | Fixes: QTBUG-135225 Pick-to: 6.9 6.8 Change-Id: I64077ffaccc4f3b864c08df02b489857ac82f34b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> |
||||||||| | These functions have narrow contracts since they return integer types. Passing infinities or NaN is illegal, therefore they can't be noexcept. The qRound overloads for float/double in fact aren't noexcept. Change-Id: Id41c166bc296fd11fc10a31ceab640f55868570e Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> |
||||||||||||||||| | This function can be overridden by individual platform themes, in order to read contrast settings from the platform's system settings, and report the result back to Qt. This information is relevant for our styles, and can be used to determine color palette values, and additional elements like outline thickness for controls/widgets. Currently only the Windows, macOS, Gnome and Flatpak themes support this feature. Task-number: QTBUG-133595 Change-Id: I3aff519aa7f07c8b2fdcc1e7fb35ec719ab8efcc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> |
||||||| | The attribute must appear before the modifiers like 'inline' and 'constexpr'. Change-Id: If3d143fc2f85a8eba6e3ac2ceca10720649f33cb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||||||||||| | Otherwise including only the private header leads to QT_CONFIG being undefined. Amends 38bb72720aef4caf3de6c1c68ab46435d7c8d65c. Pick-to: 6.9 Change-Id: I0960d38c98d64348ebf1cec481417bdb21eed9a6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||||||||||||||||||||||||||||||||||||| | The namespace contains traits to check for presence and noexceptness of compareThreeWay() overloads. One of those overloads, the (raw) ptr one, is deprecated, and therefore throws a warning when one of these traits hits it. But this is beside the point, because it's not actionable by the user. Fix by wrapping the whole namespace in QT_WARNING_DISABLE_DEPRECATED. This fixes one of the two remaining -Wdeprecated warnings in tst_qcompare (which the test tries its best to defend against, by using QT_WARNING_DISABLE_DEPRECATED around the lines, too, but it didn't help in this case), namely this one: qcomparehelpers.h: In instantiation of ‘constexpr bool QtOrderingPrivate::CompareThreeWayTester::compareThreeWayNoexcept() [with LT = int*; RT = int*; typename std::enable_if<hasCompareThreeWay_v<LT, RT>, bool>::type <anonymous> = true]’: qcompare.h:689:91: required from ‘auto qCompareThreeWay(const LT&, const RT&) [with LT = int*; RT = int*; typename std::enable_if<disjunction_v<QtOrderingPrivate::CompareThreeWayTester::HasCompareThreeWay<LT, RT, void>, QtOrderingPrivate::CompareThreeWayTester::HasCompareThreeWay<RT, LT, void> >, bool>::type <anonymous> = true]’ tst_qcompare.cpp:847:5: required from here qcomparehelpers.h:1229:34: warning: ‘constexpr Qt::strong_ordering Qt::compareThreeWay(const LeftType*, const RightType*) [with LeftType = int; RightType = int; typename std::enable_if<disjunction_v<std::is_same<T, U>, std::is_base_of<Container, T>, std::is_base_of<U, T> >, bool>::type <anonymous> = true]’ is deprecated: Wrap the pointers into Qt::totally_ordered_wrapper and use the respective overload instead. [-Wdeprecated-declarations] 1229 | { return noexcept(compareThreeWay(std::declval<LT>(), std::declval<RT>())); } | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ qcomparehelpers.h:999:31: note: declared here 999 | constexpr Qt::strong_ordering compareThreeWay(const LeftType *lhs, const RightType *rhs) noexcept | ^~~~~~~~~~~~~~~ The last warning actually pertains to the body of qCompareThreeWay() calling Qt::compareThreeWay() on pointers. Even though we try to suppress that one, too, for testing purposes, it's not clear how it can be fixed without hiding it for all users of qCompareThreeWay(), so this is left for another day. Amends 3d231e27a8c38f8e840e161e76be3a153d6b0aa9. Pick-to: 6.9 6.8 Change-Id: Id434629435ea8ea89d03e46096866283ab792b54 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> |
||||||||| | Just so they're constant-initialized to zero and thus don't occupy disk space in QtCore. Change-Id: I2f876ef66b5f789c7642fffdfe073dbd65ea7a6d Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io> |
|||||||||||| | The use of function-local static implied there was a guard variable to perform a thread-safe initialization (a critical section). We don't need that: we can just use a plain QBasicAtomicInt and cooperatively initialize, in parallel. This way, the QMessageLogger code does not need to check the status of the guard variable before every access to the atomic, which would be an atomic access before the atomic access. Change-Id: Iedfbe8e28ca5168dea43fffddf205d122c97f71c Reviewed-by: Marc Mutz <marc.mutz@qt.io> |
||||||||||||||||||||||||||||| | Amends ceb859bf036dfdd1c54eec403006eac62a0d09b8 We'd accept negative values and keep counting downwards, reaching 0 again only after a full underflow[*]. Effectively, this meant that a negative value was the same as zero, so this makes the behavior explicit. The commit introducing checked_var_value() said in its changelog: For compatibility reasons with previous versions, if the variable is set to any non-empty and non-numeric value different from 0, Qt will understand as "stop on first warning". Negative values are not "non-empty and non-numeric", so this commit chooses to make the current behavior explicit. [*] atomic under- and overflows are defined behavior, but only if the atomic operation is the one producing it. The current code is doing the subtraction by itself in the call to testAndSetRelaxed(), so underflows are still UB. If/when this is replaced by atomicMutate, that might change (and note to self when implementing that!). Pick-to: 6.9 6.8 Change-Id: I594ed31f1cc7fc04ea98c6e86bdcaa3a4aa59114 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io> |
|||||||||||||||||||||||||||||||||||| | Amends commit b933a5668cc5647d26378f8a9a52901d0497585d ("Make sure we don't count down past 0 QT_FATAL_CRITICALS"), which introduced the CAS. Apparently it was a design decision then that only one thread would call qAbort(), while the others would happily continue. For example, for the common case of QT_FATAL_WARNINGS=1: // T1 T2 v = n.loadRelaxed() // v = 1 v != 0 // true n.testAndSet(v, v - 1, v) // n = 0 v = n.loadRelaxed() // v = 0 v != 0 // false return v == 1; // false This commit changes that design, for two reasons. First, a semantic one: if one thread has detected a fatal condition, it must be equally fatal for all threads. Second, we must accept a meaningful time between the detected condition and the call to qAbort() and thus the time until its effects take. In the worst case scenario, T1 could get suspended indefinitely, at which point T2 having concluded that warnings weren't fatal will happily execute forever. [This could happen *because* of having called abort(), and though that's a SW bug elsewhere, we should not let our other warnings and criticals continue.] The fix is simple: we never decrement from 1. That way, if multiple threads start their verification at the same time, they will all see the value 1 and will all abort. The abort() standard library function is thread-safe, as our replacements for it. Pick-to: 6.5 6.8 6.9 Change-Id: I03fbcbac26bd1f34d631fffd43bb9c27d51783d0 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> |
|||||||||||||||||||||||||||| | As decided with lazy consensus on the development ML¹, we'd like to separate precondition checking from internal consistency checking. Add a new Q_PRE/Q_PRE_X macro for the former, to leave Q_ASSERT/_X for the latter. As requested in review, modernize Q_PRE_X vis-a-vis Q_ASSERT_X by skipping the `where` parameter (defaulting it to Q_FUNC_INFO). Added as undocumented API, for now, to pick back to all active branches without actually promising semantics different from Q_ASSERT, a change that, realistically, will only happen for 6.10 at the earliest. But by making the macro available to all active branches, we avoid conflicts when picking changes back, and the change is rather risk-less. Apply to QStringView, to have at least one user. ¹ https://lists.qt-project.org/pipermail/development/2024-August/045588.html Items 1-3. Pick-to: 6.9 6.8 6.5 Task-number: QTBUG-98965 Change-Id: Ia04248a64c8feba80cce10f8f5cbde580436db88 Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> |
||||||| | Fixes: QTBUG-134538 Pick-to: 6.5 6.8 6.9 Change-Id: Iab51337b9b27ccf48a0e60c08cf14706112b6235 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||||||||| | clang-cl does not warn about return after unreachable, but would warn about the unused variable after return. Pick-to: 6.8 6.9 Change-Id: Ia0fcff4f536d51d56eb915a9130cc3f72437d8d1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||||||| | The thread name is often more meaningful than a number or pointer. [ChangeLog][QtCore][Logging framework] QMessagePattern / QT_MESSAGE_PATTERN now support the %{threadname} placeholder. Change-Id: I7ad8821c8b887e428023144d6e93e20c53bf757e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||||||||||||||||||||| | QGlobalStatic has a warning suppression for -Wtsan because of its usage of std::atomic_thread_fence, which TSAN doesn't support. That header is included in QtCore's PCH, and that triggers a GCC bug that causes the warning to be emitted despite the suppression [1]. In a developer build, the warning turns fatal. We could either disable PCHs in such a build configuration (TSAN+developer-build+GCC < 15), or: simply make the warning non-fatal on earlier compiler versions. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117 Pick-to: 6.9 6.8 6.5 Fixes: QTBUG-134415 Change-Id: If80a4acdb1372d00804a60361f6c3d6893b96106 Reviewed-by: David Faure <david.faure@kdab.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> |
||||||||||||||||||| | On CYGWIN, the build process fails at this point: In file included from qtbase/src/corelib/global/qsysinfo.cpp:40: qtbase/src/corelib/global/qoperatingsystemversion_win_p.h:19:10: fatal error: qt_windows.h: No such file or directory 19 | #include <qt_windows.h> | ^~~~~~~~~~~~~~ compilation terminated. Besides the fact that qt_windows.h doesn't exist into the build directory when compiling a POSIX-like platform, when compiling under CYGWIN, the operating system is CYGWIN, not Windows. So, it is better to collect those information by using Q_OS_UNIX tools instead. Change-Id: I496eedb58c4a3d1ce2da9fb3526a6ec5ed67f638 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||||||||||||||||||| | qRound, qCeil, qFloor convert the input floating point number to an int, using various rounding strategies. They all have UB if the input fp number is out of range for the target representation. This is actually documented (at least for qRound, see a47a5932a64a8867077cab7c8efa57587b637481), and just the reality of the current implementation for all of them. This commit therefore adds an additional check, which asserts if result of std::trunc (applied to the FP number after rounding) overflows. std::trunc has the very same semantics of FP->integral conversions in the language (round towards zero / discard the fractional part). Since qRound is constexpr, make the wrapper constexpr-friendly as well, which requires C++23 or a suitable compiler (GCC has had constexpr cmath since GCC 5 or so.) Change-Id: I17740381c2af98ebdda4c240035e53aea26116b0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||||||||||||||||||||||||||||||||||| | The floating-point based geometry classes promise rounding in their documentation, in at least two places. 1) when fp math is applied to an integer-based class, the result is the same integer class. For instance, QPoint(1, 2) * 3.14 yields a QPoint (!). The documentation says that the result is rounded to the closest integer. 2) when a fp-based class is converted to the corresponding integer-based one (e.g. QRectF::toRect()). These functions have the same notice. Insofar qRound has been used in the implementation of these functions. There's a problem: qRound does not actually honor the "round to closest integer" contract. Specifically, if the input floating point is out of range for the destination type, then the behavior is undefined (cf. a47a5932a64a8867077cab7c8efa57587b637481). Since we have reports of cases where out-of-range values are indeed passed through these functions, I'm extremely wary of changing the behavior to be UB. Instead, I'm making these functions actually do what the documentation says they do. To this end, refactor the various qRound overloads and split the rounding part from the casting to the destination type. The rounding is kept as private API, using the existing arch-specific implementations. The casting is generic and it's in the public qRound overloads. Then, add a private qSaturateRound which re-uses the casting, clamps to range ("saturating" -- which is still casting to the closest integer value), and casts to the final type (only int, at the moment). This new API is then used in the geometry classes when they round. Fixes: QTBUG-133261 Change-Id: Iba0d9baa17c136a976a945742c117e4cfac520b3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||||||||||||||||||||||||||||||| | We have divergence in the way we document function, operator and constructor constraints. About half use \note, while the other doesn't. Some say "if and only if" while others say just "participates only if". So add a qdoc macro, \constraints, to semantically mark up these constraints. It expands to a section titled `Constraints`, and uses a predefined sentence (prefix) for constraints. Documentation for constraints is moved to the end of the comment blocks to separate them from the rest of the text. Apply them to all the standard-ish constraint documentation blocks (grepped for "participate"). I didn't look for other, one-off, ways documentation authors may have documented constraints, but I'm also not aware of any. Re-wrap lines only if the result fits into a single line. As a drive-by, drop additional "if"s, as in "only if X and -if- Y" to make the texts work with the `Constraints` section. Fixes: QTBUG-106871 Pick-to: 6.9 6.8 6.5 Change-Id: I18c2f9f734474017264e49165389f8c9c7f34030 Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> |
|||||||| | This applies to qaxserverdll only, where "the executable" is actually a DLL. Change-Id: I8ac1bc015b9e6f381de8fffd1f8ee185d923f1f4 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> |
|||||||||| | Clang 20 has fixed the referenced issue. Once more this shows the importance of versioning compiler-related checks... Amends 1b1ae345025d1cac953985d4cfebd20fadb6bc99. Pick-to: 6.9 Change-Id: Iea88d466883562b0130639d7c0f2f3b984acdbc2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||||||||||||||| | This is a thread-safe version of QCoreApplication::instance() != nullptr for Qt 6.x, because QCoreApplication::self is not atomic and thus reading it from outside the main thread could be a data race. That's not to say it always is: if by construction the code can only run in the main thread or while QCoreApplication definitely exists, that's safe. Therefore, this commit focuses on places that are meant to be used in multi-threaded environment (ruling out most of QtGui and QtWidgets) or where the code was going to dereference the returned pointer anyway. Change-Id: I6fc556c5fe5cbe0b5902fffdfb6b3bb345b0ee50 Reviewed-by: Marc Mutz <marc.mutz@qt.io> |
||||||||| | Making it qt_maybe_message_fatal(). Thus we're less likely to forget to do the right thing. Change-Id: Ie3c344d9f64527fc755ffffdd3c97cf8fa3fcc90 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Marc Mutz <marc.mutz@qt.io> |
|||||||||||||||||||||||||| | Windows has shipped a (limited) subset of ICU for quite a while: https://learn.microsoft.com/en-us/windows/win32/intl/international-components-for-unicode--icu- The C API for this subset uses non-standard names for headers and lib though, and is therefore not picked up by the ICU configure logic in CMake. This patch adds a separate configure test that enables the use of this ICU API, specifically for text codec support in QStringConverter. If a 'proper' ICU is enabled by the user, this still takes precedence. Also, note that MinGW-w64 misses the respective Windows API, and will therefore still use the old fallback. [ChangeLog][QtCore][Text] Qt on Windows now uses the ICU API of the Windows SDK for text codec support (if available and no 'full' ICU is configured). This greatly enhances the list of supported text codecs available. Fixes: QTBUG-132056 Change-Id: Id02ae9f8cf56dee8c34795c0e60d2113f319bfd9 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||||||||||||||||| | This commit removes all uses of getenv_s() (but not _wgetenv_s in qEnvironmentVariable()), which is what was imposing the length limit with qEnvironmentVariableIntValue(). We don't need to use getenv_s() -- it's not more secure than getenv(). Microsoft could have made them thread-safe, but the documentation for them[1] indicates they are not. [ChangeLog][QtCore][QtEnvironment] qEnvironmentVariableIntValue() is no longer limited in the length of the number. [1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/getenv-s-wgetenv-s Change-Id: I95d97966c6da43b59a17fffdab2f904d78a62e9a Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> |
|||||||| | [ChangeLog][QtCore][Editorial] Update previous statement on qEnvironmentVariableIntegerValue to indicate it returns 64-bit. Change-Id: I93fc5ca3455b2435bf95fffded69e086e038d14d Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> |
|||||| | Pick-to: 6.9 6.8 6.5 Change-Id: I5e463b81f7e73b2946a0e3b3036a09de2105307b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||||||||||| | Both enable_if and is_null_pointer belong to type_traits, include it. Amends 631a0cc45cbe70940746cd944d325d7d3bab8c15. Pick-to: 6.9 6.8 Fixes: QTBUG-133808 Change-Id: I9626ba80b2d9799d1bfed8ca9c9090691b8d8715 Reviewed-by: Marc Mutz <marc.mutz@qt.io> |
||||||||| | Adds a "media key" for the "Keyboard settings" key found on some laptops. Change-Id: Id041a551844f095f1d7d2fd25d37346da30407a3 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: David Edmundson <davidedmundson@kde.org> |
||||||||||||||| | We don't need most of the extra checks that either QByteArrayView::toInt() or QtPrivate::toSignedInteger() perform. Plus, QtPrivate::ParsedNumber won't fit a two-register return ABI, while QSimpleParsedNumber will. We do need to reintroduce the int check. Task-number: QTBUG-133654 Change-Id: I693c3e0eb072dab27000fffdd1279750dc83258c Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io> |
|||||||||||| | That way, we won't need to pass a bool pointer to distinguish an environment variable containing zero from one that failed to parse. [ChangeLog][QtCore][QtEnvironment] Added qEnvironmentVariableIntegerValue(), which returns std::optional<int>. Fixes: QTBUG-133654 Change-Id: If0d6c3a6f7a080588fa5fffd87b9365f0f8e1089 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> |
|||||||||||||||||||| | This meant a string containing the octal form of INT_MIN (-020000000000) would be just too long and getenv_s() would fail. This was never caught because code that was meant to test different bases simply forgot to use the base. Amends commit bb56586e32677ee9be23bffa4f3cc9a913ef192f. I've renamed the rows to be the text being parsed, so it matches the previous rows and it makes clear what was being parsed just by reading the test's output. That also revealed a duplicate row to be removed. [ChangeLog][QtCore][QtEnvironment] Fixed a bug that caused qEnvironmentVariableIntValue() to fail to parse octal values from -020000000000 to -010000000000 with MSVC. Other compilers were not affected. Pick-to: 6.9 6.8 6.5 Change-Id: I9095d86cccd9e8001e85fffd6fbbcd6a9a1678c3 Reviewed-by: Marc Mutz <marc.mutz@qt.io> |
||||||||||| | This is what QDir::isRelativePath() does, for better or worse. We've used QDir::isRelativePath() before and we shouldn't change the behavior. Amends commit c74cba1117355a6312b1f0cc815efa4cdea4bbfa Pick-to: 6.9 6.8 Change-Id: I03e3e921977af2b9c6ff2593535d846d6ce28fe2 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> |
|||||||||| | That becomes an error. So only allow them in GCC-compatible compilers. Fixes: QTBUG-133376 Pick-to: 6.9 Change-Id: Idd04be795dd9fd2b43affffd08cd7b8a444bbc43 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> |
|||||||||||||| | This is hot code, run early in the application's life, usually as a result of the first qDebug() because QLoggingRegistry wants to find qtlogging.ini. So let's not use QFileInfo, which allocates memory, just to do string manipulation. These are always filesystem paths. See commit d59e640c868f3db2d661970f3d34a22013d49053 for a similar change in findConfiguration(). Pick-to: 6.9 6.8 Change-Id: I012daf4a3aa2ebc2c5abfffd2ef7ceac1df2626d Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> |
|||||||||||||||||||||||||||||||| | This is a private and minimal "safe int" API for internal uses. It has configurable policies for * how to carry out a given arithmetic operation (check for overflow, just do the native language operation, ...); * how to report an error in case the operation fails (Q_ASSERT, ignore it, ...). By default, operations are implemented via the q*Overflow family of functions, and Q_ASSERT is used to report errors. This means an arithmetic error will be fatal in debug mode, and implement wraparound in release mode. However, UB will be prevented; the compiler will generate the same assembly, but it won't be allowed to exploit overflows as an UB source (that's because q*Overflow has well-defined behavior). In C++26 jargon, the program will have EB at this point. The class is also supposed to be binary compatibile with the type it wraps, so that it can be used to replace an `int` data member, without breaking ABI. (Of course the mangling will be different, but this is an implementation detail and it's not supposed to be exposed.) It's woefully incomplete (operator% is missing, for instance); I just needed a MVP to support the upcoming changes to the geomery classes. This is meant to stay completely private, users that need a real implementation should use Howard Hinnart's bbi. Change-Id: I69ea20e872e395a505c5748f24105469dfb60d84 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||| | Pick-to: 6.8 6.9 Change-Id: I967304c24e1a593b1b555998a718d0a015e12900 Reviewed-by: Jerome Pasion <jerome.pasion@qt.io> |
||||||||||||| | Amends commit 868645fd3be039e37c96315059ab0b851d022bf4 Code like (qtmultmedia): Q_ASSERT_X(QFile::exists(shaderFile), Q_FUNC_INFO, QStringLiteral("Shader file %1 does not exist").arg(shaderFile).toLatin1()); Change-Id: Iab02812335384115a689fffd871cd478c7c20046 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Marc Mutz <marc.mutz@qt.io> |
||||||| | Change-Id: I1f2acc02939171464e05671afcaf3df7ca2b3b8a Pick-to: 6.9 6.8 6.5 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
|||||||||||||||||||||| | This is from one of the 90s books on C++ Coding Style: Destructors of (public) base classes should be either public and virtual or else protected and non-virtual. The dtors of the various QFlags helper classes were public and non-virtual, allowing slicing and use outside of QFlags. Fix both following the rule and making the dtors protected. Previously, this would have been enough, but Clang started to warn about undeclared copy- and move-SMFs in the presence of a user-declared dtor, so need to declare all five. Found in API-review. Pick-to: 6.9 Change-Id: I70d1163f7bb42d981bf550418d2775a784bd416e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> |
|||||||||||||||||||||||||||||||||| | ... and add more specific #errors. There are two distinct error cases here: - First, someone could add more Q_STL_ macros to qstdlibdetection.h, so like a switch with -Wswitch, list them all here and #error out if there's a Q_STL_ we haven't yet seen. The audience here is Qt developers, via the CI. - Second, one of the "non-major" libraries (ie. not libc++, libstdc++ or MS-STL) add support for C++20, specifically the std::ordering types as announced by __cpp_lib_three_way_comparison, in which case we need to retroactively add the correct unordered value here. The audience here is both Qt developers, via CI, but also Qt users. So separate the two error conditions. Also, for platforms where we don't know the numeric value of std::partial_ordering::unordered, use Qt's legacy value, for potentially faster conversions to/from QPartialOrdering. There's no point in guessing which value _might_ be used by a future STL, and swapping STLs is _always_ BiC, so we don't need to guess which STL will follow the Dinkumware ones on QNX and VxWorks. Amends 0231f33ad121a85368bb3f43273973b9632735dc. Pick-to: 6.9 Change-Id: I1d06a18ca5bb26aceb7c76a0f035ecd8d4673547 Reviewed-by: Michał Łoś <michal.los@siili.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> |