The former messes in bad ways with the overload set (it, fatally,
attracts char16_t, e.g.). The latter was probably added in response to
ambiguities between (char) and (QChar). While it's harmless now,
remove it, since it no longer pulls its weight.
The no-ascii warning is now coming from QChar(char), so the protection
isn't lost.
[ChangeLog][QtCore][QString] The += operators taking char and
QChar::SpecialCharacter have been removed as they cause adding a
char16_t to QString to call the char overload, losing information. The
append() function was not affected.
Change-Id: I57116314bcc71c0d9476159513c0c10048239db3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The fromUtf16(ushort*) and fromUcs4(uint*) overloads are going
to be deprecated. Use the newer fromUtf16(char16_t*) and
fromUcs4(char32_t*) overloads.
As a drive-by, use std::end()/std::size() where applicable.
Change-Id: I5a93e38cae4a2e33d49c90d06c5f14f7cb7ce90c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We don't rely on a latin1 locale anymore for the test,
and the other code was not doing anything.
Change-Id: I08bc08d200c9e037884d8b680dfbb24c129f3d2e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
[ChangeLog][QtCore][QString] Now supports appending, prepending
and inserting QStringViews.
Change-Id: I7538c050c67590f27d91443eda0b94a4b80b62f2
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We should not implicitly convert a QString to a QLocale object. It can
easily create unwanted side effects.
Change-Id: I7bd9b4a4e4512c0e60176ee4d241d172f00fdc32
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This is a follow-up to commit 895939c7f9
to fix deprecation warnings it added.
Change-Id: I3d86655ec2c84c1bdcac9c70436075fc78f2f781
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QUtf32::convertToUnicode() was forgetting to set headerdone when it
dealt with the header (for contrast, Utf16::convertToUnicode() does).
Fixes: QTBUG-62011
Change-Id: Ia254782ce0967a6cf9ce0e81eb06d41521150eed
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
It was more complex than it needed to be and was a test of QString,
not of QLocale. This leaves tst_QLocale::negativeZero() available to
now test how QLocale handles negative zero.
Change-Id: Ic9aae250c29f579e6d60fba8404b38673a3b489f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Use QStringIterator rather than indexed loops. This fixes handling of
non-BMP code points (which may be lower or uppercase, see the test).
Change also the semantics of the functions, adopting Unicode §3.13
definitions: a string is lowercase/uppercase if it's equal to its
own toLower/toUpper folding.
As a side effect, empty strings are now correctly reported to be
lowercase AND uppercase.
[ChangeLog][Important Behavior Changes] The semantics of
QString::isLower() and QString::isUpper() have been changed to match the
Unicode specification. Now lowercase (resp. uppercase) strings are
allowed to contain any character; a string is considered lowercase
(resp. uppercase) if it's equal to its own toLower() (resp. toUpper())
folding. Previously, a non-letter character would make the string not
lowercase nor uppercase, and the mere presence of an uppercase (resp.
lowercase) letter would make isLower() (resp. isUpper()) return false,
even if the letter wouldn't change under case folding. As a
consequence, now empty strings are lowercase and uppercase.
[ChangeLog][QtCore][QString] Fixed a number of bugs of
QString::isLower() and QString::isUpper(). Empty strings are now
correctly reported to be lowercase (resp. uppercase), and strings
containing code points outside the BMP are now correctly handled.
Note that the behavior of these functions has also been changed.
Change-Id: Iba1398279a072399a9f21295fe75f6e414f3f813
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Conflicts:
src/corelib/tools/qvector.h
Make QVector(DataPointer dd) public to be able to properly merge
5b4b437b30 from 5.15 into dev.
src/widgets/kernel/qapplication.cpp
tests/auto/tools/moc/allmocs_baseline_in.json
Done-With: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Change-Id: I929ba7c036d570382d0454c2c75f6f0d96ddbc01
QString(View)s can be built or manipulated in ways that make them
contain/refer to improperly encoded UTF-16 data. Problem is,
we don't have public APIs to check whether a string contains
valid UTF-16. This knowledge is precious if the string is to be fed in
algorithms, regular expressions, etc. that expect validated input
(e.g. QRegularExpression can be faster if it can assume valid UTF-16,
otherwise it has to employ extra checks).
Add a function that does the validation.
[ChangeLog][QtCore][QStringView] Added QStringView::isValidUtf16.
[ChangeLog][QtCore][QString] Added QString::isValidUtf16.
Change-Id: Idd699183f6ec08013046c76c6a5a7c524b6c6fbc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We're now using the same infrastructure for QVector,
QString and QByteArray.
This should also make it easier to remove the shared null
in a follow-up change.
Change-Id: I3aae9cf7912845cfca8e8150e9e82aa3673e3756
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Preparations to move QString over to use QArrayDataPointer instead
of it's own private struct.
Change-Id: I7796a595393394083f6a85863e3c710ebbdea149
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We already detach immediately since change
c2d2757bcc. That basically removes
the main purpose of having QChar/ByteRef, and we can just as well
get rid of those classes for Qt 6.
Change-Id: I8dc566a1948ddc29c0cb8a77ec7310654a7219a4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
I'd have preferred to use QArrayDataPointer<ushort> for QString, but
that option wasn't the best one. QArrayDataPointer try to do some
operations using QArrayDataOps and that would expand to unnecessary
code. What's more, the existing code expected to be able to modify and
access the d pointer.
Instead, this commit introduces QStringPrivate (named differently from
QStringData to catch potential users), which contains the three
members. This POD class is also used in QJsonValue to store the
"inlined" QString. QHashedString in qtdeclarative will need a similar
solution.
Change-Id: I33f072158e6e2cd031d4d2ffc81f4a8dbaf4e616
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The next change will stop using some values in the reference counter as
settings from the data.
Change-Id: I94df1fe643896373fac2f000fff55bc7708fc807
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The qmake config for tst_QString tried to impose QT_NO_CAST_TO_ASCII
on it, but the source file explicitly #undef-s this symbol and its
friends. Leave the define commented out in the .pro so that a comment
can explain why it's no good.
Change-Id: I7620f4e104f0cdab05fdc246b903c40026e63d76
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Test QT_CONFIG(icu) in the code instead of testing qtConfig(icu) in
the profile and setting an extra define just to shadow what's already
defined. Also remove the matching define from qcollator.pro, whose
test code didn't use it.
Noticed while reviewing the conversions to CMake.
Change-Id: I19d3b1026b2a8f50ec424c450614e721500fd38a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
QString::fromAscii() is deprecated since 5.0 but still tested.
So suppress deprecations for its code.
Change-Id: Ic048a843c43551021da39a16d94c3222201573dc
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Now that all our supported compilers know char16_t, we no longer need
QStringViewLiteral, whose only purpose in life was to turn u"" into
L"" for MSVC < 2015.
Change-Id: I25a094fe7992d9d5dbeb4a524d9e99e043dcb8ce
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
