summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib
Commit message (Collapse)AuthorAgeFilesLines
* Guard the use of QWinEventNotifier in testsAlexey Edelev2022-05-171-0/+2
| | | | | | | | | Add the Q_OS_WIN32 guard for the include of QWinEventNotifier. Change-Id: I7824b2ee236a370c83fd85a2f594a39cf36b36e6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Return specific types for frequently used Java objectsVolker Hilsheimer2022-05-171-0/+9
| | | | | | | | | | | | | | | | | | This allows us to specialize JNI type signature templates for e.g. the context object, which in Java signatures is "android/content/Context". Introduce a Q_DECLARE_JNI_TYPE macro that takes care of the plumbing. The types declared this way live in the QtJniTypes namespace, and transparently convert from and to jobject. Since jobject is a typedef to _jobject* we cannot create a subclass. Use a "Object" superclass that we can provide a QJniObject constructor for so that we don't require the QJniObject declaration to be able to use the macro. The APIs in the QNativeInterface namespace doesn't provide source or binary compatibility guarantees, so we can change the return types. Change-Id: I4cf9fa734ec9a5550b6fddeb14ef0ffd72663f29 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Fold methods for object return type into generic methodsVolker Hilsheimer2022-05-171-0/+31
| | | | | | | | | | | | | Since we know at compile time whether the return type is an object type, we can use 'if constexpr' and auto return type in the call(Static)Method and get(Static)Field functions to call the object-type methods. This makes the object-methods conceptually obsolete, but don't declare them as deprecated as long as they are still used in submodules to avoid warning floods and build failures in -Werror configurations. Change-Id: Ic3019ed990a9252eefcb02cdb355f8a6ed6bc2ff Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-16315-8677/+692
| | | | | | | | | | | | | 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 variadic template overloads for QJniObject/Environment methodsVolker Hilsheimer2022-05-132-17/+150
| | | | | | | | | | | | | | | | | | | | | | | | | This allows the compiler to deduce the template arguments based on the provided method parameters, which we can then pass to the methodSignature and fieldSignature helpers to generate the signature string completely at compile time. Since we can't partially specialize template member functions, replace the specializations for void methods with compile-time-if branches in the general templates. This variadic template now prevents implicit conversion from the LiteralStorage types to const char* signatures, so catch the case where such a type ends up in the parameter list. Due to overload resolution rules for constructors, we need to explicitly disable the constructor if any of the arguments is a string literal type, as we have to keep the old C-style variadic function working for such calls. Add variations that use the variadic templates to the unit tests. Change-Id: I8734664b38bae932369462330a9a03302254c33c Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* QMetaType: Fix normalization on MSVC if name contains enumFabian Kosmale2022-05-121-0/+6
| | | | | | | | | | | | | | | During type normalization, we remove the struct, class and enum keywords (see the skipStructClassOrEnum function). However, we only want to do that for actual keywords, not for a name that happens to start with e.g. "enum", as in "enumerationNameSpacce". Adjust the MSVC check to still require no identifier character after the keyword, while still allowing for some remaining characters. Fixes: QTBUG-97813 Pick-to: 6.3 6.2 Change-Id: I82b873d02ff454cce4b75f2814a52a66f2268208 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove remnants of the old Intel C++ compilerThiago Macieira2022-05-113-9/+3
| | | | | | | | | | | | | We don't support it any more. I don't think it has ever properly compiled Qt 6 (and it's no longer working for me against GCC 12's libstdc++ headers). If you report a bug against it, Intel support's first question is if you can try instead the new Clang/LLVM-based oneAPI C++ compiler. So we support only that one, which identifies itself as Q_CC_CLANG. Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb57a092c8439e Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Update shared-mime-info to the 2.2 releaseLiang Qi2022-05-111-5/+5
| | | | | | | | | This also includes the fix for x-objc++src mimetype. Fixes: QTBUG-70739 Pick-to: 6.3 6.2 5.15 Change-Id: I24f70fa5cea2e5b1a7877569be98d36878fcfe72 Reviewed-by: David Faure <david.faure@kdab.com>
* Endian: Provide special integer bitfield unionsUlf Hermann2022-05-071-1/+105
| | | | | | | | | | | | | | | | | Our previous approach of creating a union from individual special integer bitfields leads to undefined values because only one member of a union can be active at any given time. Compilers have finally caught up with us on that and have started removing "no-op" writes to members. The primary user of the special integer bitfield unions is qv4compileddata_p.h in qtdeclarative. We want our on-disk format of QML compilation units to be platform agnostic and space efficient. Pick-to: 5.15 6.2 6.3 Task-number: QTBUG-99545 Change-Id: I24847bda2c364eb8ba75f074cde2a9bec25ced06 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Generate JNI signature strings at compile timeVolker Hilsheimer2022-05-053-0/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce an internal QtJniTypes namespace with types that allow us to concatenate string literals at compile time. This makes it possible to generate arbitrary strings based on types, which we can then use as signatures to JNI method calls. Move some of the private members of QJniObject into the QtJniTypes namespace for consistency, and to allow further template specialization by user code to make other types and their JNI signature string known. Remove the "Jni" prefix from names. Use the compile-time generated string in QJniObject methods that created the signature string at runtime, which involved a temporary memory allocation. Treat 'void' as a primitive type (with signature string 'V'), and remove redundant template specializations. Add a test case to verify the the strings are constructed correctly at compile time. Change-Id: I5e3895a97f7dc1b86961f7a7855b899d9203037d Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QTextStream: complete char16_t supportMarc Mutz2022-05-041-0/+9
| | | | | | | | | | ... by providing also op>> for char16_t. [ChangeLog][QtCore][QTextStream] Added op>>(char16_t&). Change-Id: I2f6cc2b2cdacd5190d364f94c1830f6de62d3b7e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QTextStream: fix streaming of char16_t'sMarc Mutz2022-05-031-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Clazy complains about all uses of QLatin1Char these days, but if one actually applies the fixit to turn out << QLatin1Char(' '); into out << u' '; the space is now streamed as an int (20), not as a space. Fix by providing an explicit char16_t overload. [ChangeLog][QtCore][QTextStream] Added op<<(char16_t). [ChangeLog][Important Behavior Changes] QTextStream streams char16_t's as QChars now instead of outputting the numeric value. If you want to preserve the old behavior, cast the char16_t to a numeric type, such as ushort or int, and stream that. This is backwards-compatible. Pick-to: 6.3 Change-Id: I42d422cdebb27d38ac1714b22ef186642ec407e7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Deprecate _qs and _qba literal operators in favor of _s and _baSona Kurazyan2022-05-022-2/+6
| | | | | | | | | | [ChangeLog][QtCore] Deprecated _qs and _qba literal operators for QString and QByteArray in favor of _s and _ba in the Qt::Literals::StringLiterals namespace. Task-number: QTBUG-101408 Change-Id: I26aee0055e3b4c1860de6eda8e0eb857c5b3e11a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace remaining uses of deprecated _qs with _sSona Kurazyan2022-05-022-5/+7
| | | | | | Task-number: QTBUG-101408 Change-Id: I1fda67c07e948af5017f0b99b67f8c20d7052033 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Implement support for '0b' prefix in toInt() etcMarc Mutz2022-04-281-4/+1
| | | | | | | | | | | | | | | | | | | | [ChangeLog][QtCore][QByteArray/QByteArrayView/QLatin1String/QString/QStringView] The string-to-integer conversion functions (toInt() etc) now support the 0b prefix for binary literals. That means that base = 0 will recognize 0b to mean base = 2 and an explicit base = 2 argument will make toInt() (etc) skip an optional 0b. [ChangeLog][QtCore][Important Behavior Changes] Due to the newly-introduced support for 0b (binary) prefixes in integer parsing, some strings that were previously rejected as invalid now parse as valid. E.g., Qt 6.3 with autodetected bases would have tried to parse "0b1" as an octal value and fail, whereas 6.4 will parse it as the binary literal and return 1. Fixes: QTBUG-85002 Change-Id: Id4eff72d63619080e5afece4d059b6ffd52f28c8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix qlocale_unix's handling of uiLanguages to take script into accountEdward Welbourne2022-04-271-0/+6
| | | | | | | | | | | | | | | Some languages have, in the same territory, locales for more than one script. In such cases, since we ignored the script, we got the one that is used by default, instead of the one actually asked for. Take the script into account. Added TODO comment in test listing the known examples of this; manually tested before and after the fix to verify the prior code was indeed getting it wrong and now does do it right. Change-Id: Iaf9201d6992bc39e6e9346ef8b7c69d418db7253 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Return more specific entries before less in QLocale::uiLanguages()Edward Welbourne2022-04-271-12/+12
| | | | | | | | | | | | | | | | | | The documentation overtly listed entries in this order but the code gave less specific entries before more specific (and the tests verified the same). This is now reversed. [ChangeLog][QtCore][QLocale] uiLanguages() now prefers more specific locale names over less specific ones, matching its own documentation, except where the system backend supplies them in some other order. This means a translation with the expected script and/or territory as well as language will be used in preference to a generic one for just the language, rather than only as a fall-back when the more generic one is missing. Fixes: QTBUG-102796 Change-Id: I3c7b3627afb51246df5a6ad0230e23b60af78071 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Don't declare type 'id' in the global namespace in a public headerTor Arne Vestbø2022-04-272-0/+77
| | | | | | | | | | | It's not necessary, and it breaks the qttools build (where we have a global variable named 'id'), and thus will most certainly build a lot of existing user code. Amends e47c22480fe84c100019cd92d0296f0dd2a7f3f1. Change-Id: I97a91c2cb23fdae65143cf14c81570cf88d529d5 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Clear tst_QSettings of deprecation warningsEdward Welbourne2022-04-262-7/+5
| | | | | | | | | | | Assorted QMetaType and QVariant methods deprecated in Qt 6 were still in use - the deprecation warnings were suppressed by setting QT_DISABLE_DEPRECATED_BEFORE=0 - fix them and clear that suppression. Change-Id: I1aa8f45dcb5a18449b060b346c80ad70536896ab 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>
* tst_QSettings::testVariantTypes(): modernize list initializationsEdward Welbourne2022-04-261-10/+6
| | | | | Change-Id: Ia84cd7590f9bcc95a790efb1e1dab46ab368cd2d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Convert tst_QSettings::testVariantTypes()'s macro body into a lambdaEdward Welbourne2022-04-261-13/+18
| | | | | | | | | Retain the macro, so as to automate checking QTest::currentTestFailed() after return from the lambda. Change-Id: If5873a533224ea3b809cef02255642a7d071d642 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Clean up tst_QSettings::testVariantTypes()Edward Welbourne2022-04-261-27/+26
| | | | | | | | | | | | | | | | | | | | | Give the macro and its parameters clearer names, wrap the macro body in do {...} while (0), use QCOMPARE() rather than QVERIFY()ing comparisons, convert the result type to QMetaType::Type rather than QVariant's deprecated equivalent, save one macro parameter by using decltype() on another. Simplify one check by pulling out a common sub-expression as a local variable. In the process, give the settings keys meaningful names rather than just "key" with a numeric suffix. Ideally this test would be reworked to be data-driven, instead of using macros, but the use of qvariant_cast<> to convert a read-back value, along with the variable type of the input value compared to the result of that cast, precludes this (as far as I can see). Change-Id: I4e083cd0dea14d723910873829352e15740006bd Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Rearrange tst_QSettings::testVariantTypes()Edward Welbourne2022-04-261-24/+24
| | | | | | | | | | | | Move the large block unrelated to the macro-driven parts to before the macro is defined. This makes it clearer that it has nothing to do with the macro-driven part of the test. This is, in any case, a more basic test of behavior, so may as well go first. Rename the tested key in the process. Change-Id: I783fcd812e36320e9bb9765bab3ec09b56d6e6e6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Remove two unused resource files from tst_qsettingsEdward Welbourne2022-04-264-8/+0
| | | | | | Change-Id: Ia54fa1ffa6e739496667d1486ee7e5658cd6a74f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Inline a shared data-driven test table in tst_QSettingsEdward Welbourne2022-04-261-88/+23
| | | | | | | | | | | Move its static populateWithFormats to before the class is declared and make the _data() methods that call it (including one that did so via another) inline so that we can see which are this simple - and thus which aren't. Change-Id: I71863244ba0e4bd188424b6a3f8d86d5d9f635a9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Clean up includes involving tst_qmetatype_common.hEdward Welbourne2022-04-263-13/+8
| | | | | | | | | | | The functions it defines depend on many many types in QtCore for which it did not have a #include; both files that included it thus had to pull in QtCore to compile. Put that #include where it belongs and clean out many specific QtCore includes that it makes redundant. Change-Id: Ie9d9ec325d4879d771cb14baecb06fecbdaf62c5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Add support for unwrapping QFuture<QFuture<T>>Sona Kurazyan2022-04-211-0/+267
| | | | | | | | | | | | | | | | 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>
* tst_qstringapisymmetry: check toInt() etc also with base != 0Marc Mutz2022-04-171-0/+119
| | | | | | | | | | | This shows we're lacking support for the 0b prefix, and, as it turns out, there's a request for it. Task-number: QTBUG-85002 Pick-to: 6.3 Change-Id: Ie201c84bf906a7e482b929301699ceb429b53c14 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QDate(Time): add a addDuration methodGiuseppe D'Angelo2022-04-142-14/+27
| | | | | | | | | | | | | | | | To complement the existing addSecs / MSecs / etc., add a function that takes any compatible std::chrono::duration. QTime also features similar functions, but it's also "unique" in that it uses modular arithmetic (it wraps around in case of "overflow"). I'm not so sure that adding durations to a QTime object therefore makes sense, and I'm not doing it in this patch. [ChangeLog][QtCore][QDate] Added addDuration(). [ChangeLog][QtCore][QDateTime] Added addDuration(). Change-Id: I02aa37ff024d7f56fa976dc8f4f73523bdba8d94 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDateTime: add conversions for time_point and zoned_timeGiuseppe D'Angelo2022-04-131-0/+227
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In C++20, QDateTime is a direct equivalent of a sys_time<milliseconds> time point. (Before, it might not have been, because system_clock before C++20 was not guaranteed to be tracking Unix time, AKA UTC time without leap seconds.) To be specific, sys_time<milliseconds> corresponds to a QDateTime using the Qt::UTC timespec. This patch: 1) adds named constructors taking time_points: * a generic one taking any time_point convertible (via clock_cast) to a system_clock (this obviously includes system_clock, but also e.g. utc_clock) * another couple taking local_time, interpreted as a duration from 1/1/1970 in local time. 2) adds a named constructor from zoned_time (i.e. a sys_time + a timezone), that we can easily support via QTimeZone. 3) add conversion functions towards sys_time, matching the existing to(M)SecsSinceEpoch() functions. [ChangeLog][QtCore][QDateTime] QDateTime can now be constructed from std::chrono::time_point objects (including local_time), as well as from std::chrono::zoned_time objects. Moreover, they can be converted to std::chrono::time_point using system_clock as their clock. Change-Id: Ic6409bde43bc3e745d9df6257e0a77157472352d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDate: add conversions for std::chrono calendaring classesGiuseppe D'Angelo2022-04-131-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QAbstractProxyModel: do not access invalid indexesGiuseppe D'Angelo2022-04-131-0/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QAbstractProxyModel::headerData tries to do the "smart" thing and map sections in the proxy to sections in the source. However there's no "mapSectionToSource" virtual. Instead, to map horizontal headers, the code builds a proxy index at row 0 and section N, maps it to the source, and finds out which source column it gets mapped to. (Same story for the vertical headers). ... in general this can obviously fail, say you've got a "horizontal scrambling" proxy model, but in the common case this is OK. Except, if the proxy is empty (e.g. 0 rows or columns). In this case, it asks for an illegal index, and if you reimplemented index() yourself (which you must, since it's a pure virtual in QAPM) and you do bounds checking, you'll not be pleased at the result. This turns out to be a massive API liability. To fix this somehow properly, we can decide that empty models don't get the section remapped (easy). Less easy is the fact that, when the model does get some data, we have to emit headerDataChanged() otherwise the views will get broken. So add this logic too. Note that QAPM does not normally forward any source model's signal -- a subclass has to connect to them and handle them explicitly. That's *another* API liability, all over the place -- data(), headerData(), flags(), etc. What I mean by this is that one can create a valid QAPM (by implementing its pure virtuals) that however is immediately broken by the convenience that QAPM provides for the rest (data(), headerData(), etc.). This commit doesn't try and change this in any way, but I'm less and less convinced of the usefulness of QAPM in its current shape. Change-Id: I45a8c2139f2c1917ffbf429910fdb92f005f4feb Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: David Faure <david.faure@kdab.com>
* QVarLengthArray: add missing (size, value) ctorMarc Mutz2022-04-131-0/+12
| | | | | | | | | | | Extend the corresponding test in tst_containerapisymmetry. [ChangeLog][QtCore][QVarLengthArray] Added (size, value) constructor. Fixes: QTBUG-102469 Change-Id: I4802eebe6ba1a6835e4d6f41e1d3db2a0d7c7894 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDateTime: add support for std::chrono::duration arithmeticGiuseppe D'Angelo2022-04-131-1/+20
| | | | | | | | | | | | | | | | | | | QDateTime represents a specific point in time, so arithmetic with durations makes perfect sense. Moreover, we can finally equip QDateTime with a subtraction operator, to calculate the duration between two QDateTime objects. [ChangeLog][QtCore][QDateTime] QDateTime now supports arithmetic between QDateTime objects and std::chrono::duration objects. A duration can be added to or subtracted from a QDateTime, yielding another QDateTime; and two QDateTime objects can be subtracted from each other, yielding the duration between them. Change-Id: I656419f3bb9418c49f0e2fd0800c3dbaaf6aff32 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QTimeZone: add construction from std::chrono::time_zone*Giuseppe D'Angelo2022-04-121-0/+48
| | | | | | | | | | | A time_zone represents a timezone identified by its IANA ID. This allows for a straightforward conversion to QTimeZone. [ChangeLog][QtCore][QTimeZone] QTimeZone can now be constructed from a std::chrono::time_zone pointer. Change-Id: I093d9fc2e989475d30730a9dcdef491903a2aeb2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Skip test that fails with Address Sanitizer enabledDimitrios Apostolou2022-04-121-0/+7
| | | | | | | | | | | | | | These particular testcases request huge buffers from malloc() .This is intentional and the test expects malloc() to return NULL. Address sanitizer catches this and considers it a problem. Could also be skipped in runtime by setting the environment variable: ASAN_OPTIONS=allocator_may_return_null=1 Task-number: QTBUG-89400 Change-Id: Id3a9b586be9c0bad4a007e1731f2bc1a879cc76e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Ensure that readAllStandardError() doesn't crash on assertJarek Kobus2022-04-091-0/+10
| | | | | | | | | | | Ensure that it's safe to call readAllStandardError() when process channel mode is set to MergedChannels. Pick-to: 6.3 6.3.0 Task-number: QTBUG-102177 Task-number: QTCREATORBUG-27196 Change-Id: I01073255d9347dee4654d602802a12d341372b73 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Android: use BCP 47 tag to create a correct Locale for QTimeZone::displayName()Ivan Solovev2022-04-081-0/+52
| | | | | | | | | | | | | | | | | | Before the patch we tried to create a java Locale object by passing the human-readable language, territory and variant strings. However, the Locale constructor accepts ISO-defined codes. Fix it by using a factory method Locale.forLanguageTag() [0] that constructs a Java Locale object based on BCP 47 tag. [0]: https://developer.android.com/reference/java/util/Locale#forLanguageTag(java.lang.String) Fixes: QTBUG-101460 Pick-to: 6.3 6.2 5.15 Change-Id: If414c66cf0e5b7e8299ffc3a6038b6f9eb79d5ec Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Fix assertion failure when parsing a doubly-invalid date-time textEdward Welbourne2022-04-071-1/+14
| | | | | | | | | | | | | | | | | | | | | | | When the date-time string falls in a spring-forward (so is invalid) and one of the fields of the parsed string doesn't match the format it's meant to (e.g. a single-digit seconds field when format ss was specified), a check that the current fall-back date-time is between the minimum and maximum for the parser object failed, triggering an assertion. In any case, an invalid default-value wasn't useful to the code that parsed a single section of the date-time string, so brute-force the current value to a valid date-time (when possible) using the usual round-trip via milliseconds since the epoch. Added the test-case which first revealed the problem, plus a couple more informed by it, to exercise the same code-paths with fewer things failing. Fixes: QTBUG-102199 Pick-to: 6.3 6.2 5.15 Change-Id: I658308614505ef25f4c97d0de6148acb54a65a0f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Don't use QSKIP() when merely eliding part of a testEdward Welbourne2022-04-071-25/+23
| | | | | | | | | | | | | | | | | Use of QSKIP() means the whole test is skipped; when all applicable parts of a test have passed and some part of the test is inapplicable, merely report that it is skipped, rather than discarding the PASS for all the parts that do work. In the process, eliminate a spurious layer of indentation; the earlier test only needed a scope to contain its declaration, a goal adequately achieved by the scope of the if constexpr block. Task-number: QTBUG-99123 Pick-to: 6.2 6.3 Change-Id: Ie4790a24ebf49a7f3035ffad42d78450e1560832 Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Replace uses of _qs with _s in testsSona Kurazyan2022-04-0715-55/+83
| | | | | | Task-number: QTBUG-101408 Change-Id: If092a68828a1e8056259cf90d035d9a87989244b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Add literal operators for QString/QByteArray to StringLiterals namespaceSona Kurazyan2022-04-072-30/+80
| | | | | | | | | | | | [ChangeLog][QtCore] Added literal operators for _s and _ba for QString and QByteArray respectively in the Qt::Literals::StringLiterals namespace. Task-number: QTBUG-101408 Change-Id: I5cd4e7f36f614ea805cfecc27b91c5d981cd3794 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Q[Multi]Hash: fix squeeze()Ivan Solovev2022-04-061-1/+94
| | | | | | | | | | | | | | | | | | | When calling QHash::reserve(), or when creating the internal QHashPrivate::Data structure, the value 0 for the size parameter is reserved for performing the squeeze operation. However commit 8a984ab772dd194e39094e728b869e65912912a7 broke it, by using the 0 value in QHashPrivate::Data constructors as a mark that no resizing needs to be done. This patch reverts the problematic commit (also applying some later fixes to the code), and adds the missing tests for Q[Multi]Hash::squeeze(). Pick-to: 6.3 6.2 Change-Id: Id644df7b2beb008e6a37b2c89b709adfbd893e25 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Q[Multi]Hash::reserve(): do nothing if desired size is less than currentIvan Solovev2022-04-061-0/+31
| | | | | | | | | | | | | | | | Calling Q[Multi]Hash::reserve(n) when n is much smaller than the current amount of elements in the hash, could result in an infinite loop, because at some point the algorithm could not find a free bucket for the element. Fixing it by returning early if the new desired capacity is less than current. Fixes: QTBUG-102067 Pick-to: 6.3 6.2 Change-Id: I38ef0b2168c4e2a317eedf91b2155b1fdffb1c27 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QByteArray/QVarLengthArray: add missing resize(n, v) overloadsMarc Mutz2022-04-062-0/+41
| | | | | | | | | | | | | | | | | | QList and QString had them, so add them to QByteArray and QVarLengthArray, too. In the QVLA case, we need to jump though a hoop or two to avoid having to duplicate all the reallocation logic. Nothing a few template tricks cannot solve. [ChangeLog][QtCore][QByteArray] Added resize(n, ch) overload. [ChangeLog][QtCore][QVarLengthArray] Added resize(n, v) overload. Fixes: QTBUG-102270 Change-Id: I0d281ae5b574f440f682e4a62427b434dcf5b687 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QBuffer: fail early in seek() beyond QByteArray's max capacityMarc Mutz2022-04-051-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On 32-bit platforms, the range of qsizetype is smaller than the range of the qint64 used as a parameter in seek(). When seek()ing beyond the current buffer's size, the old code relied on a write() to fill the gap with NUL bytes. This has two problems: First, this may allocate a huge amount of memory just to find that it cannot write that much, possibly even taking the program down when the allocation in the QByteArray ctor fails, instead of returning false from seek(). Second, the QByteArray ctor to which we pass the gapSize only takes qsizetype, not qint64, so we were writing data of size gapSize mod (INT_MAX+1) on 32-bit platforms, which may succeed, just to find that that wasn't the number of bytes we expected to be written. By that time, however, the internal buffer has already been enlarged. Fix by checking whether the desired seek position is within the limits that QByteArray can contain early on, before attempting to construct such a large QByteArray. [ChangeLog][QtCore][QBuffer] Fixed silent data corruption on 32-bit platforms when seek() fails due to position > INT_MAX. Pick-to: 6.3 6.2 5.15 Fixes: QTBUG-102274 Change-Id: Ib63cef7e7e61ef8101a5f056c7b2198bb7baa228 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QBuffer: fix writing more than two GiB of dataMarc Mutz2022-04-041-0/+53
| | | | | | | | | | | | | | | | | | | | | In Qt 6, QByteArray can hold more than two GiB of data on 64-bit platforms, so QBuffer should be able to handle writes of more than two GiB, too. But the implementation didn't check for overflow and held sizes in int variables, so it happily reported success but wrote data only mod INT_MAX. Fix by carefully avoiding overflow and using size variables of proper type. [ChangeLog][QtCore][QBuffer] Fixed silent data truncation when writing more than two GiB at once on 64-bit platforms. Pick-to: 6.3 6.2 Fixes: QTBUG-102171 Change-Id: Ib666f9f7db24495b4ed64191a48b35edc410f7e9 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* We do in fact support 'F' format for floating-point valuesEdward Welbourne2022-04-012-1/+102
| | | | | | | | | | | | | | Update docs and add tests. [ChangeLog][QtCore] Documented existing support for 'F' format when converting floating-point numbers to strings in QLocale::toString(), hence equally for QString's floating-point formatting. Previously it was supported but the documentation neglected to mention it; it only differs from 'f' for infinities and NaN. Change-Id: Ic946c0f7b9e86fdf512daa3124bea57fc664b34b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Move some purely floating-point testing from tst_QLocale to tst_QNumericEdward Welbourne2022-04-012-24/+13
| | | | | | | | | The testing of infinity and NaN somewhat duplicated existing tests in tst_QNumeric and, in any case, belongs there. Change-Id: I6b5d1ff9767daf8e4bbe0025d3efab3d74ed35de Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Use constants of the correct type in qnumeric NaN testEdward Welbourne2022-04-011-11/+12
| | | | | | | | | Replaces 0, 0.0, 1, 1.0 and 2.0 with zero, one and two constants of the templated floating-point type, to avoid type-conversions which might have meant the test only checked doubles, or similar. Change-Id: Id9d4488f0cc7226b5b8958d2a204a76fe5ae469d Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 00:02:27 +0000