The actual formatting of date-time strings is handled by the calendar
backend, but the code's in qlocale.cpp as it uses some of its tools.
When feature timezone is unavailable, we're stuck (as before) with
using QDateTime::timeZoneAbbreviation(), but when it's available we
can use QTimeZone::displayName() to get the localized form of the
abbreviation and offset string.
Make matching changes in QDTP so that it recognizes these localized
abbreviations. We now have another candidate for what local time might
be called, to add to those that must be checked.
This naturally implied some changes to tests. It turns out ICU
believes en_US uses GMT+1/GMT+2 for CET/CEST. Replace some MS
QEXPECT_FAIL()s by including the non-abbreviations we do in fact use
on MS in the lists of "abbreviations" to accept.
[ChangeLog][QtCore][QLocale] When a datetime format includes the
timezone (or offset), the appropriately localised form is (to the
extent the timezone backend in use supports this) used where,
previously, a haphazard choice of system and C locale was used. This
applies to both serialization and parsing.
Task-number: QTBUG-115158
Change-Id: I04f9c1055c3b9008320bb8b758490287fd8be5cd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's legacy method marked as internal.
There are zero occurrences of "isSimpleText"
anywhere in Qt or Qt Creator other than qstring.*
Change-Id: I4961b7b2539fb6552484e77fbea58ba0e6656921
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The first/last/sliced API may be what we suggest users use, but the vast
majority of the installed codebase uses left/mid/right because they've
been available since time immemorial.
An additional benefit of this is to make left() and right() available as
inline methods.
Change-Id: Ifeb6206a9fa04424964bfffd1788383817ed906c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Those ought to have been the original implementation, when they were
added in commit 38096a3d70, for Qt 6.0.
Because these classes are exported, we need to provide the previous only
implementations for MSVC. All other compilers would provide inline or
emit local, out-of-line copies.
Change-Id: Ifeb6206a9fa04424964bfffd178836a2ae56157d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It's by far the most common use, so having to call two things is just
cumbersome.
Change-Id: I79e700614d034281bf55fffd178f454c4e31929e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
- Fix method name, it starts with a small letter
- Improve grammar in one sentence
- Use "INTEGRITY", less ambiguous and that's how their web site spells
it
Change-Id: Icfca9d7ebe64cd2f012456507ebf65c1e62f9e9d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Then we can easily test how fromLocal8Bit() and toLocal8Bit() behave
with different code-pages.
Pick-to: 6.6 6.5
Task-number: QTBUG-118318
Task-number: QTBUG-118185
Task-number: QTBUG-105105
Change-Id: Ib1cd3bccd27d598f4c80915557e332befcd96354
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The format is changed from 6.7 to support more than UINT32_MAX - 1
elements. The format used to have a quint32 size. Now if the size is
larger or equal to 0xfffffffe (2^32 -2) the old size is an extend
value 0xfffffffe followed by one quint64 with the actual value. The
32 bit size with all bits set is still used as null value.
Fixes: QTBUG-105034
Change-Id: I62188be170fe779022ad58ab84a54b1eaf46e5d9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QStringList] Added lastIndexOf() overloads that take
a QString/QStringView/QLatin1StringView and a Qt::CaseSenitivity
parameters. Prior to this calling lastIndexOf() would call the methods
inherited from the base class. This change is source compatible and
existing code should continue to work.
Task-number: QTBUG-116918
Change-Id: Ia50c884c00021bf581c23c12e0e0c22700dae446
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QStringList] Added filter(QLatin1StringView)
overload, which is more optimized when searching for a Latin-1 string
literal as no conversion to QString is necessary.
Task-number: QTBUG-116918
Change-Id: Ieb92f4cfd545b070258dbc5c701ddfb2e6f3fc64
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QStringList] Added indexOf() overloads that take
QString/QStringView/QLatin1StringView, and a Qt::CaseSensitivity
parameter. Prior to this using QStringList::indexOf() called the methods
inherited from the base class.
Task-number: QTBUG-116918
Change-Id: Ibc42130b6509f6ecfe7de0d6be378f226ae61982
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Now that users can pass a QStringMatcher to do the matching, change the
existing overload to not use QStringMatcher.
Thanks to Giuseppe D'Angelo for the idea of passing a QStringMatcher to
filter instead of using a magic number to decide whether to use
QStringMatcher or not.
Results of running filter() and filter_stringMatcher, times are in msecs
and this was compiled with gcc -O3:
Without With QStringMatcher
list10 0.00022 0.000089
list20 0.00040 0.00014
list30 0.00058 0.00018
list40 0.000770 0.00023
list50 0.00094 0.00027
list70 0.0012 0.00037
list80 0.0014 0.00041
list100 0.0018 0.00050
list300 0.0054 0.0014
list500 0.0091 0.0023
list700 0.012 0.0032
list900 0.016 0.0041
list10000 0.17 0.045
Drive-by change: optimize tst_QStringList::populateList().
[ChangeLog][QtCore][QStringList] Added filter(const QStringMatcher &)
overload, which may be faster for large lists and/or lists with very
long strings.
[ChangeLog][Possible Performance Changes][QtCore][QStringList] Changed
the implementation of filter(QStringView) overload to not use
QStringMatcher by default. Using QStringMatcher adds overhead, so it is
beneficial/faster when searching for a pattern in large lists and/or
lists with long strings, otherwise using plain string comparison is
faster. If using QStringMatcher makes a difference in your code, you can
use the newly added filter(QStringMatcher) overload.
Change-Id: I7bb1262706d673f0ce0d9b7699f03c995ce28677
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The existing pattern() method always returns a QString, which means that
if the matcher was constructed using a QStringView, pattern() would
uncoditionally convert it to a QString.
This is useful to check if a match is exact:
auto pattern = matcher.patternView();
if (pattern.size() == needle.size() && matcher.indexIn(needle) == 0)
....
This may be needed for a later change in QStringList::contains();
regardless of that, this change makes sense on its own.
Change-Id: I49018551dd22a8f88cf6b9f878a5166902a26f58
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We don't use va_list and don't have variadic functions in this file.
[ChangeLog][Potentially Source-Incompatible Changes] The header
qbytearray.h no longer includes the header stdarg.h.
Change-Id: I8f3ce163ccc5408cac39fffd178c7fb49d12b739
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
.data() in both classes has a null pointer check so it will return non-
null even if the object is storing a null pointer, for compatibility
with Qt 5 (controlled by QT5_NULL_STRINGS). We don't need this in
first()/last()/sliced()/chopped(), so we can skip the test and pass
whatever pointer it is directly to the class constructor. Both of them
handle null pointers creating an isNull() object.
This is a minor performance optimization and interestingly makes these
functions now retain isNull() with the result. I'm not adding test for
that as I don't want to hardcode that they will do so.
Change-Id: Ifeb6206a9fa04424964bfffd17888d14ec8244ec
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
These methods return a struct which is implicitly convertible to
QString/QByteArray respectively. Don't hide the return type from QDoc,
this simplifies telling users what those methods return exactly.
Fixes: QTBUG-117705
Pick-to: 6.6 6.5
Change-Id: Ibb22a1e54fffce8f5f20aaabe47983870ccfba1e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Don't call resize on QVLA, just wrap pointers in QSV
As drive-by, fix typo in comment
Change-Id: Id90236cfb53d861b8bd57fa9452aba4b8d9b20bf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We have to single QString out because of the isNull/isEmpty distinction.
Still, we can avoid having a constructor template on it constrained on
the argument being precisely QString. This is a historic remnant; in Qt
5 the constructor also worked with QStringRef.
Change-Id: I5457a83d5b77887f57ea9910a826f729ec276d28
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Canonical way is compare result of std::find_if against end by != operator, not <
Change-Id: Ifffbaf11416ea0738a1ccbb2f2f8482193390070
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
A helper method encasuplating the asserts related to index into the
container and length, modelled after the QVLA::verify().
`pos <= size` is OK because if pos == size, the e.g. sliced()'ed
container is just going to be empty.
Normalize how verify() is used, the first arg is an index and the second
a length.
This method is constexpr even in QString/QByteArray merely for
consistency with similar methods in other string classes (this
necessitates using `d.size` in verify() in QString/QBA because size()
isn't constexpr).
Change-Id: I90e3c56d76c802259297a06d11d46ee342a1daf2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Implement the missing overload to handle UTF-8 specific data types,
including char8_t (C++20), char, uchar and signed char.
Introduce the helper function 'assign_helper_char8' which handles the
non-contiguous_iterator case. The contiguous_iterator case is already
handled by the QAnyStringView overload.
Include 'qstringconverter.h' at the end of the file, since it can't
be included at the top due to diamond dependency conflicts.
QStringDecoder is an implementation detail we don't want users to
depend on when using assign(it, it). It would be unnatural to not
be able to use a function just because we didn't include an
apparently unrelated header.
[ChangeLog][QtCore][QString] Enabled assign() for UTF-8 data types.
Fixes: QTBUG-114208
Change-Id: Ia39bbb70ca105a6bbf1a131b2533f29a919ff66d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The class name was wrong.
Task-number: QTBUG-100236
Change-Id: I0ffd163bf59682d8326feefb76a4cd8b7e106105
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Øystein Heskestad <oystein.heskestad@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Let's find replaceable chars and then do copy
Change-Id: I2d365626218b0daf2023144dee7e901e8e99adc6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Let's find needle and then do detach
While touching code, replace raw loop with algorithm
and add early out: compare before and after args
Change-Id: I22403fd3d6920d941b65e79f44b46e49a9777dc5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In the documentation of the TagSeparator parameters of three QLocale
methods, I neglected to mention they were added at 6.7. This amends
commits 91e70f239e and
15cfdab514 in which I added these
parameters.
Change-Id: I11462b88305255359d4e9b144b000cffe9a142ad
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Fix the following QDoc warnings:
* warning: Can't link to 'QRhiWidget::sampleConut'
* warning: Can't link to '`Q_NODISCARD_CTOR'
* warning: Invalid '\relates' (already a member of 'QEventLoopLocker')
* warning: Unknown command '\relatesalso'
* warning: Undocumented parameter 'separator' in QLocale::name()
* warning: clang couldn't find function when parsing \fn void QRhiWidget::framePresented()
In QAtomicPointer, work around the issue of QDoc not supporting
multiple \relates command for a single topic by adding a see-also
link to the global qYieldCpu() function.
Document the qvariant_cast() overload taking an rvalue reference.
Change-Id: I2528eee666149a97a14be059bbed537636d7aa0d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
By first checking if the list has any matches before potentially making
it detach.
Change-Id: I7a42c2910ef6efc45033e562573414a3a9ef972e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use a lambda instead of a struct with operator(), it's only used in one
place and a lambda is more optimizable.
Change-Id: If3917f4819a7c886a08ad1396d92fcbcf606cbcb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QStaticLatin1StringMatcher is a static templated Latin-1 Boyer-Moore
string matcher which can be case sensitive or not. It should be used
when the needle is known at compile time so there is no run-time
overhead when generating the skip table.
The convenience functions qMakeStaticCaseSensitiveLatin1StringMatcher
and qMakeStaticCaseInsensitiveLatin1StringMatcher should be used to
construct the matcher objects.
Green Hills Optimizing Compilers are currently not supported.
[ChangeLog][QtCore] Added QStaticLatin1StringMatcher, which can be used
to create a static constexpr string matcher for Latin-1 content.
Task-number: QTBUG-100236
Change-Id: I8b8eed1e88e152f29cbf8d36d83e410fafc5ca2c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
After the v43 update landed, a bug surfaced that was fixed by it, so
it has been picked back to 6.6, in which it has landed before 6.6.0
branched. Consequently the new enum members are in fact [since 6.6],
not [since 6.7], so update the documentation to reflect reality.
(They may also be in 6.5.3, subject to ongoing debate, but they were
not in 6.5.0 so are not [since 6.5], even if 6.5's branch does end up
describing them as [since 6.5.3].)
Pick-to: 6.6
Change-Id: Ida938fc3e3575d6e45d61449123464ebb5b6638c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If an inline member function is defined outside of its class' body,
its declaration must have the inline keyword. Otherwise, in certain
situations, MinGW complains like this:
qstring.h:1118:13: error: 'void QString::clear()' redeclared without dllimport attribute after being referenced with dll linkage [-Werror]
Fix all instances in qstring.h by
- adding the inline keyword where it was missing on the definition
(except constexpr functions, which are implicitly inline)
- removing the inline keyword from all out-of-class-body definitions
While the latter isn't necessary for fixing the MinGW
warning-turned-error, the churn is warranted: It's enlisting all
platforms' help in checking for inline consistency (by causing
"multiple-definition errors" at link time or "inline function never
defined" at compile time when we get it wrong). If we kept the inline
keyword on the definitions, only MinGW would continue to warn, and only
in some, as of yet not fully understood, situations, so we'd have no
control over when these warnings pop up in user code.
Pick-to: 6.6 6.5 6.2
Change-Id: I0ae78f1d8f1fa4eaec0b162ea16013669370eead
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The SizeShift was not taken into account when constructing QASV from
QL1SV. This is not an issue in normal Qt builds, because SizeShift == 0
there.
But in bootstrapped case (and in future Qt 7) SizeShift changes to 2,
and the bug becomes visible.
The added test-cases do not really reveal the issue, because we do
not run tests in bootstrapped builds, but at least they will help
to prevent the issues in Qt 7.
Pick-to: 6.6 6.5 6.2
Change-Id: I337b37b5230323a5357f48fd1c9bf799ca507d52
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QString::fromJsString -> QString::fromEcmaString()
QString::toJsString() -> QString::toEcmaString()
For API naming compatibility with QByteArray::fromEcmaUin8Array()
Pick-to: 6.6
Change-Id: If6e2121e31e630d6728ed24e41d14b763f395aaa
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Instead of a manual loop, which was there since at least Qt 4.5.1
(beginning of the public history).
Pick-to: 6.5 6.6
Change-Id: Ifa1111900d6945ea8e05fffd177dd3dfea450a67
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
QStringView already did since 6.0. I don't know how we missed this.
Pick-to: 6.5 6.6
Change-Id: I5acc02341c5940499682fffd1774f7c3a807317a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
When appending to an empty string or byte array, we optimize and
copy the internal pointer. But if the other string/byte array was
created with fromRawData this might be temporary data on the stack/heap
and might be de-allocated or overwritten before the string/byte array
is used or is forced to make a deep-copy. This would lead to incorrect
data being used.
This is easy to overlook if you plan to append multiple strings
together, potentially supplied through an argument. Upon appending a
second string it would make a full copy, but there might not be a
guarantee for that. So, it's hard for users to avoid this pitfall!
Fixes: QTBUG-115752
Pick-to: 6.6 6.5 6.2
Change-Id: Ia9aa5f463121c2ce2e0e8eee8a6c8612b7297f2b
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously name() has always used underscore and bcp47Name() dash; let
the user chose which one best fits their needs.
[ChangeLog][QtCore][QLocale] QLocale's name() and bcp47Name() now let
the caller chose what separator to use between the tags making up the
name, where there is more than one.
Change-Id: Ia689e6a3fb581b42905e7fb1ae7a7b688244d267
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This clarifies what doesn't work, that we print a warning, and that it
applies to all Unix systems aside from macOS, not just Linux.
Fixes: QTBUG-115852
Pick-to: 6.6
Change-Id: I80612a7d275c41f1baf0fffd1779701e98e7552d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
It has always returned dash-joined forms of the locale names, and
callers who need an underscore-joined form have been obliged to
replace('-', '_') before using them. Given that everything it adds to
the list comes from QLocaleId methods that accept a separator, it's
trivial to let it offer the same choice to its callers and save them
this hassle.
Amended code in QTranslater and QMimeType to save them that hassle.
[ChangeLog][CoreLib][QLocale] QLocale::uiLanguages() now lets the
caller choose what separator to use between the tags that make up each
locale-identifier in the list returned.
Change-Id: I91fcd0b988d9a64e0e9ad9e851f6cb8c1be8ae50
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This amends commit 9237908327, which
shouldn't have integrated, but apparently the qdoc check in Coin
wasn't running that day.
Pick-to: 6.5 6.6
Task-number: QTBUG-111550
Change-Id: Ife6108eb49fb8988d43390200de480fc5b57e58f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We've known for a long time that this is producing worse code with GCC
because of how we implemented in Q_ASSUME_IMPL(). So bite the bullet and
actually deprecate the macro, replacing all extant Q_ASSUME() with
Q_ASSERT().
The replacement is in C++23. Backporting the support onto Q_ASSUME_IMPL
was previously rejected by reviewers.
[ChangeLog][Deprecation Notice] The Q_ASSUME() macro is deprecated. This
macro has different side-effects depending on the compiler used (GCC
compared to Clang and MSVC), and there are certain conditions under
which GCC is known to produce worse code than if the macro was absent.
To give a hint to the compiler for optimizations, use the C++23
[[assume]] attribute.
Change-Id: I80612a7d275c41f1baf0fffd177a3a4ad819fb2d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
operator=(~) and assign(~) share similar names but, until now, have not
shared the same functionality. This patch introduces the usage of
QByteArray::assign() within the non-sharing assignment operator to
effectively boost efficiency by reusing the available capacity.
Since these assignment operators are frequently used in many places,
both within Qt and non-Qt code, this patch comes with benchmarks.
The preview of the benchmark results are compared with this patch and
before this patch. The findings indicate a slight enhancement in
performance associated with the assignment operator. Despite the results
displaying only a minor improvement, progress has been made. Therefore
use assign(QByteArrayView) as replacement.
(x86_64-little_endian-lp64 shared (dynamic) release build (O3); by
gcc 13.2.1, endeavouros ; 13th Gen Intel(R) Core(TM) i9-13900K
benchmarks executed with -perf -iterations 1000000
* The last value at the EOL represent the string size.
QByteArray &operator=(const char *ch) (current)
65 cycles/iter; 317 instructions/iter; 16.0 nsec/iter (5)
71.7 cycles/iter; 383 instructions/iter; 13.0 nsec/iter (10)
59.8 cycles/iter; 318 instructions/iter; 10.9 nsec/iter (20)
70.8 cycles/iter; 340 instructions/iter; 12.9 nsec/iter (50)
80.2 cycles/iter; 419 instructions/iter; 14.6 nsec/iter (100)
164.2 cycles/iter; 899 instructions/iter; 29.9 nsec/iter (500)
260.5 cycles/iter; 1522 instructions/iter; 45.6 nsec/iter (1'000)
QByteArray &operator=(const char *ch) (before)
66.8 cycles/iter; 317 instructions/iter; 16.9 nsec/iter (5)
76.5 cycles/iter; 383 instructions/iter; 13.9 nsec/iter (10)
63.7 cycles/iter; 318 instructions/iter; 11.6 nsec/iter (20)
71.6 cycles/iter; 344 instructions/iter; 13.0 nsec/iter (50)
77.5 cycles/iter; 419 instructions/iter; 14.1 nsec/iter (100)
143.4 cycles/iter; 893 instructions/iter; 26.1 nsec/iter (500)
270.8 cycles/iter; 1516 instructions/iter; 48.2 nsec/iter (1'000)
Task-number: QTBUG-106201
Change-Id: I0745c33f0f61f1d844a60960cc55f565320d5945
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The code of a class doesn't need that class's prefix to access members
of the class.
Change-Id: I4cc2f72c90cff48b331dc12d390c45c0639606b3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Now that the "and" is only seen in enumdata.py and comments, we can
s/And/and/ in all the various territory names that used it.
Change-Id: Ic376d5904b6f5ab54931f96230c1dd5b7f357b8d
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Various comments need to continue using the enumdata.py names, as they
associate data with particular enum members, but we can now correctly
use the en.xml versions of their names when we report them, rather
than the enum-friendly names we use in the code. Since this now means
the data may stray outside plain ASCII - it'll be UTF-8-encoded - this
implies replacing the QLatin1StringView()s of the code that formerly
read this data with QString::fromUtf8().
Fixes: QTBUG-94460
Change-Id: Id3b08875a46af58c0555c3e303b0e15a19441509
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We could already use dashes in some, rather than spaces, and now no
longer need to capitalize each word. This changes the *_name_list[]
entries for affected languages to more closely match what CLDR gives
as their names. It also amends various comments. Added tests for the
QLocale::*ToString() functions to cover the entries changed.
Task-number: QTBUG-94460
Change-Id: I0163795cb282881f15a97be00a5311c1936c3a09
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Those are "public-ish" and exported functions (qstringalgorithms.h), so
one wouldn't expect that they get inlined most of the time. But they can
be inlined by other code inside qstring.cpp and if QtCore is compiled
with LTO.
More importantly, we want the compiler to inline qustrXXX_avx2() into
it, instead of tail-calling into qustrXXX_avx2(). This may seem like a
no-op but has one very important difference: backtraces will point to an
exported, function instead of an internal symbol. This will then allow
us to create valgrind suppressions.
Before unstripped:
==12492== Invalid read of size 32
==12492== at 0x53142EE: qustrchr_avx2(QStringView, char16_t) [clone .lto_priv.0] (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==12492== by 0x54A7AE6: QString::indexOf(QChar, long long, Qt::CaseSensitivity) const [clone .constprop.0] (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==12492== by 0x5218EC4: treatAsAbsolute(QString const&) (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==12492== by 0x5218FBA: QDir::filePath(QString const&) const (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
Before, stripped:
==19477== Invalid read of size 32
==19477== at 0x5314395: ??? (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19477== by 0x54A7AE6: ??? (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19477== by 0x5218EC4: ??? (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19477== by 0x5218FBA: QDir::filePath(QString const&) const (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
After:
==19692== Invalid read of size 32
==19692== at 0x53143C5: QtPrivate::qustrchr(QStringView, char16_t) (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x54ABA46: ??? (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x5218824: ??? (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x521891A: QDir::filePath(QString const&) const (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== Address 0x741919e is 2 bytes before a block of size 32 alloc'd
==19692== at 0x4843794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==19692== by 0x54A8A84: ??? (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x531EB1C: QString::fromLatin1(QByteArrayView) (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
Recommended suppressions:
{
qustrchr_avx2
Memcheck:Addr32
fun:_ZN9QtPrivate8qustrchrE11QStringViewDs
}
{
qustrchr_avx2-with-debuginfo
Memcheck:Addr32
fun:UnknownInlinedFun
fun:UnknownInlinedFun
fun:_ZN9QtPrivate8qustrchrE11QStringViewDs
}
Change-Id: Ib84fc618ac204205bf7afffd1772b1d87343dfd0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
I'd previously understood CLDR's minimumGroupingDigits to mean the
most significant group must have that many digits. It turns out to
mean only that the first grouping separator doesn't get added unless
the more significant group has this many. Once we have one separator,
more can be added that do isolate a single digit.
In the process, I discover some of the prior arithmetic is incorrect;
it is now fixed. Added some basic testing, amended some existing
tests. In the process, fixed naming of some double validator tests.
Pick-to: 6.6 6.5
Fixes: QTBUG-115740
Change-Id: Ia6ce011ba72e72428b015ca22b97d815ebf751b2
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
qstringbuilder.h needs qstring.h completely parsed. Without this
change, we won't be able to include qstringconverter.h even at the end
of qstring.h (needed for QTBUG-114208).
Picking back to 6.5 to reduce the diff with our LTS going forward.
Task-number: QTBUG-114208
Pick-to: 6.6 6.5
Change-Id: I83d5bcc0939b698209481793f60a0199aa95a06e
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The string data tables have a mix of digit-length tokens, up to
four-digit hex; we can fit 12 of those per line within our margins.
Leave the one-row-per-locale tables as they are, though, despite long
lines.
Change-Id: I655fddecf24133c26d16187b7a5a8fbc25553e07
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
It's a) not needed, because qstringbuilder.h simply just defines op%
and not op+ when these defines are not set and b) surprising for users
that they have to include <qstringbuilder.h> if they want to use op%
without also setting one of these defines. Finally, it just throws
readers of the code off the track for no good reason.
So, drop the external guards for qtringbuilder.h in qstring.h and
qstringconverter.h.
Task-number: QTBUG-114208
Pick-to: 6.6 6.5
Change-Id: I00b3e405d905d319437c32a7253b39de1625d096
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
I.e. concatenating a null byte array and an empty-but-not-null byte
array should result in an empty-but-not-null byte array.
This matches the behavior of QString::append(QString) too.
Fixes: QTBUG-114238
Pick-to: 6.6
Change-Id: Id36d10ee09c08041b7dabda102df48ca6d413d8b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Ran the scripts, added the new enum members to docs.
Updated tests:
* Two of the new languages are right-to-left,
* Canada has replaced a silly date format with a sensible one.
Fixes: QTBUG-111550
Change-Id: Ie6f1e6e94477167c9e2b5c67e6518ca0f6a7e7fb
Reviewed-by: Mate Barany <mate.barany@qt.io>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Nothing prevents client code from calling QLocale::setDefault() before
we ever instantiate QLocale::system() - aside from some quirks that
mean setDefault(), currently, does instantiate QLocale::system() to
force initialization of defaultLocalePrivate - so using defaultIndex()
could set the system QLocalePrivate instance's index incorrectly.
In any case, even if the index is initially set correctly, a
subsequent change to the system locale would change the correct index;
and nothing outside QLocale::system() has access to the instance that
would then be remembering an out-of-date index.
Actually tripping over that inconsistency took some deviousness, but
was possible. The index is (currently) only used for month name
lookups and those special-case, for the Roman-derived calendars, the
system locale, to only use the index if the system locale offers no
name for a month. Meanwhile, updateSystemPrivate() uses the fallback
locale's index for its look-up of which CLDR data to copy into the
fallback QLocaleData for the system locale.
None the less, a non-Roman calendar's lookup will go via the index to
get at the CLDR data for that calendar, thereby exposing the system
locale's index to use; and, sure enough, a setDefault() could lead
that to produce wrong answers.
In QLocale::system() there's a cached QLocalePrivate, whose index we
need to ensure stays in sync with the active system locale. So pass
its &m_index to systemData(), which will now (when passed this) ensure
it's up to date. Since we always have called systemData(), to ensure
it is up to date, we can skip that update in the initialization of the
cached private and use m_index = -1 to let systemData() know when it's
in the initial call, thereby making the static cache constinit.
Amended a test to what proved the issue was present.
Change-Id: I8d7ab5830cf0bbb9265c2af2a1edc9396ddef79f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
E.g. a group separator, a -/+ sign, or 'e' (exponent). Input ending with
one of these characters now returns Intermediate, as it can become
Acceptable if the user types more characters.
Remove a check from initialResultCheck(), as it's now covered by
QLocaleData::validateChars() checking that the last character in the
buffer is -/+, this works the same if buffer's size is 1.
Extended unittests based on the linked bug report; the other cases for
"last" are already covered by existing unittests.
Task-number: QTBUG-111371
Change-Id: I9b6979c29f07a5f57b040004cd3dbf4e27147c21
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It was defined in qlocale_tools_p.h which already includes qlocale_p.h.
Change-Id: I43464a27ec15266ce8632ca30dcd1c57d94b1f25
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of returning just bool, return a result struct {State,
CharBuff}, a State is useful as it can have an Intermediate state
where the input isn't Acceptable yet, but not Invalid as such. The
example from the linked bug is in tst_QIntValidator::validateFrench(), a
string "1 ", which can be interpretted as a number with a group
separator, but the input shouldn't end with a group separator (changing
the unittest will be done as part of a separate commit).
CharBuff (QVarLengthArray<char, 256>) replaces the QByteArray input
parameter; a QVarLengthArray means no heap allocation in typical
use-cases with input text < 256 characters to validate. This required
minimum changes (QVLA doesn't have startsWith, replaced by comparing
with buff[0]; and for converting to double, wrapped it in a QBAV).
Task-number: QTBUG-111371
Change-Id: I4e0eb612d470ef03faf52031ddfe9c4bdb31e1e1
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Take by const Str&, trimming a container/view of characters means
removing whitespace from the beginning and end, so the two args were
always cbegin() and cend().
Change-Id: Iac0eda59341f1981204d11013d591013eae3c4e0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The other Roman-based calendars share the same month names as
Gregorian, so it makes sense for them to use the same system fallbacks
as it when available.
Change-Id: Idf2f2901032c7a02d641f00a3993cc95b6bb8067
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Amends commit 94de5f9b25 so that every
change to the default locale is reflected in an update to the default
collator used by QString::localeAwareCompare().
Although the change to the system locale does update the QLocaleData
object shared by all system locale objects, the possible change to its
collator() may imply the default collator needs an update; and the
collator backend's init() may use the language, script and territory
that's changed in setting up the revised collator, even if the QLocale
instance referenced has the same QLocaleData.
Pick-to: 6.6 6.5 6.2
Change-Id: I957486c03c3d779fc9a2f0b889346ec13b1af868
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
They have no preconditions and cannot throw.
As a drive-by, merge the definition of isEmpty() into its declaration.
Pick-to: 6.6
Change-Id: Ifffa0d4cb2a285bb802d39d10a757be9c31cfae1
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This requires explicitly marking constexpr if conditions to fix C4127
issues:
qtbase/src/corelib/text/qstringbuilder.h(112):
error C2220: the following warning is treated as an error
qtbase/src/corelib/text/qstringbuilder.h(112):
warning C4127: conditional expression is constant
qtbase/src/corelib/text/qstringbuilder.h(112):
note: consider using 'if constexpr' statement instead
Change-Id: I9787fb37099f811c52f93c94c9edb4da8aafdfe5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A text editor commonly wants to display a list of codecs that are
supported. With the introduction of the ICU based QStringConverter, that
list is no longer statically known. So provide the necessary
functionality.
Fixes: QTBUG-109104
Change-Id: I9ecf59aa6bcc6fe65c8872cab84affafec4fa362
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In C++20 std::basic_string_view has gained a range constructor (like
QStringView always had), but that range constructor has been made
explicit. This means we can't just pass a QString(View) to a function
taking a u16string_view. The consensus seems to be that that types that
should implictly convert towards stdlib's string views should do that
via implicit conversion operators. This patch adds them for
* QByteArrayView => std::string_view
* QString(View) => std::u16string_view
* QUtf8StringView => std::string_view or std::u8string_view, depending
on the storage_type
QLatin1StringView doesn't have a matching std:: view so I'm not enabling
its conversion.
QByteArray poses a challenge, in that it already defines a conversion
towards const char *. (One can disable that conversion with a macro.)
That conversion makes it impossible to support:
QByteArray ba;
std::string_view sv1(ba); // 1
std::string_view sv2 = ba; // 2
because:
* if only operator const char *() is defined, then (2) doesn't work
(situation right now);
* if both conversions to const char * and string_view are defined, then
(1) is ambiguous on certain compilers (MSVC, QCC). Interestingly
enough, not on GCC/Clang, but only in C++17 and later modes.
I can't kill the conversion towards const char * (API break, and we use
it *everywhere* in Qt), hence, QByteArray does not get the implicit
conversion, at least not in this patch.
[ChangeLog][QtCore][QByteArrayView] Added an implicit conversion
operator towards std::string_view.
[ChangeLog][QtCore][QString] Added an implicit conversion operator
towards std::u16string_view.
[ChangeLog][QtCore][QStringView] Added an implicit conversion operator
towards std::u16string_view.
[ChangeLog][QtCore][QUtf8StringView] Added an implicit conversion
operator towards std::string_view (QUtf8StringView is using char
as its storage type in Qt 6). Note that QUtf8StringView is planned to
use char8_t in Qt 7, therefore it is expected that the conversion will
change towards std::u8string_view in Qt 7.
Change-Id: I6d3b64d211a386241ae157765cd1b03f531f909a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When QDebug::quoted(), indicates the encoding using the u/u8 prefixes
or the _L1 suffix. This is information that might come in handy, and
we plan to make it off-switchable (QTBUG-114936). The default should
be true, though, for QAnyStringView, because we should confront users
with this feature so they learn it exists. For concrete view types,
changing the default behavior is probably not a good idea.
[ChangeLog][QtCore][QAnyStringView/QDebug] Can now stream
QAnyStringView into QDebug.
Fixes: QTBUG-114935
Change-Id: Icd5bf700c8b7958e942468b54248487998f262d5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This minimizes any multi-threading / file-locking issues as the file is
closed once the contents are read.
This change assumes /proc/self/mountinfo is available on Linux systems,
and doesn't fallback to setmntent(). It's been around since at least
Linux Kernel 2.4.0.
This requires exporting qstrntoll() for the unittests (using
QT_AUTOTEST_EXPORT and wrapping the those unittests in "#ifdef
QT_BUILD_INTERNAL"), otherwise linking fails.
Fixes: QTBUG-77059
Change-Id: I0363258a9979ea6dadfe5e36c02534ffbd3386c5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Code points is what you get when surrogate pairs have been joined
Pick-to: 6.6 6.5 6.2
Change-Id: I86c4131de5782ce1e6342217947a603ca16bb521
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
My fault, I had added that bit of the docs a while ago.
Pick-to: 6.6
Change-Id: I1fa2c10b0f7263e12b5b2a4d18f362c702f9d831
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The idea is to store a concatenable in a QStringBuilder object by value
or by reference, depending on how it was originally passed into the
concatenation operator. So if it was passed by r-value, we treat it as
a temporary object and hold it by value (and use move-semantic if
available), otherwise we hold it by reference (as before).
To achieve this we first change concatenation operators '%' and '+'
to take their arguments by universal reference. Next we instantiate
QStringBuilder object with deduced types of the arguments, which will
be a "value type" or a "reference type" according to "universal
reference deduction rules".
Further we use perfect forwarding to pass arguments to QStringBuilder's
constructor. Thus arguments, initially passed by r-value reference
and which are move-constructible, will be "moved" to corresponding
QStringBuilder member variables.
So, to summarize:
1. Arguments passed by l-value reference - stored in QStringBuilder
object by reference (as before).
2. Temporary objects passed by r-value reference - stored in
QStringBuilder object by value. If a type is move-constructible
(QSting, QByteArray, etc), the object will be "moved" accordingly.
Special thanks to Giuseppe D'Angelo for the tests.
Fixes: QTBUG-99291
Fixes: QTBUG-87603
Fixes: QTBUG-47066
Task-number: QTBUG-74873
Task-number: QTBUG-103090
Task-number: QTBUG-104354
Change-Id: I64f417be0de0815ec5ae7e35a1cc6cef6d887933
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Vladimir Belyavsky <belyavskyv@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Deduplicate it in the process by moving to qstringalgorithms.h.
In non-constexpr contexts, both GCC and Clang were giving up in
pre-calculating the length if the UTF-16 string literal was too big. For
the old code, that was 14 and 16 characters respectively. That number
can be raised by adding some Q_ALWAYS_INLINE and (for GCC's case),
replacing std::char_traits::find() with std::find(). If that limit is
exceeded, we call the newly introduced qustrnlen() function.
qustrnlen() is just qustrchr(), like qstrnlen() is just memchr(). But it
is introduced as a separate function so we could change implementation
if we ever wished to, plus QStringView is only forward-declared at this
point.
Change-Id: Ieab617d69f3b4b54ab30fffd175c560d926db1c3
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is not q20::is_constant_evaluated() because it does not replace
that for all compilers. Instead, it's our own version of it that may
return false even in constant contexts. However, for the majority of our
users, it will work even in C++17 mode.
Updated QStringView and QAnyStringView to use it, which are the only two
places in all of Qt that used std::is_constant_evaluated().
Change-Id: Ieab617d69f3b4b54ab30fffd175c50c517589226
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Because GCC isn't really working them out at compile time. First, for
both lengthHelperPointer(), they don't get called on string literals
such as
return QStringView(u"Hello");
because the type hasn't decayed to a pointer, but is instead a
char16_t[6]. No one writes
constexpr auto str = u"Hello";
return QStringView(str);
Second, even when you do write that, GCC is emitting the code to search
for the null or non-ASCII byte at runtime, instead of pre-calculating
it. That's not worth it because the code is not vectorized, even at -O3
and with a long string. Instead, let it get the length at runtime with
QtPrivate::qustrlen(), which has vector code.
Drive-by fix the QAnyStringView::lengthPointerHelper() to be constexpr,
avoiding the same GCC warning that was fixed for QStringView in commit
4fd4082c3a.
Change-Id: Ieab617d69f3b4b54ab30fffd175c505cb66eac02
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
It turns out that Darwin's date formatting uses the Julian calendar
for dates before 1582-10-15, when the Gregorian calendar first came
into use (in some countries, while many others continued using
Julian). This leads to discrepancies between the (Gregorian) dates we
pass it for formatting and the (Julian) dates it actually prints, that
are the same number of seconds before 1970.
Previously the QLocale system backend for Darwin already had a kludge
to work round its handling of negative years, so it suffices to extend
that to years before 1583.
Fixes: QTBUG-54955
Pick-to: 6.6 6.5
Change-Id: I70f219b73bf20c0cd63bcda2b0e99042354872ca
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This no longer is range-length preserving now, so adapt the
documentation.
For the non-contiguous iterator case, it's actually ok to always
resize(0) and then append(), because, unlike for QList and QVLA, the
resize(0) doesn't actually iterate the container to destroy
elements. It just sets some members and conveniently detach()es for
us.
The char8_t case is even more complicated, since we can, atm, not
include qstringconverter.h into qstring.h, yet qstringconverter is
required for stateful UTF-8 decoding in the input_iterator case. So
that's postponed to yet another patch, and maybe won't make it into
6.6. But I feel it's important to have at least one
non-length-preserving version of assign(it, it) in before release lest
users come to rely on this documented (and de-facto) feature of the
the step-2 assign().
Fixes: QTBUG-106198
Pick-to: 6.6
Change-Id: Id458776e91b16fb2c80196e339cb817adee5d6d9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This is an improved version of the previous attempt to remove
this 3c6c3eccd1. Now we also take
into account that concatenation of 2 null stings must also produce
null string as a result.
Change-Id: I39c270552839b056247c1cce334cef4fa8f1cfdd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Restrict the permissible value_types to those QStringView can take,
plus QLatin1Char. All of these implicitly convert to QChar and give
the correct result, even when converted char-by-char.
Task-number: QTBUG-106198
Pick-to: 6.6
Change-Id: Icb44244cb08af391161c4309467d4e0d2d3d3d62
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
The system locale backend on macOS uses system APIs to format dates
and times in localized ways. Those system APIs appear to know more
about time zones than the time_t functions (which artificially cut off
before 1900) are willing to tell us. As a result, QDateTime is left to
guess the offsets in use before 1900 but the locale-formatting takes a
correct offset into account, which can lead to QDateTime and the
locale-aware APIs using different offsets. This is further compounded
by the system APIs taking into account the calendar transition from
Julian to Gregorian. We can't do much about the latter.
Previously we were formatting dates by passing the start of the day to
the system APIs (which take a date-time, albeit using a "Date" name
for the type), along with a date-format that ignores the time of day.
For dates before 1900, if the system APIs know the offset in use was
less than that in use in the early 1900s, QDateTime (using the latter)
gets the start of the day slightly earlier than where the system APIs
know it is, so the day before is the date at that time. Use noon on
the day in question to avoid this problem, at least for zones that
didn't do whole day offset-shifts (crossing the date line) before
1900. Document the problem and the limited extent to which we can
solve it.
Task-number: QTBUG-54955
Pick-to: 6.6 6.5 6.2
Change-Id: I5be1bfdb3013433ee248846533ef73af39f173f5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Edward Welbourne
Anton Kudryavtsev
Thiago Macieira
Ahmad Samir
Mårten Nordheim
Øystein Heskestad
David Faure
Giuseppe D'Angelo
Dennis Oberst
Marc Mutz
Topi Reinio
Ivan Solovev
Morten Sørvig
Olivier De Cannière
Kai Köhne
Fabian Kosmale
Vladimir Belyavsky