We can't have those macros defined while compiling the headers on
Windows (mainly MSVC, but there are some corner cases that apply to
MinGW too) because the inline functions must be emitted and added to the
DLL export table. Trying to undefine (as qchar.cpp did) won't work in
builds with PCH or in CMake Unified builds, because the headers in
question will have already been included. So instead just #error out.
qchar.cpp is #included in qstring.cpp so it no longer needs this. For Qt
7, we'll un-export the class (see next commit).
Note: it's possible we only need a single .cpp including the headers and
compiled without these macros for the export to kick in. That could be
removed_api.cpp, because that can never be part of PCH or Unified
sources. But I have not confirmed this is the case.
Task-number: QTBUG-121356
Change-Id: I5dd50a1a7ca5424d9e7afffd17acba32fb27f1ca
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Changed section titles to sentence case.
Added or removed commas as required.
Simplified language were appropriate.
Varied terms to improve engagement.
Corrected resultant text to within the 80 character
width, so there will be whitespace change warnings.
Fixes: QTBUG-119553
Pick-to: 6.6 6.7
Change-Id: I5f40605fde4639a6dfcdb3816f32ad7599572fae
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mats Honkamaa <mats.honkamaa@qt.io>
The private QLocale::FirstTwoDigitYear constant, which is used as a
default value for the parameters in some methods, causes troubles for
Qt for Python Team, because they need to use the default values in the
binding code. It also potentially create some inconveniences for the
users who want to write functions wrapping these methods.
The name is also confusing, because, when read out of context, it
implies that there might be SecondTwoDigitYear, etc...
Rename QLocale::FirstTwoDigitYear to QLocale::DefaultTwoDigitBaseYear
and make it public.
Now when the constant is public, we can use it in QDate, instead of
introducing another constant, so do that.
The qdatetime.h header already includes qlocale.h via qcalendar.h,
but, rather than relying on this transitive include, add it
explicitly.
As pointed out by Thiago [1], the static constexpr members of exported
classes need out-of-line definitions, so add such definition to
qlocale.cpp.
Amends 41f84f3ddb
Found in 6.7 API review.
[1]: https://lists.qt-project.org/pipermail/development/2024-January/044888.html
Pick-to: 6.7
Change-Id: Ib3c6f1d5b181968bf311fd0435173e025a369865
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The constructor and update() method for the system locale were using
GetUserDefaultLCID(), where query() and the fallback locale first
checked the LANG environment variable, leading to inconsistent results
if the user set the environment variable to something different from
the system's configured locale.
Break out the logic of parsing %LANG% into a static helper, replace
the existing parsing with a call to this and add a helper to get the
right ID to use, possibly via it, using GetUserDefaultLCID() as
fall-back. Drive-by: initialize substititionType in its declaration.
Also look up %LANG% each time we want it; it's not that expensive,
given how rarely this code is called, and client code could change its
value at runtime. Partially inspired by a patch from Wladimir
Leuschner <wladimir.leuschner@qt.io>
Pick-to: 6.5 6.6 6.7
Fixes: QTBUG-120961
Change-Id: Ie706c7089bd2b3757a3eab627723ec34a5e2b07f
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QSystemLocale is setting the global window.onLanguageChanged
property which may cause conflicts in cases where there
are more than one Qt app instance on the same web page.
In addition the QSystemLocale destructor never runs,
which breaks also for repeated QLocale instantiations
on the same page (for example for the QLocale auto-
test)
Pick-to: 6.7
Change-Id: I85af0587527b2922804fc866c83864f677700e6d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
A null QString / QStringView has a null begin pointer stored as its
array beginning (something we hide a little in the QString::data()
function, but not in QStringView::data()). We've been passing a null
pointer to memcpy() every time someone passed a null QStringView for
QString's single-argument arg() call, though not the multi-string arg()
version (which is the only one QStringView offers).
Commit f5021835df made this worse by
making QStringViews created from null QStrings retain the nullness (as
was intended).
Fixes: QTBUG-120624
Pick-to: 6.2 6.5 6.6 6.7
Change-Id: I6e2677aad2ab45759db2fffd17a870639b19340b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Use QString as inheader record as the place of definition of both
Qt::Literals and Qt::Literals::StringLiterals. Previously mentioned
headers never exist.
Fixes: QTBUG-120379
Pick-to: 6.5 6.6 6.7
Change-Id: I104f73b338a144ef5f296500a9a4368cd3791750
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Commit ba5db13c8d ("QStringView: add
internal qToStringViewIgnoringNull()") said:
As long as a null QString still returns non-null data(), QStringView's
QString constructor needs to call isNull(). That's a branch we often
can do without, so add an internal function that bypasses this
correctness check.
It's internal, since we might have a Q6String that returns nullptr
data() when null, which will remove the need for this function.
For Qt 6, we made QString and QByteArray be able to return nullptr from
data() when null... but that's not enabled by default yet. However, the
begin() functions do return nullptr, so we can avoid the extra branch
the commit was talking about.
Task-number: QTBUG-119750
Change-Id: Ica7a43f6147b49c187ccfffd179e4cf032bc8565
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
That is, don't call QByteArray::data() because that one is still under
QT5_NULL_STRINGS conditional. Instead, like QString, call d.data()
directly, which is allowed to return a null pointer.
This necessitated a fix to QStringBuilder's QConcatenable because it was
iterating from &QByteArray::_empty to nullptr.
[ChangeLog][Important Behavior Changes] Calling begin() or end() in a
const QByteArray will return a null pointer if isNull() is true. This is
the same behavior as QString. This is important for code attempting to
iterate from data() to end() instead of begin() to end().
Change-Id: Ica7a43f6147b49c187ccfffd179e4cda75bd1031
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
In the case of QString, the vast majority of searches are case-
sensitive, so by inlining we make the user code call qustrchr() directly
instead of QtPrivate::findString(). In the case of QByteArray, the call
is to memchr(), which being a compiler intrinsic, may itself be inlined
or even just resolved at compile time.
In both cases, a great deal of searches use from=0.
Benchmark for QByteArray; before:
8.83207052 nsecs per iteration
22.01568546 CPU cycles per iteration, 2.49 GHz
60.00000331 instructions per iteration, 2.725 instr/cycle
21.00000281 branch instructions per iteration, 2.38 G/sec
After:
6.42561493 nsecs per iteration
16.01623130 CPU cycles per iteration, 2.49 GHz
49.00000261 instructions per iteration, 3.059 instr/cycle
18.00000211 branch instructions per iteration, 2.8 G/sec
This shaves 6 cycles in the execution and 11 instructions (3 of which
were branches), slightly improving the IPC raito, for the QByteArray
case. For QByteArrayView, there are 2 fewer instructions (1 a branch),
but the number of cycles is the same at 16.
Task-number: QTBUG-119750
Change-Id: Ica7a43f6147b49c187ccfffd179e2204ebb6a348
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
QByteArray::indexOf() had the best implementation of the two *because*
it was out-of-line, in qbytearray.cpp. The compiler could thus see the
body of the QtPrivate::findByteArray() function and inline it, with
constant-propagation, so only findCharHelper() was expanded and we had a
fast path towards memchr().
On the other hand, QByteArrayView::indexOf() was inline, so the
compiler emitted the call to QtPrivate::findByteArray() in user code,
causing the full function to be executed. We fix that by adding a char
overload for QtPrivate::findByteArray() and lastIndexOf(), so we get to
memchr() more quickly.
Also, inline QByteArray::indexOf() and lastIndexOf().
Before:
QByteArray::indexOf():
8.83287376 nsecs per iteration
22.01766832 CPU cycles per iteration, 2.49 GHz
62.00000330 instructions per iteration, 2.816 instr/cycle
21.00000281 branch instructions per iteration, 2.38 G/sec
QByteArrayView::indexOf():
9.64034694 nsecs per iteration
24.03001151 CPU cycles per iteration, 2.49 GHz
68.00000355 instructions per iteration, 2.830 instr/cycle
23.00000306 branch instructions per iteration, 2.39 G/sec
After (same result for both, requires recompilation):
8.83207052 nsecs per iteration
22.01568546 CPU cycles per iteration, 2.49 GHz
60.00000331 instructions per iteration, 2.725 instr/cycle
21.00000281 branch instructions per iteration, 2.38 G/sec
The inlining appears to have cut 2 instructions, but the effect is not
measurable in this benchmark (the entire code is in cache and the Branch
Predictor is probably primed).
Fixes: QTBUG-119750
Change-Id: Ica7a43f6147b49c187ccfffd179e1cb4b306fc62
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This is a repeat of the last commit, which did the same for QByteArray.
No benchmarks in this commit, assuming the results are similar (at least
for cs = Qt::CaseSensitive).
Task-number: QTBUG-119750
Change-Id: Ica7a43f6147b49c187ccfffd179e1f852272af8b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This patch is specific to the return type of updatePtrSimd function as boolean to avoid the bug of GCC 9.2.
Fixes: QTBUG-112920
Pick-to: 6.7 6.6 6.5
Change-Id: I21cb1f6dda34448b2290ab72ec280b6b2a3732c9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
As the comment says, this allows us to skip the check for non-detached
strings and for null ones. We know that the one we've just created isn't
either, so long as len != 0. All QConcatenable::appendTo() calls do
nothing if len == 0, including not calling memcpy() at all.
Moreover, because it no longer references the QByteArray::_empty
variable, the GCC -Warray-bounds warning should be gone too.
Task-number: QTBUG-116763
Pick-to: 6.7 6.6 6.5
Change-Id: Ica7a43f6147b49c187ccfffd179eba2897ce2aff
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
The twentieth century is now some way behind us, so using its years
when parsing a date-time format that only provides the last two digits
is increasingly likely to produce unwelcome results. Most such formats
are saved by the "redundant" presence of a day-of-week field but, for
those that are not (notably including ASN.1 date fields), there is a
need to provide some way to over-ride the twentieth century default.
Allow the caller to pass a base year to the fromString() methods, of
QDate and QDateTime, and to QLocale's toDate() and toDateTime(), that
indicates the first of 100 consecutive years, among which the two
digits given can select a year. Add some test-cases to exercise the
new API.
[ChangeLog][QtCore][QDate] When fromString() has only a two-digit year
to go on, it is now possible to set the start-year of the century
within which this selects.
[ChangeLog][QtCore][QDateTime] When fromString() has only a two-digit
year to go on, it is now possible to set the start-year of the century
within which this selects.
[ChangeLog][QtCore][QLocale] When toDate() or toDateTime() has only a
two-digit year to go on, it is now possible to set the start-year of
the century within which this selects.
Fixes: QTBUG-46843
Change-Id: Ieb312ee9e0b80557a15edcb0e6d75a57b10d7a62
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
For contiguous containers, end() is always begin() + size(), so use
that instead of data() + size().
Centralizes what it means to be an iterator in just begin() now, which
will simplify a follow-up commit of Thiago's.
Pick-to: 6.6 6.5
Change-Id: I53ca1a335910bdea3d46b9496ba39bc1a2d3fd93
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The `from` value is not constrained, so the code must be able to
handle all values, incl. `Min := numeric_limits<qsizetype>::min()`.
But the result of negating `Min` is not representable in qsizetype, so
it's UB to try.
Fix by multiplying both sides by -1 (which flips the relational
operator).
This works because the size() of a string is always non-negative, and
the negation of all such values is representable in the same type. Add
a comment to avoid a "fix back".
Amends f9b867216b.
Pick-to: 6.6 6.5
Change-Id: I10d2e400b86f07a6a6c0a61080a27f41a16b3517
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Provide qspan_p.h as backward-compatibility header.
[ChangeLog][QtCore][QSpan] New Qt equivalent of std::span.
Fixes: QTBUG-115022
Change-Id: I1cc27dc0aa1f7406f0a41d7a75f176cd7f858feb
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The (internal) docs say that - and _ are ignored, and they're ignored
everywhere, except as suffixes. If the old code only ignored them as
infixes, fine, that would make some sense, but it ignored infixes and
prefixes, so there's no reason for it to not ignore suffixes, too.
Fix by continuing the loop until both input ranges are exhausted, or a
mismatch was found.
[ChangeLog][QtCore][QStringConverter] Fixed a bug where
encodingForName() failed due to trailing characters (`_`, `-`) that
ought to have been ignored.
Pick-to: 6.6 6.5
Change-Id: Iec21489d988eda7d33c744c170f88cd665b73f34
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The cast that prevented it was a remnant of QStringView (which, like
QString itself, stores char16_t, but interfaces in QChar).
Remove the cast, add the constexpr.
[ChangeLog][QtCore][QUtf8StringView] data() is now constexpr, too.
Change-Id: I7891b89bf26176484411b4388ded04e56651b607
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
It's required for C++ containers.
Change-Id: Id5b51e1af22ac6e452019e976f50c727bbba6948
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Also update the QCollator::compare() docs for consistency.
Task-number: QTBUG-114822
Change-Id: I5fca896cacedd93ce5a4a1a8aead1986a21f6993
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QAnyStringView` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I6c37a8bf90e3de8cc254e9b1ff3077fc9ebe6636
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QByteArrayView` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I93abd3d0aaa2ae2bb3807b1aea5a938aabac848c
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QUtf8StringView::QUtf8StringView(const Char*,
qsizetype)` and `QUtf8StringView::QUtf8StringView(const Char*, const
Char*)` are not in sync with their intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I916e840677f26d855f0bd825e6a913100ac261e2
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When we restore a high surrogate from the state, we need to make sure
that the next code unit is a low surrogate. And if it is not then we
should at least not throw it away.
Amends d8d5922f16
Pick-to: 6.6 6.5
Task-number: QTBUG-118185
Task-number: QTBUG-105105
Change-Id: I64afa0d323d73422128e24e16755e648a8811523
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for of the members of `QStringView` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: Ia5c6f99d38b0080b150cbfca83ae605cc07d9b72
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
The nameMatch() function has an implicit precondition that neither
argument is nullptr: it immediately dereferences both arguments.
Prevent the crash by checking for name == nullptr early, before
passing to nameMatch().
Add tests for null and empty.
As a drive-by, make variables in the test const (needed for the
QByteArray to avoid detaching, peer pressure for the others).
Amends a639bcda1e.
Pick-to: 6.6 6.5 6.2
Change-Id: I4a30f6c130310eb701ba7c7251168294489c34db
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Prepare the code for the upcoming changes to support strings longer
than 2GiB.
We will have to loop from start to end, and increment the pointer
whenever we succeed, rather than assuming there is a single success
before we return.
This also means the error-handling code goes into an else-branch and
gets indented.
Pick-to: 6.6 6.5
Task-number: QTBUG-105105
Change-Id: Ibe49cc661f582fd54ce36ad466cf798a62b5c4c6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I ended up writing different logic for similar things.
And using points_into_range doesn't work if we, by coincidence,
point at end, though this shouldn't be possible yet, but it may happen
once we support input larger than 2Gi. So, let's instead check if the
destination buffer has been initialized.
Pick-to: 6.6 6.5
Task-number: QTBUG-105105
Change-Id: I28c367eb965339ae84355c0cac27c5d0352d9271
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
By just setting state to nullptr.
Pick-to: 6.6 6.5
Task-number: QTBUG-105105
Change-Id: I6b4f8fe39f1ba51dcfaf98ce7e42c2acd4c4cf98
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
indexIn() could hit UB if `from` < 0, so handle that case too. (This
also makes using noexcept for that method more correct wrt the Lakos
rule). While I think that passing valid indexes to a method is the
responsibility of the caller and that the existing API in Qt where a
negative index is interpretted as "search from the end" is
hard-to-use/bad API, not handling `from < 0` this way will most likely
not pass review (c.f. commit 81538c5219b92356c52233a80845847145795d6f on
gerrit). I'd rather get this over with so that an indexIn(QSV) overload
can be added...
Change-Id: Id85d18c901c82d9652804ecff7bfe7c71c10a63c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
With one exception in a kludge-around, substituteDigits() calls were
always subject to the same condition, so wrap that in a trivial method
and simplify the code calling it.
Change-Id: I6d8f3ca9179e32f03348cd718f9ee9de573221b9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The arrays can be constexpr, and we can avoid some repetition by
making only the choice of which to look in conditional, when we do the
same thing thereafter.
Change-Id: I8c9f95b3967017cf67a76de9d2a7a8729ee430f0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Likewise for the string list in uiLanguages(). Document the exception
(for grouping separator) and the other corner case (currency symbol).
In commit 089bbfc307 we changed the
system locale look-ups to rely on backends to return null QVariant on
failed look-up, but the MS backend has several places where it would
return an empty string for lookups that really shouldn't.
Pick-to: 6.6 6.5
Fixes: QTBUG-118703
Change-Id: I1a5622beebc4e5639d643250829937a829e23363
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is a simple backend based on navigator.languages,
which gives us a prioritized list of languages in the
form '["en-US", "zh-CN", "ja-JP"]'.
Use this to implement QSystemLocale::query() for UILanguages
and QSystemLocale::fallbackLocale().
Register an event handler for the native QWindow:languagechange
event in the QSystemLocale constructor. This event handler
stays active for the lifetime of the QSystemLocale object.
Task-number: QTBUG-116613
Change-Id: Ibd176748377e891b63a3f1d57605af0c2a49edb3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The win32 API doesn't give us much choice. _Some_ code pages have
support for returning some error if we pass a specific flag, but not
all of them.
Anyway, since the code pages might not support all that UTF-16 provides,
we can't reasonably make it error out on characters that cannot be
converted.
So, the most reasonable thing we can handle is a unpaired high surrogate
at the end of a string, assume that the rest of the string was fine, and
that the low surrogate will be provided in the next call.
Pick-to: 6.6 6.5
Fixes: QTBUG-118185
Task-number: QTBUG-105105
Change-Id: I1f193c9d8e04bec769d885d32440c759d9dff0c2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
To match convertToUnicode, we use a local array as a temporary
buffer, then if any growth is needed we work directly with a QBA.
As a drive-by: explicitly cast to int where we pass int
Pick-to: 6.6 6.5
Task-number: QTBUG-105105
Task-number: QTBUG-118185
Change-Id: I1efff318eea41d87d558599d737b64107af4ae17
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We don't use the value, and the docs[0] say that we get the best
performance if we don't pass the argument.
[0] https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte#remarks
See table
Pick-to: 6.6 6.5
Task-number: QTBUG-118185
Task-number: QTBUG-105105
Change-Id: I3eb5e023a936fe3def5169e3fb492a62708bbf44
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
So we don't have to do this multiple times when calling the function.
Pick-to: 6.6 6.5
Task-number: QTBUG-118185
Task-number: QTBUG-105105
Change-Id: Ifa72eedd5f71365618ec6b67fa3047f90f4eb541
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Both to store and to restore.
Without this a 3 or more octet sequence would cause errors or wrong
output. This can be seen with GB 18030.
Pick-to: 6.6 6.5
Fixes: QTBUG-118318
Task-number: QTBUG-105105
Change-Id: Id1f7f5f2fba4633b9f888add2186f4d8d21b7293
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A few code pages do not support this flag[0]. It's also deprecated[1]
and is what Windows prefers to generate by default. So let's drop it.
[0] https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
See note at the end for the dwFlags parameter.
[1] It's mentioned in the header files, but not online...
Pick-to: 6.6 6.5
Task-number: QTBUG-118185
Task-number: QTBUG-105105
Change-Id: I798c387170c73a953be874de139868543b2d775e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of having separate variables for the state, that we then
store back at the end, let's just make state-handing explicit, making
the logic around it easier to follow.
We now output Replacement Characters, if we try to decode stateless and
have an invalid sequence at the end. Otherwise we fall back to
convertToUnicodeCharByChar as before.
Pick-to: 6.6 6.5
Task-number: QTBUG-118318
Task-number: QTBUG-105105
Change-Id: Ifea64bc241113f468b69cad16fc3cc97a6ebe646
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We now, instead, resize and copy the data directly into a QString if
we run out of space in the pre-allocated array.
Pick-to: 6.6 6.5
Task-number: QTBUG-118318
Task-number: QTBUG-105105
Change-Id: I1eed5e75f0bd067b4e7d6bff97c4186f3f6ee0ad
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Thiago Macieira
Nicholas Bennett
Ivan Solovev
Edward Welbourne
Morten Sørvig
Alexey Edelev
Kai Köhne
shjiu
Marc Mutz
Luca Di Sera
Jaishree Vyas
Mårten Nordheim
Ahmad Samir
Anton Kudryavtsev