summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/text/qstring
Commit message (Collapse)AuthorAgeFilesLines
* QString::arg: deprecate use of arbitrary Unicode digits as replacementsGiuseppe D'Angelo2021-11-301-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only documented replacements for Q*String*::arg() are sequences like %1, %2, %3 -- where the n-th number is expressed using a sequence of ASCII digits [1]. The code parsing the replacements however used the QChar::digitValue() function. That function simply checks if a QChar has a *Unicode digit value* (no matter what its block/category is), and if so, returns the corresponding digit value as an int (otherwise returns -1). The result of this is that a sequence like "%¹" or "%१" actually triggered substitutions (both count as "1"). Similarly, QChars with a digit value would be parsed as part of longer sequences like "%1²" (counting as "12" (!)). This behavior is weird, undocumented, and extremely likely the usual backstabbing by Unicode by using "convenience" QChar methods -- that is, never *intended* by the implementation. This commit deprecates (via warnings) such usages, which for the time being are left working as before (in the name of backwards compatibility). At the same time: given it's extremely unlikely that someone would be deliberately relying on this behavior, it implements the desired change of behavior (only accept sequences of ASCII digits) starting from Qt 6.6, that is, after the next LTS. Throughout Qt 6's lifetime users will still be able to control arg()'s behavior by setting an env variable, but that variable (and the support for Unicode digits) will disappear in Qt 7. To summarize: * Qt 6.3->6.5: default is Unicode digits, env var to control * Qt 6.6->6.x: default is ASCII digits, env var to control * Qt 7: only ASCII digits, no env var [1] That's the name Unicode gives to them, cf. https://www.unicode.org/charts/PDF/U0000.pdf [ChangeLog][QtCore][Deprecation Notices] The arg() functions featured in Qt string classes have always been documented to require replacements tokens to be sequences of ASCII digits (like %1, %2, %34, and so on). A coding oversight made it accept sequences of arbitrary characters with a Unicode digit value instead. For instance, "%2੩" is interpreted as the 23rd substitution; and "%1²" is interpreted as the 12th substitution. This behavior is deprecated, and will result in runtime warnings. Starting from Qt 6.6, arg()'s behavior will be changed to accept only ASCII digits by default. That means that "%1²" is going to be interpreted as substitution number 1 followed by the "²" character (which does not get substituted, so it gets left as-is in the result). Users can restore the previous semantics (accept Unicode digits) by setting the QT_USE_UNICODE_DIGIT_VALUES_IN_STRING_ARG environment variable to a non-zero value. In Qt 7, arg() will only support sequences of ASCII digits. Note that from Qt 6.3 users can also set QT_USE_UNICODE_DIGIT_VALUES_IN_STRING_ARG to zero; this will make arg() use ASCII digits only, in preparation for the future change of defaults. Change-Id: I8a044b629bcca6996e76018c9faf7c6748ae04e8 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Move locale-switching code in tests to a shared headerEdward Welbourne2021-09-141-10/+2
| | | | | | | | | | | | | | | | | | | | | | QLocale and QString tests had copies of a TransientLocale; we've recently improved the QLocale one. Rather than duplicating those rather complicated improvements, finally share a common version. In the process, I noticed that setlocale() only returns the prior value when passed nullptr as the new value; so rework the implementation to get that right, so that it now correctly restores the prior locale. That, in turn, means there's now a later call to setlocale(), when we actually set the changed setting, which may invalidate the earlier return; so copy it to a QByteArray before the second call. Included Ivan Solovev's improved version of how to reset the locale, since TransientLocale needs it. Pick-to: 6.2 Change-Id: I4cb1efbda42f0e2cdd934e04b3b3732ce0f45a06 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Replace FreeBSD's strtou?ll() with std::from_chars()-based strntou?ll()Edward Welbourne2021-08-301-1/+75
| | | | | | | | | | | | | | | Remove third-party code in favor of STL. Implement (for now) strtou?ll() as inlines on strntou?ll() calling strlen() for the size parameter. (This is not entirely safe, as a string lacking '\0'-termination but with at least some non-matching text after the numeric portion would formerly be parsed just fine, but would now produce a crash. However, strtou?ll() are internal and callers should be ensuring '\0'-termination.) Task-number: QTBUG-74286 Change-Id: I0c8ca7d4f6110367e93b4c0164854a82c5a545e1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QBA(V)/QS(V)::lastIndexOf: fix the search of 1-char needlesGiuseppe D'Angelo2021-08-261-1/+1
| | | | | | | | | | | | | | | | | | | | When a needle has length 1 (because it's a QChar/char16_t, or because it's a string-like of length 1) then an ad-hoc search algorithm is used. This algorithm had a off-by-one, by not allowing to match at the last position of a haystack (in case `from` was `haystack.size()`). That is inconsistent with the general search of substring needles (and what QByteArray does). Fix that case and amend wrong tests. This in turn unveiled the fact that the algorithm was unable to cope with 0-length haystacks (whops), so fix that as well. Drive-by, add a similar fix for QByteArray. Amends 6cee204d56205e250b0675c9c6d4dd8a2367f3c4. Pick-to: 6.2 Change-Id: I6b3effc4ecd74bcbcd33dd2e550da2df7bf05ae3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QString: use the QRegularExpression operations on QStringViewGiuseppe D'Angelo2021-08-191-10/+10
| | | | | | | | | | | | | | | | There's no need of duplicating code all over the place; QString can reuse the implementation of the indexOf/contains/count/lastIndexOf family of functions already existing for QStringView. For simplicity, the warning messages (that our autotests actually check) have been made more generic, rather than introducing some other parameter (as in, "which class is using this functionality so to emit a more precise warning"), which would have just complicated things as the implementation of these functions is exported and used by inline QStringView member functions. Change-Id: I85cd94a31c82b00d61341b3058b954749a2d6c6b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QS(V)/QBA(V)/QL1S::lastIndexOf: fix the offset calculationsGiuseppe D'Angelo2021-08-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to fix 0-length matches at the end of a QString, be83ff65c424cff1036e7da19d6175826d9f7ed9 actually introduced a regression due to how lastIndexOf interprets its `from` parameter. The "established" (=legacy) interpretation of a negative `from` is that it is supposed to indicate that we want the last match at offset `from + size()`. With the default from of -1, that means we want a match starting at most at position `size() - 1` inclusive, i.e. *at* the last position in the string. The aforementioned commit changed that, by allowing a match at position `size()` instead, and this behavioral change broke code. The problem the commit tried to fix was that empty matches *are* allowed to happen at position size(): the last match of regexp // inside the string "test" is indeed at position 4 (the regexp matches 5 times). Changing the meaning of negative from to include that last position (in general: to include position `from+size()+1` as the last valid matching position, in case of a negative `from`) has unfortunately broken client code. Therefore, we need to revert it. This patch does that, adapting the tests as necessary (drive-by: a broken #undef is removed). Reverting the patch however is not sufficient. What we are facing here is an historical API mistake that forces the default `from` (-1) to *skip* the truly last possible match; the mistake is that thre is simply no way to pass a negative `from` and obtain that match. This means that the revert will now cause code like this: str.lastIndexOf(QRE("")); // `from` defaulted to -1 NOT to return str.size(), which is counter-intuitive and wrong. Other APIs expose this inconsistency: for instance, using QRegularExpressionIterator would actually yield a last match at position str.size(). Similarly, using QString::count would return `str.size()+1`. Note that, in general, it's still possible for clients to call str.lastIndexOf(~~~, str.size()) to get the "truly last" match. This patch also tries to fix this case ("have our cake and eat it"). First and foremost, a couple of bugs in QByteArray and QString code are fixed (when dealing with 0-length needles). Second, a lastIndexOf overload is added. One overload is the "legacy" one, that will honor the pre-existing semantics of negative `from`. The new overload does NOT take a `from` parameter at all, and will actually match from the truly end (by simply calling `lastIndexOf(~~~, size())` internally). These overloads are offered for all the existing lastIndexOf() overloads, not only the ones taking QRE. This means that code simply using `lastIndexOf` without any `from` parameter get the "correct" behavior for 0-length matches, and code that specifies one gets the legacy behavior. Matches of length > 0 are not affected anyways, as they can't match at position size(). [ChangeLog][Important Behavior Changes] A regression in the behavior of the lastIndexOf() function on text-related containers and views (QString, QStringView, QByteArray, QByteArrayView, QLatin1String) has been fixed, and the behavior made consistent and more in line with user expectations. When lastIndexOf() is invoked with a negative `from` position, the last match has now to start at the last character in the container/view (before, it was at the position *past* the last character). This makes a difference when using lastIndexOf() with a needle that has 0 length (for instance an empty string, a regular expression that can match 0 characters, and so on); any other case is unaffected. To retrieve the "truly last" match, one can pass a positive `from` offset to lastIndexOf() (basically, pass `size()` as the `from` parameter). To make calls such as `text.lastIndexOf(~~~);`, that do not pass any `from` parameter, behave properly, a new lastIndexOf() overload has been added to all the text containers/views. This overload does not take a `from` parameter at all, and will search starting from one character past the end of the text, therefore returning a correct result when used with needles that may yield 0-length matches. Client code may need to be recompiled in order to use this new overload. Conversely, client code that needs to skip the "truly last" match now needs to pass -1 as the `from` parameter instead of relying on the default. Change-Id: I5e92bdcf1a57c2c3cca97b6adccf0883d00a92e5 Fixes: QTBUG-94215 Pick-to: 6.2 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QString/QByteArray::number(double): Test big numbersMårten Nordheim2021-08-171-1/+8
| | | | | | | | | | | Exhausts the entire buffer which double-conversion is left to work with. Also has a large amount of precision, which apparently we need to store temporarily. Task-number: QTBUG-88484 Change-Id: I87e8c323676465f1b8695e086020df1240d0d0d7 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Assert that special handling of '0' padding does what it shouldEdward Welbourne2021-08-101-21/+61
| | | | | | | | | | | | | | | | | | | | When formatting numbers, if the fill character used to left-pad to field widths is '0', the code delegates that padding to the QLocaleData's ZeroPadded formatting option. Since we want the zeros before any minus sign, and don't want to subsequently add more zeros before it, check that this has worked as expected when calling replaceArgEscapes(), to confirm that it doesn't need to worry about that. Add some tests that verify the expected behavior. In the process, tidy up the code doing this. Rename a local variable to match our coding style, split a long line. Pick-to: 6.2 Change-Id: I7cc430c5bceb006cf4e226bca33da16bd2bb1937 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QByteArray::number(double): Extend the testMårten Nordheim2021-08-041-66/+5
| | | | | | | | | Move out and share the test data from the QString::number_double() test and re-use it for this one. Task-number: QTBUG-88484 Change-Id: I6502d1d360657f6077e5c46636f537ddfdde3a83 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rework tst_QString::remove_regexp() and its data tableEdward Welbourne2021-08-041-30/+36
| | | | | | | | | | | | | | | | | | | The test was producing a warning about the invalid test, for which replace_regexp() had anticipated that warning; do the same in remove_regexp(). The two tests shared a date() method, but the remove test was a no-op on the tests with non-empty replacement text; move the column set-up and data rows with empty replacement to remove's data() function, from replace's, and reverse the direction of calling each other between data() functions, so each test gets the cases that are relevant to it and no spurious PASSes happen for no-op tests. In the process, give moved test-cases informative names; relocate the (entirely re-written) remove data function to beside its test; and eliminate a pointless local variable from both tests (it used to be needed when testing both QRegExp and QRegularExpression). Pick-to: 6.2 Change-Id: I93dcfc444f984edf5c029f99306aff6bc95d554a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Refine localeAwareCompare() test-case filtering on ICUEdward Welbourne2021-08-041-6/+9
| | | | | | | | | | | | | | | | The code to work around setlocale() mis-describing en_US as C ensured that we didn't accept the C test-cases when the locale was really en_US; but neglected to accept the en_US test-cases when the locale really was en_US but was misdescribed as C. This lead to no tests being run when the locale was en_US. Tweak the logic of the test filtering to compare the wanted locale against the system locale both when C is wanted and when it isn't. Make the skip-messages a little more informative. Pick-to: 6.2 6.1 Change-Id: I4e072e12819144b2941b87a5f486534047d9a579 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add a few more cases to the QString::number(double) testMårten Nordheim2021-07-301-0/+4
| | | | | | | Formatting using scientific notation with extra precision wasn't tested Change-Id: I7a89a0f3d6468515604e43e52fc366dedf3c39ea Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix QString test compilation without QRegularExpressionIvan Solovev2021-07-291-5/+64
| | | | | | | | | | | The QString itself can be compiled without QRegularExpression, but the tests do not check if they are supported or not. This patch fixes the issue by introducing the proper #ifdef guards. Task-number: QTBUG-91736 Pick-to: 6.2 6.1 Change-Id: I797691f78a34d4f78a86af99c78bf06e26e846d1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QString: extend number(double) formatting testMårten Nordheim2021-07-281-4/+90
| | | | | | | | | The number(double) testing done in tst_qstring was a bit lacking, so other tests (like tst_uic) had to be run to properly test changes. Task-number: QTBUG-88484 Change-Id: I2fc6cba27788ab4fab6d625257f35868e2b684e3 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QString: extend unit testsIvan Solovev2021-07-221-74/+495
| | | | | | | | | | | | | | | | This patch introduces some test improvements to check the calls of different methods on an empty default-constructed string. Apart from that, some other tests are added to extend code coverage. As a drive-by: * fix int -> qsizetype in the test data * fix int -> enum in the test data Task-number: QTBUG-91736 Pick-to: 6.2 6.1 Change-Id: I159473b7f5dcbea1bdaf2966979e066296351208 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* QString: Respect precision when reading data for %.*s format stringUlf Hermann2021-06-221-0/+30
| | | | | | | | | | | If we disregard the precision we may read a very large string that we subsequently discard. Furthermore, people use this to read non-null-terminated strings, which randomly crashes. Pick-to: 5.15 6.1 6.2 Change-Id: Ifa255dbe71c82d3d4fb46adfef7a9dc74bd40cee Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Tidy up tst_QString::localeAwareCompare()Edward Welbourne2021-06-161-121/+262
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was suppressed unconditionally (albeit in different places and with different levels of obviousness) almost everywhere, due to inability to set the system locale in use by the implementation. Several test-cases used ISO-8859-1 encoding on Q_OS_MAC, where the tests were all suppressed anyway. A block of no_NO tests was #if 0'd out; and should, in any case, have been nb_NO. Tests of any locale but en_US were skipped on Q_OS_WIN because we can't set the locale (but including the tests of en_US tacitly assumed that's the system locale). If setlocale() failed, for ICU or DARWIN, the test was skipped; but we might as well check for this in the _data() to save repetition. The test was laboriously going through the sign cases; relocate the QString::compare() test's sign() function so that we can use it here, too, and simply QCOMPARE() signs. Introduce a TransientLocale class, copied from tst_QLocale, to take care of setting and restoring the locale using setlocale(). Change the locale name to a QByteArray so that we save having to convert it to one in order to pass it to setlocale(). Since that changed every _data() row, reformat those rows in the process - most of them were long lines. On the systems where we can't set the locale used by the function being tested, condition each block of tests in the _data() on whether LC_COLLATE looks like the locale to be tested, and report how a determined developer at least can (by repeatedly running the test with different locales set) test all the cases; and we'll attempt the ones that we can, when one of the relevant locales is in use. If that leaves us with no tests we can do, QSKIP() in the _data() to avoid an assert failure for "Test data requested, but no testdata available." Change-Id: I75709fda8827dcbe74f80c4136042054da6fcb13 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Turn tst_QString::setRawData()'s QSKIP into QEXPECT_FAIL()sEdward Welbourne2021-06-151-1/+3
| | | | | | | | | | | | | In commit 287ace562ee5ddff22f7dbf4e49ae5f0520f2308, part of this test was suppressed without filing a Jira ticket (or, at least, without recording it in the QSKIP message). Since it's a known failure, it should at least be a QEXPECT_FAIL, not a QSKIP. Since only some of the subsequent parts of the test fail, I used QEXPECT_FAIL(,,Continue) on each of the failing tests. Task-number: QTBUG-94450 Change-Id: Iebc6801210c289b4502e59116e71d5901b71aa46 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Don't use APPLESS testing for QStringEdward Welbourne2021-06-151-1/+2
| | | | | | | | Its collation (and everything locale-related) is only supported during the lifetime of QApplication. Change-Id: Ide97795664d45768e66248d47c3b1da83935b0d6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add .UTF-8 suffixes to locale-names passed to setlocale()Edward Welbourne2021-06-111-0/+1
| | | | | | | | | | | We use UTF-8 locales by default since Qt 6; and relatively few systems have the encoding-unspecified locales we were trying to use, with the result that the setlocale() calls all failed. Task-number: COIN-689 Change-Id: Id791ba269bf4abac29da3daa4fd01684ca9caa7a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Remove two QEXPECT_FAIL()s that no longer appear to be validEdward Welbourne2021-06-111-12/+0
| | | | | | | | | Because they were followed by a QVERIFY(false), no-one noticed until now. Dates from 2011, when ICU support was first added. I guess someone fixed the problem in the intervening decade. Change-Id: I847816c297156e65397c652767f286bc4de193a2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add more tests for QList/QString/QBAAndrei Golubev2021-04-271-0/+73
| | | | | | | | | | | | | | | | The major part is stability tests for QList operations, Also added std::shared_ptr to the Custom type. shared_ptr accesses the memory which does not directly belong to QList, so using it inside a passed-to-qlist type is beneficial (e.g. ASan could catch extra issues) Basic prepend-aware cases added to QString/QBA tests Task-number: QTBUG-93019 Change-Id: I50e742bdf10ea9de2de66539a7dbb9abc4352f82 Reviewed-by: Lars Knoll <lars.knoll@qt.io> (cherry picked from commit adb41bbe00b2b853d4dd26cd9ee77ae5ed541576) Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Remove meaningless QT_NO_UNICODE_LITERAL check in QString literal testsAndrei Golubev2021-03-301-5/+0
| | | | | | | | | | | This check doesn't really do anything useful anymore: QStringLiteral is used in Qt without any extra QT_NO_UNICODE_LITERAL #if-ery Additionally, clean the related (and outdated) comment in {QString, QByteArray}::literals() Change-Id: I65b1eac33c5470508997be24f9ba6cf56d8578ea Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Add literal operators for QString and QByteArrayAndrei Golubev2021-03-301-0/+24
| | | | | | | | | | | | [ChangeLog][QtCore][QString] Added literal operator u"..."_qs that converts a char16_t string literal to QString [ChangeLog][QtCore][QByteArray] Added literal operator "..."_qba that converts char string literal to QByteArray Change-Id: I4aa59b28cc17bff346b378eb70008fb8185d21ac Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Purge various BLACKLIST entries that are now fixedEdward Welbourne2021-02-021-3/+0
| | | | | | | | | | | | | Based on BPASS results from recent test-runs. Task-number: QTBUG-69131 Fixes: QTBUG-87416 Fixes: QTBUG-87662 Task-number: QTBUG-87663 Fixes: QTBUG-88705 Change-Id: I8ebe014517bfa8d124e86b821650b07c591ea16e Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Remove the qmake project filesJoerg Bornemann2021-01-071-17/+0
| | | | | | | | | | | | | | | | Remove the qmake project files for most of Qt. Leave the qmake project files for examples, because we still test those in the CI to ensure qmake does not regress. Also leave the qmake project files for utils and other minor parts that lack CMake project files. Task-number: QTBUG-88742 Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Replace QtTest headers with QTestDavid Skoland2020-12-222-2/+4
| | | | | | | | | | | Complete search and replace of QtTest and QtTest/QtTest with QTest, as QtTest includes the whole module. Replace all such instances with correct header includes. See Jira task for more discussion. Fixes: QTBUG-88831 Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44 Pick-to: 6.0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QString::lastIndexOf: fix off-by-one for zero length matchesGiuseppe D'Angelo2020-12-101-1/+1
| | | | | | | | | | | Otherwise, it would report that lastIndexOf of an empty pattern in an empty string doesn't exist. Next commit adds extensive autotests; for now, disable a broken autotest (which already features a comment about why it's broken). Change-Id: I9a0e5c0142007f81f5cf93e356c8bd82f00066f7 Pick-to: 5.15 6.0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QString: fix count(QRegularExpression)Giuseppe D'Angelo2020-12-091-0/+1
| | | | | | | | | | | | | | | | | There is an off by one in the implementation of count(): a match must be attempted even at the very end of the string, because a 0-length match can happen there. While at it, improve the documentation on the counter-intuitive behavior of count(), which doesn't merely count how many times a regexp matches into a string using ordinary global matching. [ChangeLog][QtCore][QString] Fixed a corner case when using QString::count(QRegularExpression), causing an empty in the last position not to be accounted for in the returned result. Change-Id: I064497839a96979abfbac2d0a96546ce160bbc46 Pick-to: 5.15 6.0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add unit test for QString::insert(negativeint, QChar)Andreas Buhr2020-11-201-0/+1
| | | | | | | | | | QString::insert(qsizetype, QChar) can insert at negative positions, then counting from the end of the string. Coverage analysis revealed we do not have a unit test for this. This patch adds a unit test. Pick-to: 6.0 Change-Id: I8d41b38df964c07fe2d2e7be444f8236c9e19b5d Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Add unit test for QString::replace with out-of-bounds positionAndreas Buhr2020-11-191-0/+10
| | | | | | | | | | | QString::replace(pos, len, *unicode, size) can handle positions which are outside of the this-string. In that case, it is a no-op. Coverage analysis revealed we do not have a unit test for this. This patch adds one. Change-Id: Id4a407e860fff0d5c7c0a200c379e5e3961c86d2 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
* Fix logic error in QString::replace(ch, after, cs)Andreas Buhr2020-11-191-0/+11
| | | | | | | | | | Coverage analysis showed that an if-branch marked "Q_LIKELY" was never taken. It turns out the code was incorrect, but behaved correctly. This patch fixes the logic and adds a unit test. Pick-to: 5.15 Change-Id: I9b4ba76392b52f07b8e21188496e23f98dba95a9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Change QString formatting of negative numbers in non-base-10Andreas Buhr2020-11-191-0/+64
| | | | | | | | | | | | | | | | | | | For bases other than 10, negative numbers have been converted to QString by casting them to an unsigned number and converting that. Thus QString::number(-17, 16) returned "0xffffffffffffffef", for example. This patch changes the behavior so that negative numbers are converted like positive numbers. Additinally, this patch adds unit tests for QString::number. [ChangeLog][Important Behavior Changes] Changed QString::number(integer, base) for negative numbers and bases other than 10 to return the string corresponding to the absolute value, prefixed by "-". Fixes: QTBUG-53706 Change-Id: I0ad3ca3f035d553860b262f5bec17dc81714d8ac Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QChar: make construction from integral explicitGiuseppe D'Angelo2020-11-151-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QChar should not be convertible from any integral type except from char16_t, short and possibly char (since it's a direct superset). David provided the perfect example: if (str == 123) { ~~~ } compiles, with 123 implicitly converted to QChar (str == "123" was meant instead). But similarly one can construct other scenarios where QString(123) gets accidentally used (instead of QString::number(123)), like QString s; s += 123;. Add a macro to revert to the implicit constructors, for backwards compatibility. The breaks are mostly in tests that "abuse" of integers (arithmetic, etc.). Maybe it's time for user-defined literals for QChar/QString, but that is left for another commit. [ChangeLog][Potentially Source-Incompatible Changes][QChar] QChar constructors from integral types are now by default explicit. It is recommended to use explicit conversions, QLatin1Char, QChar::fromUcs4 instead of implicit conversions. The old behavior can be restored by defining the QT_IMPLICIT_QCHAR_CONSTRUCTION macro. Change-Id: I6175f6ab9bcf1956f6f97ab0c9d9d5aaf777296d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Android: blacklist a list of failing tests for androidAssam Boudjelthia2020-11-041-0/+3
| | | | | | | | | | | | | | | | We want to re-enable Android tests in QTQAINFRA-3867. However, many tests are failing already preventing that from happening. QTBUG-87025 is currently keeping track (links) to all of those failing tests. The current proposal is to hide those failing tests, and enable Android test running in COIN for other tests. After, that try to fix them one by one, and at the same time we can make sure no more failing tests go unnoticed. Task-number: QTBUG-87025 Change-Id: Ic1fe9fdd167cbcfd99efce9a09c69c344a36bbe4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix strange capacity check in tst_QString::append_special_casesAndrei Golubev2020-10-211-1/+2
| | | | | | | | | | | We cannot rely on "QString a; a.insert(0, u'A');" to give a.capacity() >= 3, this is clearly an implementation detail. Changed the check to a meaningful one Task-number: QTBUG-87416 Change-Id: I2e017c1292d360e32b85b903361027485c08ea74 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Another round of replacing 0 with nullptrAllan Sandfeld Jensen2020-10-071-1/+1
| | | | | | | | | This time based on grepping to also include documentation, tests and examples previously missed by the automatic tool. Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Change QString::fromLatin1 and friends to use QByteArrayViewLars Knoll2020-10-051-19/+20
| | | | | | | | | | | | Also adjust the QString constructor from QByteArray to ignore \0 characters in the string (and not terminate conversion there). [ChangeLog][QtCore][QString] Constructing a QString from a QByteArray will not stop at intermediate '\0' (null) characters in the string as in Qt 5, but will convert all characters in the byte array. Change-Id: I1f6bfefe76dfa9072b165903fec7aa4af1abd882 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: Regenerate projects to use new qt_internal_ APIAlexandru Croitor2020-09-231-3/+3
| | | | | | | | | | | Modify special case locations to use the new API as well. Clean up some stale .prev files that are not needed anymore. Clean up some project files that are not used anymore. Task-number: QTBUG-86815 Change-Id: I9947da921f98686023c6bb053dfcc101851276b5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Use UTF-8 when converting 8 bit data in QTextStreamLars Knoll2020-09-151-1/+9
| | | | | | | | | This was overlooked when doing the conversion to use UTF-8 as the standard 8 bit encoding for text. Fixes: QTBUG-54942 Change-Id: Ib7b1b75b4d694648ab7143f6930b6bb1dcad19c9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove deprecated APILars Knoll2020-09-151-4/+4
| | | | | | | And replace it's few remaining usages Change-Id: I2dfbbaa5259acfece028606bef1e872c5692f9fe Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Purge Q_{STDLIB,COMPILER}_UNICODE_STRINGSEdward Welbourne2020-09-141-18/+2
| | | | | | | | | These were now always defined, hence redundant. Leave the #define in place so that we can verify we actually do always define it, in a #else of an existing #if check on it. Change-Id: Iea4c3dbc8f9982268bcf81da5ef17fe2ebf5c462 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove '\0' space reservation logic in QStringAndrei Golubev2020-09-101-1/+2
| | | | | | | | | Changed QString to use implicit element reserved by QArrayData Task-number: QTBUG-84320 Change-Id: If517500b3f0e71bb8d2989c64815a634aa8dd554 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Use checked string iteration in case conversionsEdward Welbourne2020-08-291-0/+28
| | | | | | | | | | | | | | | | | | The Unicode table code can only be safely called on valid code-points. So code that calls it must only pass it valid Unicode data. The string iterator's Unchecked Unchecked methods only provide this guarantee when the string being iterated is guaranteed to be valid UTF-16; while client code should only use QString, QStringView and friends on valid UTF-16 data, we have no way to be sure they have respected that. So take the few extra cycles to actually check validity in the course of iterating strings, when the resulting code-points are to be passed to the Unicode table look-ups. Add tests that case mapping doesn't access Unicode tables out of range (it'll trigger the new assertion). Added some comments to qchar.h that helped me understand surrogates. Change-Id: Iec2c3106bf1a875bdaa1d622f6cf94d7007e281e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Prepend optimize QStringAndrei Golubev2020-08-291-0/+103
| | | | | | | | Added prepend optimization to QString Task-number: QTBUG-84320 Change-Id: Iaa8df790a10c56ecceb06f7143718fb94874ce76 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Move QStringRef and remains to Qt5CompatKarsten Heimrich2020-08-201-428/+40
| | | | | | | | | Export some private functions from QUtf8 to resolve undefined symbols in Qt5Compat after moving QStringRef. Task-number: QTBUG-84437 Change-Id: I9046dcb14ed520d8868a511d79da6e721e26f72b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Replace Qt CONSTEXPR defines with constexprAllan Sandfeld Jensen2020-08-141-2/+2
| | | | | | | | Both normal and relaxed constexpr are required by our new minimum of C++17. Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Implement UTF-16 to UTF-8 case-insensitive compare and make publicThiago Macieira2020-08-051-2/+28
| | | | | Change-Id: Ied637aece2a7427b8a2dfffd16116cf3645c6359 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QString::vasprintf: fix 't' modifier for integers on 64-bitThiago Macieira2020-07-311-25/+35
| | | | | | | | | | | | | ‘t’ Specifies that the argument is a ‘ptrdiff_t’. This modifier was introduced in ISO C99. We use qsizetype, which is the same width as ptrdiff_t, so it makes no difference in va_arg(). Change-Id: Iea47e0f8fc8b40378df7fffd16255730109413a5 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Move QRegExp and its remaining mentions out of QtCoreSona Kurazyan2020-07-131-1/+1
| | | | | | Task-number: QTBUG-85235 Change-Id: Ibd6c98d952c1bb9916b64715c6430fb0d3fe3843 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-22 19:12:10 +0000