It is no longer handled separately from Android.
This effectively reverts commit 6d50f746fe
Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This ensures that a command such as
$ ninja tst_qlocale && ninja tst_qlocale_check
will automagically build the syslocaleapp program that the test runs
from a subtest. Similar for testlib's selftests and tst_QProcess.
As a drive-by, pruned some legacy comments from when CMakeLists.txt
files were generated from .pro files.
Change-Id: I67691a8175aaef124d4104cf1898193993408bdf
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
QLocale::system() was not making use of QLocaleFormat::Narrow, always
treating it in the same way as QLocaleFormat::Short.
This patch fixes the issue for day and month names.
The implementation falls back to CLDR if system locale fails to
provide some data.
Pick-to: 6.2
Task-number: QTBUG-84877
Change-Id: Ia37e59dbf02d7a5e230f2767d294b9ab7de37f33
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
System headers were jumbled in with Qt headers. Separate those out and
use standard names for Qt headers. Tidied some #if-ery.
Change-Id: Ic8c61797303567eeaef48e2560e91924ddb380f0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
The name of is_utf8_encoded type seems to imply that QByteArray and
const char * contain UTF-8 encoded data. This is not always the case.
When used with QByteArray API, those types are handled as containing
ASCII-only. It's only when used with APIs of other classes (QString,
QLatin1String) they are handled as UTF-8. This renames the check to
is_bytearray_like_v and clarifies its usage. No need to handle
QUtf8StringView this way because it works just fine with the current
testcases.
While at it, also remove unused is_latin1_encoded trait.
Task-number: QTBUG-92021
Change-Id: I44e40cf3c0dd07e5b3cf1e47ff7a04f1c548aa97
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The existing a, ap, A and AP specifiers all force the case of the
formatted am/pm indicator. The indicators returned by QLocale's
amText() and pmText() methods are those given in CLDR, with no case
coercion. Application writers may reasonably want these strings used
verbatim, rather than having to chose a case and impose it on the
locale's indicators, in defiance of national custom. For example,
while en_US uses upper-case indicators by default, cs_CZ uses
lower-case ones. An application author writing a time format has been
forced to chose which of these locales to be wrong in.
Add support for aP and Ap specifiers, whose mixed case indicates that
the locale's case is to be respected. Amend an existing test-case of
tst_QLocale's formatDateTime() that used Ap (expecting, of course, an
upper-case indicator followed by a stray p) to now expect the
locale-appropriate-cased indicator. Extend formatTime() to test cases
using aP and Ap, to illustrate the difference between en_US and cs_CZ.
Rework QDateTimeParser to also support the new format specifier. This
required expanding its Case enum, used by the getAmPmText() method,
which was formerly shared with QDateTimeEditPrivate; however, as that
class no longer makes any reference to this method, it and the enum
can be made private, allowing a systematic clean-up of their use.
Added test-cases for both serialization and parsing; and amended some
existing parsing tests to verify am/pm indicators are matched
case-insensitively.
[ChangeLog][QtCore][Important Behavior Changes] Time formats used by
QLocale, QTime and QDateTime's parsing and serialization now recognize
'aP' and 'Ap' format specifiers to obtain an AM/PM indicator, using
the locale-appropriate case for the indicator, where previously the
author of a time format had to pick a case that might conflict with
the user's locale. For QTime and QDateTime the locale is always C,
whose indicators are uppercase. For QLocale, the case will now match
that of amText() or pmText(). Previously, 'aP' would have been read as
a lower-case indicator followed by a 'P' and 'Ap' as an upper-case
indicator followed by a 'p'. The 'P' or 'p' will now be treated as
part of the format specifier: if the prior behavior is desired, either
use 'APp' or 'apP' as format specifier or quote the 'p' or 'P' in the
format. The prior 'a', 'ap', 'A' and 'AP' specifiers are otherwise
unaffected.
Fixes: QTBUG-95790
Change-Id: I26603f70f068e132b5c6aa63214ac8c1774ec913
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Some backends were missing support for standalone days and months,
also the standaloneDayName() implementation was always using the
same codepath as dayName().
This patch fixes the issues.
Support for narrow format will be added in the following patch.
Task-number: QTBUG-84877
Pick-to: 6.2
Change-Id: I38ee06342cafab544e3c69097bd0e6ae68e85645
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It was previously calling setlocale(), which makes no difference to
the Unix backend for the system locale, since that's based on
environment variables (that would normally be used to get default
values for the various setlocale() categories, but only the first time
each is asked for). So, on Unix, set the environment variable, too.
It's also necessary to instantiate a QSystemLocale instance
transiently to trigger a refresh of the system locale data.
Pick-to: 6.2
Change-Id: If92e44053f9021e96c814f4b289f4fadaa7027e0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This is the kind of loop that the autovectorizer is pretty good
at, but this is really just a type of memchr, so help dumber
compilers and build modes without vectorization.
Drive-up fix the style of the test code.
Change-Id: Ie72b0dd0fbe84d2caae0fffd16a022a35fa24c17
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We have previously been using the standalong (nominative) month names
both when asked for that and when asked for the plain (genitive) month
name, probably because there was no LCTYPE value for the
latter. However, MS's docs for the standalone values do contain a
comment telling us how to get the genitive names.
Rename the old monthName() to standaloneMonthName() and add a
monthName() that calls GetDateFormat() suitably, as described by the
MS doc.
Pick-to: 6.2 5.15
Fixes: QTBUG-92018
Fixes: QTBUG-86279
Change-Id: I27f63198c3a15b792683f476d2019078b0860f99
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The testcase was disabled with no explanation in
2766322de3 but seems to work fine.
Change-Id: Ibc22a4ffb756604e22c1f2cf1165919c1d7f1212
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Now that we don't need '\0'-termination on the data, this is possible.
Moved QByteArray's tests to tst_QByteArrayApiSymmetry and added some
more test-cases.
[ChangeLog][QtCore][QByteArrayView] Added numeric parsing methods.
Change-Id: Ic0df91ecfe5dbf6f008d344dd0464d7927f32273
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
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>
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 6cee204d56.
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>
Relying on the fact that a given capturing group captured a null string
doesn't allow users to distinguish whether a capturing group did not
capture anything, or captured a null substring (say, from a null subject
string).
Perl allows for the distinction: the entries in the @- and @+ arrays are
set to values in case there is a capture, but they're undef otherwise.
PCRE2 gives us the information already in the results "ovector", but
it was simply not exposed to QREM users. So, expose it.
[ChangeLog][QtCore][QRegularExpressionMatch] Added the hasCaptured()
family of functions to know if a given capturing group has captured
something.
Change-Id: Ic1320933d4554e2e313c0a680be1b1b9dd95af0b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
An oversight in the code kept the algorithm in the GB11 state, even if
the codepoint that is being processed wouldn't allow for that (for
instance a sequence of ExtPic, Ext and Any).
Refactor the code of GB11/GB12/GB13 to deal with code points that break
the sequences (falling back to "normal" handling).
Add some manual tests; interestingly enough, the failing cases are not
covered by Unicode's tests, as we now pass the entire test suite.
Amends a794c5e287.
Fixes: QTBUG-94951
Pick-to: 6.1 5.15
Change-Id: If987d5ccf7c6b13de36d049b1b3d88a3c4b6dd00
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Don't go via QString when we don't need to.
Put expected after actual, not the other way round.
Give tests and test-cases sensible names.
Prefer function-style cast over C-style.
Change-Id: I0b79534a9cc95f2e312a85394693ac674ff3d1d6
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
An empty QString(View) is allowed to have nullptr as its data pointer
(of course, only if its size is 0). This wasn't properly
checked in QRegularExpression, which passed such nullptr to
PCRE, and that resulted in PCRE raising an error (PCRE_ERROR_NULL).
Detect this case and pass a dummy pointer to keep PCRE happy.
Fixing and testing this in turn exposed a problem with QStringView
support in QRegularExpression when used over a null QString: the
code is supposed to use the QStringView(QString) constructor and NOT
qToStringViewIgnoringNull. That's because QRE distinguishes null
and empty subjects; when using qToStringViewIgnoringNull over
a null QString, one gets a non-null QStringView (!). Again, this in
turn exposed a problem with a QRegularExpression autotest that assumed
that a null match could only mean "no match" (instead, it can happen at
position 0 of a null QString(View)).
Change-Id: Ifb3cf14dec42ce76fcdbcb07ea1d80784d52ef65
Pick-to: 6.1 6.2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When trying to fix 0-length matches at the end of a QString,
be83ff65c4 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>
All the tests were using the C locale, so were equivalent to tests of
QTime::toString(). Add a locale column and some test-cases in
preparation for a change to am/pm indicators.
Task-number: QTBUG-95790
Change-Id: I3ad917b7a6f3d3bfe31d6a5a5da596025f173e81
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
Unlike simplified(), it just moves the end-points, without needing to
modify contents, so it makes sense (as for QStringView and
QLatin1String) to provide it. Moved QByteArray's trimmed() tests to
tst_QByteArrayApiSymmetry so that QBAV can now share them.
[ChangeLog][QtCore][QByteArrayView] Added trimmed().
Change-Id: Ifd7a752adb5f3d3e2ad0aa8220efa7e7d2d39baa
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
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>
Oliver Wolff reports that this test no longer hangs on Windows; and
the other plafroms for which it was skipped are no longer supported,
so remove the #if-ery that skips this test for platfroms on which
uncompressing corrupt data used to hang.
Change-Id: I94a3fd4b83338fe6e3a97ab055fe05e2f15b6b45
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
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>
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>
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>
The QtTest best practices documentations recommends using output
mechanisms such as qDebug() and qWarning() for diagnostic messages,
and this is also what most of our own tests do.
The QWARN() macro and corresponding internal QTest::qWarn() function
was added when QtTest was first implemented, but was likely meant as
an internal implementation detail, like its cousin QTestLog::info(),
which does not have any corresponding macro.
This theory is backed by our own QtTest self-test (tst_silent)
describing the output from QWARN() as "an internal testlib warning".
The only difference between QWARN() and qWarning(), besides the much
richer feature set of the latter, is that qWarning() will not pass
on file and line number information in release mode, but QWARN() will.
This is an acceptable loss of functionality, considering that the user
can override this behavior by defining QT_MESSAGELOGCONTEXT.
[ChangeLog][QtTest] QWARN() has been deprecated in favor of qWarning()
Pick-to: 6.2
Change-Id: I5a2431ce48c47392244560dd520953b9fc735c85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This follows up on commit 98666c8afc,
which did the same for QString. If someone wants to get formatting
suitable to an unsigned value, they can cast the value to that
unsigned type and the correct overload shall pick it up.
[ChangeLog][Important Behavior Changes] QByteArray's formatting of
negative whole numbers to bases other than ten now, like QString's
(since Qt 6.0), formats the absolute value and prepends a minus sign.
Task-number: QTBUG-53706
Pick-to: 6.2
Change-Id: I91fee23d25ac0d5d5bcfcbeccbac1386627c004a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Formatting using scientific notation with extra precision wasn't tested
Change-Id: I7a89a0f3d6468515604e43e52fc366dedf3c39ea
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This patch introduces some test improvements to check the calls of
different methods on an empty default-constructed string.
Apart from that, many other tests are added to extend code coverage.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: If86ef3d8611a678798b1bcc60a1a4f5598fd2179
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch fixed two bugs in indexOf/lastIndexOf:
1. The lastIndexOf(char, qsizetype) overload was crashing with an empty
QByteArray. It was unconditionally calling lastIndexOfCharHelper()
which assumes that this QBA is not empty. An explicit check for
the empty case is added.
2. The indexOf(QByteArray, qsizetype) overload was behaving incorrectly
while searching for an empty QByteArray. In this case it
unconditionally returned its second parameter (from). However, from
can be negative, or even exceed the size of this QByteArray. This
patch handles this cases properly.
As a drive-by: this patch adjusts the QByteArray::indexOf(char, qsizetype)
and QByteArray::lastIndexOf(char, qsizetype) overloads to match with the
QByteArrayView implementation. This is done to have similar code paths
in both cases and avoid tricky bugs in future.
Ideally we had to adjust the QByteArrayView implementation, but it's
fully inline, so can't be changed without breaking BC.
Task-number: QTBUG-91736
Pick-to: 6.2 6.1
Change-Id: Iaef2fdc5b99cce6aa342cca2d17544a1ad7ca677
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
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>
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>
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>
Add tests to verify parser behavior with locales that use code points
outside of Unicode BMP to represent dates. ccp is used for this because
Chakma language uses code points outside of BMP for both letters and
digits. QDateTimeParser currently is not able to handle this locale
correctly, so the tests are marked as expected failures.
Task-number: QTBUG-87111
Change-Id: I1cc6fe7304b47f19950ae0ad3179c4ffa946adb3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
- QString/QStringView overloads were designed to be compatible for all
possible argument types, so check that it stays that way
- QString/QAnyStringView overloads have several known ambiguities that
we cannot and don't want to fix, because it would make
QAnyStringView less versatile, but at one should at least be able to
overload QString and weak-QAnyStringView.
Change-Id: I5e5ae3c96060c93bfe070f6c19213328dae9c5f9
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
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>
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>
In commit 287ace562e, 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>
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>
Small change needed to make QString_char16 and QString_QChar return -1
in this case, but other combinations already returns -1.
[ChangeLog][QtCore][Behavior Change] QString::indexOf(QChar) and
QString::indexOf(char16_t) now treat a negative start-position, from,
bigger than the string's size as invalid. It previously
clipped such start-positions to the start of the string, inconsistently
with other QString indexOf overloads.
Change-Id: Ic56c8a558bf40a94845c649647db569892d4df02
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
tst_QStringList::sort() wants to use the C locale; but, if it failed,
it left that in force, since it only restored the prior locale on
success. It should also use C.UTF-8, since Qt now wants UTF-8.
Change-Id: If62e3d8da682081bf969075a719d03caebf09233
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
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>
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>
Ievgenii Meshcheriakov
Edward Welbourne
Ivan Solovev
Thiago Macieira
Giuseppe D'Angelo
Mårten Nordheim
Tor Arne Vestbø
Marc Mutz
Ulf Hermann