In tst_qlocale.cpp there was a #include that caused the static data
tables to be duplicated, violating ODR. All it actually needed was the
ability to iterate all rows of the locale_data[] table, so export a
method to do that from QLocaleData and have the test run that instead
of pulling in a second copy of the tables.
Conflict resolution at 6.8 needed the declaration of locale_data_size
moved up qlocale.cpp, which happened after 6.8 as part of other work
that isn't included in 6.8.
Pick-to: 6.5 6.2
Task-number: QTBUG-128930
Change-Id: Ie5ebdf508a622eeca93f8785bc09b086502aa0e2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 96c07655c46afdd3e2da7ef7d339b518d36c83c5)
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
We do have an implicit constructor which allows construction of a
QLocale from the QLocale::Language enum values. It will be used when
doing the comparison.
However, do not rely on the implicit conversions, and provide the
operators that explicitly do the right thing. This also allows us to
save an extra allocation of QLocalePrivate.
Found in Qt 6.8 API review.
Amends 71bbc35a37.
As a drive-by: fix the order of the test slots in the unit test.
Change-Id: I37f8f5881469b7734705e06e471746814dd2ddf0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 403b1abcad5f437c51dfabd7095b814e99e197a1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Methods with preconditions can't be noexcept (from Marc in code
review).
[ChangeLog][QtCore][String Views] Added slice() methods to
Q{String,ByteArray,Latin1String,Utf8String,AnyString}View which work
like sliced() but modify the view they are called on.
Found in API review.
Task-number: QTBUG-99218
Change-Id: Ic8ef3085f7cfac86b8404fb28d491ca38ad121eb
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 8f68bd9e6353a42d3b71d893b27fec6bedced501)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Complements ab05e05f60253b9be615c09aa340ee75f2e5bcaf:
Strings: get rid of the last std::char_traits use
LLVM's libc++ became pedantic and insists on only accepting
instantiations for one of the standard Char types, so remove all uses of
it with a template parameter.
Complements dc2ae08e02.
which is:
QStringView: stop instantiating std::char_traits<QChar> and <uchar>
It's deprecated and will be removed with LLVM 19.
Amends b1ee49b465.
Fixes: QTBUG-128325
Task-number: QTBUG-126214
Task-number: QTBUG-122753
Pick-to: 6.7
Change-Id: I2c7fbe3c0f557e98e7edfffdb00b4cc71a6612ca
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
(cherry picked from commit b387537d3e9c35d9f112d4aa32ad71df5e5e9028)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
By using {QString,QByteArray}::begin() instead of data() (for const
objectst); both begin() methods, respectively [1], return nullptr for a
const null {QString,QByteArray}. Whereas data() returns &_empty if
QT5_NULL_STRINGS is defined.
[1] QByteArray::begin() since a116b2ddfc
QString::begin() since 287ace562e
[ChangeLog][QtCore][QLatin1StringView] Creation of QLatin1StringView
from QByteArray or QByteArrayView now preserves the origin's isNull()
status. This matches the behavior of creating a QUtf8StringView from
those types.
Change-Id: Icbdfe282e315c08ca6a17201bcd32c1a3bba8bf5
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 221d8fdfb14c16472267320f859105f1a3834952)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It's failing to produce output in reasonable time and blocking the CI.
Since this test is basically a syntax checker, it not being present for
WASM is not a great loss.
Task-number: QTBUG-128322
Change-Id: Ic49e7523af63d5819c13fffdd7a752534b77f0ab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit f414505eaac5c222fc6404b9cda24fec25f68a7a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
lastIndexOf will convert the `needle` to unsigned char, which is then
'upcast' to int, before we search. But the string itself was searched
using signed char, meaning any values with the signed bit set would
mismatch.
Add tests for indexOf and lastIndexOf.
Amends 4c12ae7e67
Fixes: QTBUG-128199
Change-Id: I0ce7d7d9741f21650ef6f0f012a94e00d84a0f02
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 7b1f3bdc503ea7aceacc9fa8d388d843f1d7b131)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The qsnprintf() function introduces even more platform variability
than std::snprintf(), so from now on, we're using only std::snprintf().
Task-number: QTBUG-127110
Change-Id: Ic81b2a760521d77442cc328d2cfa7659bba8b7e2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit b8a956c2d3f9c158594265eca89185bd2bc671e7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When converting a wildcard into a regexp, convert a series of
consecutive '*' tokens in just one '.*' (instead of a series of '.*').
The pattern matched is the same, but we reduce the effects of a
possible catastrophic backtracking. I'm not actually sure whether
PCRE optimizes this case out of its own or it doesn't; Perl appears
not to.
Change-Id: Ia83336391593d56cf6d8332c96649a034a83a15b
Fixes: QTBUG-127672
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit a041cd35214e57a189aaa1f1f77199ff42303f83)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They were lacking it since the start of the public history, and
porting to std::snprintf() (which has the warning) as part of making
Qt compile with QT_NO_SNPRINTF has turned up surprisingly many
-Wformat warnings, so enable the warning for the remaining (non-tree)
users.
Backporting aggressively, as this might unearth security bugs in user
code.
[ChangeLog][QtCore][q(v)snprintf] Added attributes for GCC-compatible
compilers to detect format/argument mismatches. If this throws warnings
for your calls now, don't ignore them. printf() format mistakes could
be security-relevant. You may also find that you relied on undocumented
behavior, such as that certain implementations (Windows, Android, WASM)
of qsnprintf() support char16_t* instead of wchar_t* for %ls. In that
case, you should port to qUtf16Printable() and QString::asprintf(), or
suppress the warning and port away from the platform dependence at your
earliest convenience.
Task-number: QTBUG-127110
Pick-to: 6.7 6.5 6.2 5.15
Change-Id: I5c1fd9b2d5d2d55c68773f33edfd76acacd2408c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
(cherry picked from commit 64416d3cf645187385d8ad90bc44d9c8e9ce864f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
... it is. Filed QTBUG-125730 to track this and discuss how to deal
with it.
Pick-to: 6.7 6.5 6.2
Task-number: QTBUG-125730
Change-Id: I2c680e1a9e8dda43700468a544ac645e1fa3aa53
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 3ff55648cee8365fb7825ca7a038596b63757ea3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This was in fact present in v44, but we overlooked it somehow. The new
version also fixes some inconsistencies in the data, that I reported
against v44.1; in particular, Tamil no longer claims to override the
root AM/PM markers (probably because it uses 24-hour time so doesn't
need them).
Add the test-file under util to the list of files containing generated
content.
Conflict at 6.8 resolved by regenerating the data; this only changed
the date of generation, not the data. Then hand-edited the date to
match the picked upstream commit, to avoid future conflicts.
[ChangeLog][Third-Party Code] Updated CLDR data, used by QLocale, to
v45.
Task-number: QTBUG-126060
Pick-to: 6.7 6.5 6.2
Change-Id: I81a5bcca49519b55091fc541de6b73b606661bb4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit f79548e268a496698d77d0e78365334d0e507212)
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The build on Android with clang results in a bunch of irrelevant
warnings. Disable them for the offending lines of test code.
Change-Id: Ica5d867e3a2b1215dc526cc5f945a39ac908ac23
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 8d523a098cc8068400a6138970c6382f8f56224c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The "many-0 max dec" tests check if a large number (512) of leading zeros
interferes with parsing the number.
The std::from_chars implementation available on VxWorks cannot handle
strings longer than 255 characters.
The number is properly parsed, but the ptr returned as a part of the
std::from_chars_result does not contain the correct result.
It should point to the end of the string (as there is nothing left after the
number), but it wraps and starts to point to other places.
This leads to a wrong value returned by qstrnto(u)ll and to a failing
test.
The issue has been acknowledged by WindRiver. For now, blacklist the
"many-0 max dec" tests.
Pick-to: 6.7
Task-number: QTBUG-115777
Change-Id: I0a897728c71503e6817c69f8ced8ebb0a45295af
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit aea27282b783059ef52e928e811029cedb98ebf9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Strictly speaking, we did want to compare pointers, but char* are
special with QCOMPARE in that the pointed-to strings are compared, not
the pointers. So this wasn't doing what we wanted it to do.
We could static_cast to void* to do it, but subtracting one from the
other also gets us what we want, with simpler code. The drawback is that
if appendToBuffer() ever returns nullptr, we'll print a huge number as
the offset.
Found by Valgrind:
==3769588== Conditional jump or move depends on uninitialised value(s)
==3769588== at 0x483FEDC: strcmp (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==3769588== by 0x4C41EB6: qstrcmp(char const*, char const*) (in lib/libQt6Core.so.6.9.0)
==3769588== by 0x48975D8: QTest::compare_string_helper(char const*, char const*, char const*, char const*, char const*, int) (in lib/libQt6Test.so.6.9.0)
==3769588== by 0x12B12A: QTest::qCompare(char*, char*, char const*, char const*, char const*, int) (in tests/auto/corelib/text/qstringconverter/tst_qstringconverter)
==3769588== by 0x10EE94: tst_QStringConverter::invalidConverter() (in tests/auto/corelib/text/qstringconverter/tst_qstringconverter)
Amends c46ee7df57.
Pick-to: 6.7 6.5 6.2
Fixes: QTBUG-126107
Change-Id: I44265a5eb67e47a59fc8fffd17d64051657af529
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 9d5611dc97979dab1932b07f8cfab367c3872d24)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Found more issues:
- quint8 and qint8 (signed and unsigned char) actually match an
integral overload (probably int/uint), and _not_ (char),
- char8_t (only in C++20 builds) and (at least on non-Windows) wchar_t
are incorrectly treated as numeric types,
- qfloat16 breaks if QFLOAT16_IS_NATIVE.
Created a few tasks to track these.
Task-number: QTBUG-126053
Task-number: QTBUG-126054
Task-number: QTBUG-126055
Pick-to: 6.7 6.5 6.2
Change-Id: Iaf64929e3fae257d5dd283f555bb71ea2908cc94
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 967736b96ba06bfdfdf553b2c3720d7adc4a921c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This exercise found an inconsistency involving char16_t. Filed
QTBUG-125588 to keep track of this and decide how to deal with it.
Task-number: QTBUG-125588
Pick-to: 6.7 6.5
Change-Id: I259fecef34539e8841149570d7411d959b48d876
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Extending the fromCharacter() tests to check for the construction to
be noexcept and implicit turned up a few bugs:
The constructor from char32_t was simply not marked as noexcept, even
though all its operations were. So just mark it noexcept.
The constructor from QChar, otoh, was never called, (certainly not for
rvalues), because QString happens to be constructible from QChar (and
QLatin1Char and QChar::SpecialCharactor), so due to perfect
forwarding, the if_convertible_to<QString> ctor won, allocating a
QString.
This is a regression of Qt 6.5 compared to Qt 6.4.
To fix this, exclude arguments that convert to QChar from matching the
if_convertible_to<QString/QByteArray> ctors, taking care to not match
those arguments that are already compatible_char<>s.
This, in turn, creates a problem for implicit QASV construction from
QLatin1Char and QChar::SpecialCharacter, because now that we've
excluded them from the if_convertible_to<QString> ctor, calling the
existing QChar or QString non-template constructors for these types
would require two user-defined conversions (from said type to
QChar/QString and from QChar/QString to QAnyStringView). That works
for explicit construction, but we need implicit convertability.
So bring out the big guns once more and add a perfectly-forwarding
ctor for anything convertible to QChar. QChar itself is actually
already handled by compatible_char<>, so the old QChar non-template
ctor can go. The extra copy of the QChar argument will be optimized
away by the compiler.
[ChangeLog][QtCore][QAnyStringView] Fixed a regression where
constructing a QAnyStringView from a char-like type (QChar,
QLatin1Char, ...) would first construct a QString and only then
convert that to QAnyStringView.
Amends 812a0d3125.
This change is forward and backward BC and SC, but not
behavior-compatible: certain operations detectably change
noexcept'ness, and some arguments may now cause the resulting
QAnyStringView to have a different encoding (though I really tried
hard to avoid that).
Since it's a regression, I proposed to pick this to the affected
branches, 6.7 and 6.5 (6.6 is already closed at this point).
Pick-to: 6.7 6.5
Fixes: QTBUG-125735
Change-Id: I86f37df5d80bee36db27e529c017cb73995a6831
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These were not covered by the existing tests.
Pick-to: 6.7 6.5 6.2
Change-Id: I909ea3aa5b676904dc72ecf8ce32b73cca1b6af7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Add missing checks for integral overloads uint, short and ushort and
character overloads char and char16_t (the latter being a reproducer
for QTBUG-125588).
Pick-to: 6.7 6.5 6.2
Task-number: QTBUG-125588
Change-Id: I479e4c8c3cd86c3f85ab3c9d44b79158b0a48476
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Move the constexpr fromArray() check from fromArray() to constExpr()
and there add the protection necessary to work around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962, copied from
tst_QByteArrayView.
As a drive-by, add the test for constexpr construction from a char16_t
array, which was missing here (probably because of the GCC bug) while
the corresponding test was already in tst_QByteArrayView.
Amends 107ff4c1d6b5da2cb11c65b2bd9106817f7fdb02(!).
(iow: 6.0, and no, I don't know why it became a problem only now)
Pick-to: 6.7 6.5 6.2
Change-Id: Id9d2a08175709f8bf85b3b192e7aa49783b9e715
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Move the constexpr fromArray() check from fromArray() to constExpr()
where there is already the protection necessary to work around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962.
Amends bbe7570ddcc6fcce707a355b76d2d0024c44ea38(!).
(iow: 6.0, and no, I don't know why it became a problem only now)
Pick-to: 6.7 6.5 6.2
Change-Id: Id9d2a08175709f8bf85b3b192e7aa49783b9e714
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962, and
because marking constExpr() as __attribute__((no_sanitize_undefined))
doesn't fix a thing, we opted to disable the triggering parts of
constExpr() from all GCC builds.
This is, of course, unfortunate, since it meaningfully reduces
compile-time coverage in the general case for a rather obscure build
type most won't ever use.
While GCC doesn't give us a predefined macro to check for in the .cpp
file, the cmake build system knows whether we use ubsan, so just
define a macro of our own.
As a drive-by, simplify GCC detection by using Q_CC_GCC_ONLY.
Amends de6a004bc5.
Pick-to: 6.7 6.5 6.2
Task-number: QTBUG-101307
Change-Id: I4be5bd103b9d2386b2ac9fd22e0c34f9c63fee04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Overload set to be used in QUuid soon.
Pick-to: 6.7 6.5
Change-Id: I6f2c180bb7bb884d40f1691409e816405c3e5d47
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Since commit 91e70f23 introduced separator to uiLanguages(), the system
locale id still does not respect the separator parameter and hardcodes
dash as separator. Fixing this should make the format consistent.
Pick-to: 6.7
Change-Id: I1ab8edfa49117bdc9c4353228e73c2d1e5becffc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Moody Liu <mooodyhunter@outlook.com>
... mirroring the same change in QLatin1StringMatcher.
Task-number: QTBUG-117054
Change-Id: I8d1f4ed01ee75a51e3d99a165dbb35ae7dae5886
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Now developer build tests compile, but some are not working.
Functional fix will come later via separate tasks.
Task-number: QTBUG-122999
Change-Id: I70487b46c1b32ba4279cb02a4978e4f55ac0d310
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace class operators operator==(), operator!=() of
QRegularExpression to friend method comparesEqual() and
Q_DECLARE_EQUALITY_COMPARABLE macro.
Use QT_CORE_REMOVED_SINCE and removed_api.cpp to get rid of
current comparison methods and replace them with a friend.
Task-number: QTBUG-120304
Change-Id: Ib6fc83d29ad9bc710c2fdf32a3d60131fbf298b6
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Replace public friend operators operator==(), operator!=() of
QLocale to friend method comparesEqual() and
Q_DECLARE_EQUALITY_COMPARABLE macro.
Task-number: QTBUG-120304
Change-Id: I759ef08269abe3b40e0dce3fd408a86cc3f34857
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The QRegularExpression capture-by-name keys are currently QStringViews,
but are only ever used to compare them against a const char16_t*, so
this API is a perfect candidate for replacing all of these overload sets
with a single QAnyStringView function.
[ChangeLog][QtCore][QRegularExpression] Keys can now be passed as
QAnyStringView (was QStringView).
Fixes: QTBUG-103097
Change-Id: I1a80e85f301cc08370d70b3b5eb0ae10c6a51f33
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
I neglected to update the CLDR dateconverter code when I expanded the
range of forms we support for display of a timezone. Even that
expanded range doesn't cover all the cases CLDR does, but we can at
least approximate each of CLDR's options by the closest we do support.
Make matching changes to how the Darwin backend for the system locale
maps its ICU-derived formats to ours.
This in practice changes all locales previously using t (abbreviation)
as zone format to use tttt (IANA ID) instead. Test data updated to
match.
[ChangeLog][QtCore][QLocale] Date-time formats now more faithfully
follow the CLDR data in handling timezones. In most cases this means
the IANA ID is used in place of the abbreviation.
Change-Id: I0276843085839ba9a7855a78922cffe285174643
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There was a discrepancy that the multi-arg arg() overload would accept
any number of digits in the placeholder, resolving up to value 999
(e.g., %000001 was interpreted as placeholder #1), but the single-arg
arg() overload only supported exactly one or two digits. The single-arg
behavior was documented, so use it.
[ChangeLog][Important Behavior Changes] The QString::arg() overload
taking multiple QString-like arguments is now fixed to interpret
placeholders like the other arg() overloads: it will find at most two
digits after the '%' character. That is, the sequence "%123" is now
interpreted as placeholder #12 followed by character '3' (verbatim).
Pick-to: 6.7
Fixes: QTBUG-118581
Change-Id: I455fe22ef4ad4b2f9b01fffd17c767a948d41138
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Both qlocale_mac.mm and dateconverter.py were mapping the CLDR am/pm
indicator, 'a', to the Qt format token 'AP', forcing the indicator to
uppercase. The LDML spec [0] says:
May be upper or lowercase depending on the locale and other
options.
[0] https://www.unicode.org/reports/tr35/tr35-68/tr35-dates.html#Date_Field_Symbol_Table
We don't support the "other options" mentioned, but we can at least
(since 6.3) preserve the the locale-appropriate case, instead of
forcing upper-case. As such, this change is a follow-up to
commit 4641ff0f6a
Changes locale data, as expected, to use "Ap" in place of "AP" in
various formats in the time_format_data[] array.
[ChangeLog][QtCore][QLocale] Where CLDR specifies an am/pm indicator,
the case of the CLDR-supplied indicator is used, where previously
QLocale forced it to upper-case.
Change-Id: Iee7d55e6f3c78372659668b9798c8e24a1fa8982
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The LDML spec includes a 'b' pattern character which is like the 'a'
pattern, for AM and PM, but would rather use noon and midnight
indicators for those specific times. We don't support those and using
am/pm will be right enough of the time to be better than simply
discarding this option, if it ever gets used (which it currently
isn't), so treat as an alias for 'a'. No locale in CLDR currently uses
this.
CLDR also has a 'B' specifiers for "flexible day periods", including
things like "at night" and "in the day". At present only zh_Hant uses
'B'. As a result, this change only affects zh_Hant's formats for time
and datetime, which only zh_Hant_TW uses - zh_Hant_HK overrides them
to use am/pm markers and zh_Hant_MO inherits that from
zh_Hant_HK. Based on this and user feed-back, I've opted to treat 'B'
as another synonym of 'a'.
This removes an entry from the time_format_data[] table (it happened
to occupy one whole twelve-character row), causing many other locales'
offsets into that table to be shifted by 12. Only zh_Hant_TW has an
actual change to which entry in the table it uses.
Added a test-case.
[ChangeLog][QtCore][QLocale] CLDR's 'B' (flexible day period, e.g. "at
night" &c.) field, not currently supported, is now handled as a
synonym for the AM/PM field 'a', instead of leaving the B as literal
text. Only affects zh_TW at present.
Fixes: QTBUG-123872
Change-Id: I6ba008c0a048190bf7af8c7df7629a885b05804f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Pass the pointer to the current state, not a pointer to a pointer to it.
[ChangeLog][QtCore][QStringConverter] Fixed a bug involving moved
QStringEncoder/QStringDecoder objects accessing invalid state.
Amends 122270d6be.
Done-with: Marc Mutz <marc.mutz@qt.io>
Pick-to: 6.7 6.5
Change-Id: I70d4dc00e3e0db6cad964579662bcf6d185a4c34
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QVariant is rather big for passing by value; and no caller has any
further use for the QVariant it's passing in.
Pick-to: 6.7 6.5
Task-number: QTBUG-122619
Change-Id: I2751745e715aacfa8982ac97b4ae777fde5e88de
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Axivion (SV546) points out (based on a clazy "rule of three" that
might be rule of five by now) the lack of move and copy assignment and
construction. We don't want those anyway, so tell the compiler not to
create them.
Pick-to: 6.7 6.5
Task-number: QTBUG-122619
Change-Id: Ie951a2c3d60d76ad3448310d3f9bbda22190015b
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Wrap the call in QVERIFY.
tst_QTextStream::read0d0d0a was also faulty as it *never* opened
the file because of a broken path. Fix it with QFINDTESTDATA.
Change-Id: I61a8f83beddf098d37fda13cb3bfb4aaa4913fc5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Because they always were, but we never tested it.
Change-Id: I503c65ed41b90d710c651d879a4477965f2ef0d6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Check that all string-like types implement compareThreeWay() as a
(hidden) friend function.
This test revealed some problems: because QByteArrayView is implicitly
constructible from QLatin1StringView, the qCompareThreeWay() call
sometimes picked the compareThreeWay() overloads with QByteArrayView
instead of picking the "reversed" overloads that use QLatin1StringView.
This was leading to wrong results, because QByteArrayView is
interpreted as utf-8 data, not latin-1.
Explicitly add the missing compareThreeWay() and comparesEqual()
overloads.
Note that relational operators were never affected by this problem,
because in C++17 mode we explicitly generate the reversed versions,
and in C++20 mode the compiler does that for us.
Task-number: QTBUG-117661
Change-Id: Ia96af59c60ebf2fae6cf2a49231d6b6f401aceaa
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This reverts commit c23d3ca1f0.
Reason for revert: Update to Emscripten 3.1.50 has been merged.
Change-Id: Ie2082dcc2ee34a6d4e519c143037fda9678be234
Reviewed-by: Even Oscar Andersen <even.oscar.andersen@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Then we will automatically handle invalid leading characters instead
of throwing away the whole sequence when it cannot be converted.
Added a test that was failing before.
Drive-by change: add a comment explaining why we
have the stack allocated buffer.
Task-number: QTBUG-118834
Change-Id: I647a58f2ba95e2e7ed4ea6a964d99ecc0c91fad3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Edward Welbourne
Mårten Nordheim
Ivan Solovev
Ahmad Samir
Thiago Macieira
Marc Mutz
Giuseppe D'Angelo
Volker Hilsheimer
Albert Astals Cid
Łukasz Matysiak
Tatiana Borisova
Kirikaze Chiyuki
Jari Helaakoski
Matthias Rauter
Fabian Kosmale
Piotr Wierciński