Document QStringConverter, QStringDecoder and QStringEncoder.
In addition, do some touches to the API, renaming one enum value,
add a flags argument to one constructor and make some members private.
Change-Id: I8f99dc3d98fb8860cf6fa46301e34b7eb400511b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is a replacement for Qt::codecForHtml().
Change-Id: I31f03518fd9c70507cbd210a8bcf405b6a0106b1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add method that tries to determine the encoding of the data
from an initial byte order mark.
Change-Id: I348c51a3d4db9b434af53359b739a7e17acfc760
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add static methods that allow converting between a name for an
encoding and the Encoding enum.
Change-Id: I12bc503cf757ea31d3ca8d5e1f1216efddcb16d4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add a constructor, that allows constructing a string converter by
name. This is required in some cases and also makes it possible to
(in the future) extend the API to 3rd party encodings.
Also add a name() accessor.
Change-Id: I606d6ce9405ee967f76197b803615e27c5b001cf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Feed the data one by one to the encoder or decoder to
verify that the handling of incremental decoding is
correct.
Change-Id: I565e4f1872e00859026334f7662b6778772e159d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
IgnoreHeader was a rather badly defined enum, in addition the
utf8 and utf16 codecs where handling BOMs somewhat different
for stateless decoding.
Fix this by introducing explicit flags for writing a bom when
encoding and not skipping the initial bom when decoding.
Source compatibility for QTextCodec is done with a couple of
static constexpr variables.
Change-Id: I0b2d94f84c937cec1e0494c16ef448c00382691d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The new QStringEncoder and QStringDecoder classes
(with a common QStringConverter base class) are
there to replace QTextCodec in Qt 6.
It currently uses a trivial wrapper around the utf
encoding functionality.
Added some autotests, mostly copied from the text codec
tests.
Change-Id: Ib6eeee55fba918b9424be244cbda9dfd5096f7eb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
The fromUcs2() named ctor is designed to replace all the non-char
integral-type constructors of QChar which make it very hard to control
the implicit QChar conversions, which have caused a few bugs in Qt
itself. As a classical named contructor, it simply returns QChar.
The fromUcs4() named "ctor", however, needs to expand surrogate pairs,
and thus can't just return QChar. Instead, it returns a small struct
that contains one or two char16_t's, can be iterated over and be
implicitly converted to QStringView. To avoid bikeshedding the name
(FromUcs4Result, of course :), it's defined inline and thus can't be
named outside the function. This function replaces most uses of
QChar::requiresSurrogates() in QtBase.
[ChangeLog][QtCore][QChar] Added fromUcs2(), fromUcs4().
Change-Id: I803708c14001040f75cb599e33c24a3fb8d2579c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
wchar_t hasn't been QStringView's storage_type for a very long time
(at least since 5.10). And in Qt 6, we require char16_t support not
only in the compiler, but also in the stdlib, so drop the guards and
the alternative code paths.
Change-Id: I99f28b575f61c16a2497840708beaa4b54a80f57
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
They don't work with std::span, since std::span has neither
const_iterator nor cbegin()/cend().
To fix, perfectly forward the return type with decltype(auto) instead
of mentioning T::const_iterator, and rely on the const-qualfication of
the help::c{r,}{begin,end}() functions' arguments to select the
correct T::{r,}{begin,end}() overload.
Change-Id: I4992d4bd521d2dc0f9ea51ae70cde8286ae543a5
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It clearly belonged in tst_QDate::toDateTime(), for which it adds a
few more test-case and in which it inspires some further testing.
The new testing of case-insensitivity doesn't work if the format
contains stray non-format characters, so added a new data column to
take care of that.
Pick-to: 5.15
Change-Id: I73619be02091c97024a84cb963c7029e9fd0569a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
This is a follow-up to commit ed2b110b6a
to fix indexing errors. Added the test that should have accompanied
that commit, which found some bugs, and refined the Indian number
formatting test (on which it's based).
Make variable i in the loops that insert grouping characters in a
number be consistently a *character* offset - which, when each digit
is a surrogate pair, isn't the same as an index into the
QString. Apply the needed scaling when indexing with it, not when
setting it or decrementing it. Don't assume the separator has the same
width as a digit.
Differences in index no longer give the number of digits between two
points in a string, so actively track how many digits we've seen in a
group when converting a numeric string to the C locale. Partially
cleaned up the code for that in the process (more shall follow when I
sort out digit grouping properly, without special-casing India).
Change-Id: I13d0f24efa26e599dfefb5733e062088fa56d375
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Conflicts:
examples/opengl/doc/src/cube.qdoc
src/corelib/global/qlibraryinfo.cpp
src/corelib/text/qbytearray_p.h
src/corelib/text/qlocale_data_p.h
src/corelib/time/qhijricalendar_data_p.h
src/corelib/time/qjalalicalendar_data_p.h
src/corelib/time/qromancalendar_data_p.h
src/network/ssl/qsslcertificate.h
src/widgets/doc/src/graphicsview.qdoc
src/widgets/widgets/qcombobox.cpp
src/widgets/widgets/qcombobox.h
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
tests/auto/widgets/widgets/qcombobox/tst_qcombobox.cpp
tests/benchmarks/corelib/io/qdiriterator/qdiriterator.pro
tests/manual/diaglib/debugproxystyle.cpp
tests/manual/diaglib/qwidgetdump.cpp
tests/manual/diaglib/qwindowdump.cpp
tests/manual/diaglib/textdump.cpp
util/locale_database/cldr2qlocalexml.py
util/locale_database/qlocalexml.py
util/locale_database/qlocalexml2cpp.py
Resolution of util/locale_database/ are based on:
https://codereview.qt-project.org/c/qt/qtbase/+/294250
and src/corelib/{text,time}/*_data_p.h were then regenerated by
running those scripts.
Updated CMakeLists.txt in each of
tests/auto/corelib/serialization/qcborstreamreader/
tests/auto/corelib/serialization/qcborvalue/
tests/auto/gui/kernel/
and generated new ones in each of
tests/auto/gui/kernel/qaddpostroutine/
tests/auto/gui/kernel/qhighdpiscaling/
tests/libfuzzer/corelib/text/qregularexpression/optimize/
tests/libfuzzer/gui/painting/qcolorspace/fromiccprofile/
tests/libfuzzer/gui/text/qtextdocument/sethtml/
tests/libfuzzer/gui/text/qtextdocument/setmarkdown/
tests/libfuzzer/gui/text/qtextlayout/beginlayout/
by running util/cmake/pro2cmake.py on their changed .pro files.
Changed target name in
tests/auto/gui/kernel/qaction/qaction.pro
tests/auto/gui/kernel/qaction/qactiongroup.pro
tests/auto/gui/kernel/qshortcut/qshortcut.pro
to ensure unique target names for CMake
Changed tst_QComboBox::currentIndex to not test the
currentIndexChanged(QString), as that one does not exist in Qt 6
anymore.
Change-Id: I9a85705484855ae1dc874a81f49d27a50b0dcff7
The name of the option may cause confusion due to the fact
that it's not _fully_ anchoring the match, only anchoring it
at the offset passed to match() -- in other words, it's a
"left" anchoring. Deprecate the old name and introduce
a new one that should explain the situation better.
[ChangeLog][QtCore][QRegularExpression] The AnchoredMatchOption
match option has been deprecated in favor of
AnchorAtOffsetMatchOption, which should better describe
that the match is only anchored at the offset.
Change-Id: Ib751e5e488f2d0309a2da6496378247dfa4648de
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
In particular, this changed the US currency formats for negative
amounts to be parenthesised versions of the positive amount forms,
rather than having a minus sign after the $ sign. Test updated.
[ChangeLog][QtCore][QLocale] Currency formats are now based on CLDR's
accounting formats, where they were previously mostly based (more or
less by accident) on standard formats. In particular, this now means
negative currency formats are specified, where available, where they
(mostly) were not previously.
Task-number: QTBUG-79902
Change-Id: Ie0c07515ece8bd518a74a6956bf97ca85e9894eb
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@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>
The call of _control87 would crash because of the previous test.
Change-Id: I254efe9c2e9892a473a02663e5ff7016791d5d6d
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
Include WordBreakTest.html, since a test uses sample strings from it,
albeit without actually reading the file.
Had to comment out more of the new tests, as at Revision 24, pending
an update to harfbuzz and the text boundary detection code.
Task-number: QTBUG-79631
Task-number: QTBUG-79418
Task-number: QTBUG-82747
Change-Id: I0082294b09d67ffdc6a9b5c15acf77ad3b86f65f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
No surprises, as char16_t is transparently handled by QChar overloads.
Ok, one surprise: we seem to have QChar <> QByteArray relational
operators, but they don't work for char16_t. Probably members of
QChar, so LHS implicit conversions are disabled. Didn't investigate,
because it needs to be fixed at some point anyway, but that point is
not now.
Change-Id: I74e1c9bdd168e6480e18d7d86c1f13412e718a32
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
... to not fold QChar tests into QString ones.
This is needed for adding char16_t tests.
Change-Id: I2507d7d68a39ff96cf033eadde10e383dc976dda
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In QByteArray, they were just not marked as such.
In QString and QStringRef, the implicit conversion from QChar to
QString would destroy it. Add a QChar overload, delegating to
QStringView.
Added docs for the new overloads, copying from the nearest neighbor so
as to not look out of place. All string classes use different wording
for these functions. A cleanup of this state of affairs is out of the
scope of this patch.
Change-Id: I0b7b1d037aa229bcaf29b793841a18caf977d66b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@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>
The Qt version was added in 5.14 "for use as eventual replacement for
QString::SplitBehavior." Move another step closer to that goal.
Change-Id: I446f9ddc8f8de4a0b79b09edb44f7c1496fbc33f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Extract the character in its proper unicode form and encode it in a
new single_character_data table of locale data. Record each entry as
the range within that table that encodes it. Also added an assertion
in the generator script to check that the digits CLDR gives us are a
contiguous sequence in increasing order, as has been assumed by the
C++ code for some time. Lots of number-formatting code now has to take
account of how wide the digits are.
This leaves nowhere for updateSystemPrivate() to record values read
from sys_locale->query(), so we must always consult that function when
accessing these members of the systemData() object. Various internal
users of these single-character fields need the system-or-CLDR value
rather than the raw CLDR value, so move QLocalePrivate's methods to
supply them down to QLocaleData and ensure they check for system
values, where appropriate first.
This allows us to finally support the Chakma language and script, for
whose number system UTF-16 needs surrogate pairs.
Costs 10.8 kB in added data, much of it due to adding two new locales
that need surrogates to represent digits.
[ChangeLog][QtCore][QLocale] Various QLocale methods that returned
single QChar values now return QString values to accommodate those
locales which need a surrogate pair to represent the (single
character) return value.
Fixes: QTBUG-69324
Fixes: QTBUG-81053
Change-Id: I481722d6f5ee266164f09031679a851dfa6e7839
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
Conflicts:
tests/manual/rhi/hellominimalcrossgfxtriangle/CMakeLists.txt
Hopefully final merge from wip/cmake, and then all cmake changes
should target dev directly.
Change-Id: I29b04c9b0284e97334877c77a32ffdf887dbf95b
Conflicts:
examples/widgets/graphicsview/boxes/scene.h
src/corelib/Qt5CoreMacros.cmake
src/corelib/Qt6CoreMacros.cmake
src/network/ssl/qsslsocket.cpp
src/network/ssl/qsslsocket.h
src/platformsupport/fontdatabases/windows/qwindowsfontenginedirectwrite.cpp
src/testlib/CMakeLists.txt
src/testlib/.prev_CMakeLists.txt
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
Disabled building manual tests with CMake for now, because qmake
doesn't do it, and it confuses people.
Done-With: Alexandru Croitor <alexandru.croitor@qt.io>
Done-With: Volker Hilsheimer <volker.hilsheimer@qt.io>
Change-Id: I865ae347bd01f4e59f16d007b66d175a52f1f152
There were a few surprises:
- QByteArray::compare() are missing noexcept (will add)
- ibid., called with non-ascii content and CaseInsensitive fails
(this was discussed on the ML, with tentative agreement that
it's a feature, not a bug; waiting for QUtf8String(View) for a
fix, then).
- As was the case when we did this exercise with the relational
operators, QString(Ref)/QChar is not noexcept (will fix)
These have been QEXPECT_FAIL'ed.
Not much of the cartesian product is implemented at all, yet. These
have been #ifdef'ed with NOT_YET_IMPLEMENTED to see what's still
missing.
Change-Id: I7d9b21e292b98f980aacdc6248e88188f7472ba2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In tst_QLocale::windowsDefaultLocale(), we configure the long and
short date formats and the short time format eccentrically, then
verify that QLocale::system() does actually get these eccentric
formats. However, we did not configure the long time format (whose
MS-API name doesn't match that of the other formats), so had to rely
on a guess at the system locale's format. That, however, is not
robust; so now configure the long time format, too.
Removed a duplicated test, at the same time.
Fixes: QTBUG-36306
Change-Id: I04dc22c7eb1b58af55412b598873868f79e9c74f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Back-ends need to catch NULL data so as not to call system APIs with
invalid pointers.
[ChangeLog][QtCore][QCollator] Fixed a regression introduced in 5.14.0
that caused QCollator not to operate with default-constructed QStrings
and print a warning on Windows.
Fixes: QTBUG-81673
Change-Id: I2eafe1e188b436afcca3cf2ecdf98bba707c44c9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This pulls the CMake port, which not only adds CMake files but also
modifies existing code. A brief summary of "seemingly unrelated" changes:
* configure.json was re-formatted to not use multi-line strings. That
is an extension of the Qt JSON parser but not JSON compliant, which
is needed for the configure.json-to-cmake conversion script (python).
* Some moc inclusions were added due to CMake's slightly different way
of handling moc. With the changes the files build with qmake and cmake.
* Since CMake just grep's for the Q_OBJECT macro to determine whether to
call moc (instead of doing pre-processing like qmake), the existing use
of "Q_OBJECT" in our documentation was changed to \Q_OBJECT, which cmake
doesn't see and which is now a qdoc macro.
* QTestLib's qFindTestData was extended to also search in the source
directory known at build time.
What this change also brings is a new way of building modules in Coin by using
YAML configuration files that describe the steps of building and testing in Coin
specific terms. The platform configuration files in qt5 are instructed to use the
old Coin built-in way of testing ("UseLegacyInstructions" feature) but for any
configurations that do not have this, these yaml files in the coin/ sub-directory
are used and shared across repositories.
Change-Id: I1d832c3400e8d6945ad787024ba60e7440225c08
On macOS it's possible to configure the system locale to not do digit
grouping (separating "thousands", in most western locales); it then
returns an empty string when asked for the grouping character, which
QLocale's system-configuration then ignored, falling back on using the
base UI locale's grouping separator. This could lead to the same
separator being used for decimal and grouping, which should never
happen, least of all when configured to not group at all.
In order to notice when this happens, query() must take care to return
an empty QString (as a QVariant, which is then non-null) when it *has*
a value for the locale property, and that value is empty, as opposed
to a null QVariant when it doesn't find a configured value. The caller
can then distinguish the two cases.
Furthermore, the group and decimal separators need to be distinct, so
we need to take care to avoid cases where the system overrides one
with what the CLDR has given for the other and doesn't over-ride that
other.
Only presently implemented for macOS and MS-Win, since the (other)
Unix implementation of the system locale returns single QChar values
for the numeric tokens - see QTBUG-69324, QTBUG-81053.
Fixes: QTBUG-80459
Change-Id: Ic3fbb0fb86e974604a60781378b09abc13bab15d
Reviewed-by: Ulf Hermann <ulf.hermann@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>
We have long (since 4.5.1) coerced it to lower-case, for no readily
apparent, much less documented, reason. CLDR says most locales use an
upper-case E for this - let's actually use what CLDR says we should
use.
The code that matches the exponent separator was doing so
case-insensitively in any case; that needed adaptation now that the
separator's case isn't pre-determined; and, in any case, should have
been done using case-folding rather than upper-casing. In the process,
removed some spurious checks for "'e' or 'E'" in the result, since the
exponent separator is always represented by 'e' (and an 'e' might also
be present for the separate reason of its use as a beyond-decimal
digit representing fourteen).
[ChangeLog][QtCore][QLocale] QLocale::exponential() now preserves the
case of the CLDR source, where previously it was lower-cased.
Change-Id: Ic9ac02136cff79cb9f136d72141b5dbf54d9e0a6
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>
In the presence of multiple overloads of a function taking either
QString or QStringView, QStringView should always be preferred.
The rationale is that the QStringView overload may have been
added "later" (read: the function was written when QStringView
was not available yet, so it took QString), and the fact that
a function with the _same name_ offers a QStringView overload
implies the function never needed to store/own the string in
the first place.
Add a (compile-time) test for this preference. This is in
preparation for a future QString(char16_t*) constructor
(in Qt 5.15 / Qt 6).
Change-Id: I60a435e494b653548f8f8d52c5d7e7cac2cc875a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
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
When QLocale::Country is set to QLocale::India numbers are written so that
after first three from the right and then after every second will be comma.
E.g. 10000000 is written as 1,00,00,000
Task-number: QTBUG-24301
Change-Id: Ic06241c127b0af1824104f94f7e2ce6e2058a070
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Reviewed-by: Teemu Holappa <teemu.holappa@qt.io>
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>
The goal here is to move things over to QArrayDataPointer. This prepares
for it.
Change-Id: I32f54a47594274799600c618f7341c200ceaa306
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
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 Mutable flag now contains the information on whether the data this
QArrayData points to is mutable. This decouples the mutability /
immutability setting from the allocation and from the type of data,
opening the way for mutable raw or foreign data.
There are still plenty of places in the source code that check the
size of the allocation when it actually wants d->isMutable(). Fixing
this will require reviewing all the code, so is left for later.
The needsDetach() function is moved to QArrayData and
de-constified. It returns true when a reallocation is necessary if the
data is to be modified.
Change-Id: I17e2bc5a3f6ef1f3eba8a205acd9852b95524f57
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The test passed mostly by accident so far, as the created QByteArray
was shorter than what the test assumed.
Change-Id: I06858801d83a504eadc73ec2be281c88f8ffad5d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QByteArray::fromBase64 was liberal in its input, simply skipping
over invalid characters. As a side-effect of this, it had
no error reporting, meaning it could not be used to convert
fromBase64 _and_ validate the input in one go.
Add more option flags to make fromBase64 strictly validate
its input. Since we want to know whether it has succeeded
or not, and the existing fromBase64 overloads do not
allow for that, introduce a new function that returns
an optional-like datatype.
While at it: base64 decoding can be done in-place; add an
rvalue overload to enable this use case.
[ChangeLog][QtCore][QByteArray] Added the new fromBase64Encoding
function.
[ChangeLog][QtCore][QByteArray] Added new flags to make
fromBase64 / fromBase64Encoding strictly validate their input,
instead of skipping over invalid characters.
Change-Id: I99cd5f2230f3d62970b28b4cb102913301da6ccd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This was used to support QFlags f = 0 initialization, but with 0 used
as a pointer literal now considered bad form, it had been changed many
places to QFlags f = nullptr, which is meaningless and confusing.
Change-Id: I4bc592151c255dc5cab1a232615caecc520f02e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Allegedly Apple has fixed the bug that made this necessary, so we
should be able to include these two test-cases once more.
This reverts commit ba9585bd02.
Fixes: QTBUG-69875
Change-Id: I5ac6019c0d647691eda6cdbb2a53e7471859d4a3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The assumption when calling QStringRef::toString() on a null
QStringRef (i.e. when QStringRef::isNull() is true) is that
QStringRef::toString().isNull() will also return true. With the
current implementation we return a null QString() only when the
QStringRef references a nullptr QString. We need to do the same
also when QStringRef references a QString with null private data.
Change-Id: I4177a5ea187ae758d7c46fe76a9d0583140e90cb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Had to teach the update program to accept category Lm as for
Joining_Transparent, for the sake of a new ArabicShaping.txt entry.
Added three new Unicode versions, several new scripts and a new
word-break class.
Updated UCD's test data for tst_QTextBoundaryFinder. This left 57
tests failing; I have commented out the data rows for those tests,
pending someone with more knowledge addressing this.
Task-number: QTBUG-79631
Task-number: QTBUG-79418
Change-Id: Ic33d3b3551195d47a84d98e84020f57a68f0b201
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Released on October 4th.
Adds Windows names for two time zones, Qyzylorda and Volgograd.
Added languages Chickasaw (cic), Muscogee (mus) and Silesian (szl).
Norwegian number formatting has flipped back to using colon rather
than dot as time separator; it's flipped back and forth over the last
several CLDR releases. The dot form is present as a variant, the
colon form was long given as the normal pattern, then went away; but
now it's back as a contributed draft and that's what we pick up.
The MS-Win time-zone ID script was iterating a dict, causing random
reshuffling when new entries are added. Fixed that by doing the
critical iteration in sorted order.
Omitted locales ccp_BD and ccp_IN due to QTBUG-69324.
Task-number: QTBUG-79418
Change-Id: I43869ee1810ecc1fe876523947ddcbcddf4e550a
Reviewed-by: Lars Knoll <lars.knoll@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>
As a macro, we can't directly deprecate it, but need to make it call
something deprecated. That is a new ctor with a new enum type
added. The type might be useful for other such ventures, so put it
into qglobal.h
Remove the QT_NO_UNICODE_LITERAL protection, as it's always false
these days, and QT_UNICODE_LITERAL is unconditionally #defined a 20
lines above.
[ChangeLog][QtCore][QStringView] Deprecated the (undocumented)
QStringViewLiteral macro. Just use u"" or QStringView(u"") instead.
Change-Id: I9141320225037e1bc6b7f920bf01a9d0144fdac2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
Lars Knoll
Marc Mutz
Andrei Golubev
Edward Welbourne
Sona Kurazyan
Qt Forward Merge Bot
Giuseppe D'Angelo
Edward Welbourne
Cristian Adam
Simon Hausmann
Liang Qi
Alexandru Croitor
Leander Beernaert
Tuomas Heimonen
Thiago Macieira
Friedemann Kleint
Allan Sandfeld Jensen