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>
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>
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>
Test names and output need to be UTF-8 for the XML data formats to not
end up malformed - which would upset Coin's testrunner, when it
validates the XML as part of checking - and the few other uses of
toLatin1() were to ASCII content anyway, so can harmlessly (this being
test code, where the slight performance advantage of Latin-1 doesn't
matter) use toUtf8() as well, for the sake of uniformity.
Use of toLatin1() broke an imminent commit in which some territory,
script and language names depart from ASCII, leading to malformed
UTF-8 when they appear in test-data-row names.
Task-number: QTBUG-94460
Change-Id: Ifb826b1e417ba24fd862b93d24d0e7a38858a17f
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
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>
It's actually testing that the system locale (which it obtains via the
default constructor, relying on setDefault() not being called first in
the helper program - which I'll soon change) behaves as expected.
Change-Id: Iedd2c1bb549288661c910dfbaac509ede9506d04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Although QSystemLocale is (to make its query enum usable) defined
despite the QT_NO_SYSTEMLOCALE define, it's not used in that case, so
tests based on it won't work. So extend the reach of the #if-ery to
include the test using a custom class based on it. Also rename the
test from systemLocale(), as that's the name the emptyCtor() test
really should have.
Change-Id: Ief69bf161251cde47ee45014cc2627d42cfcc526
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
The user might not be aware of, or able to see, the difference between
Unicode's assorted horizontal spacing characters, leading them to
expect their input to be accepted for a format despite differences in
spacing. So treat the various horizontal spacing (other than tab)
characters as equivalent when matching the separators in a date-time
format. Add a test-case that failed before this fix.
Fixes: QTBUG-114909
Pick-to: 6.6 6.5
Change-Id: I3e798d3e5b89adb8e86168ebd3954904b258d630
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
We are gradually enabling more tests for WebAssembly platform
for better test coverage.
Long linking time is no longer an issue due to test batching.
Change-Id: I7ee9f877ecda726bc23d8dd2507c616bb381ebc1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Previously only toDateTime() was tested. Adding a test-case for
toTime() provoked adding full testing for both it and toDate(), based
on toDateTime() tests.
Pick-to: 6.6 6.5
Task-number: QTBUG-114909
Change-Id: I5c24b3869b3deefc36a7125133822e8f41cd24ba
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Add the boilerplate standalone test prelude to each test, so that they
can be opened with an IDE without the qt-cmake-standalone-test script,
but directly with qt-cmake or cmake.
Boilerplate was added using the following scripts:
https://git.qt.io/alcroito/cmake_refactor
Manual adjustments were made where the code was inserted in the wrong
location.
Task-number: QTBUG-93020
Change-Id: I28b6d3815c5f43d2c33ea65764f6f3f8f129eaf3
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When matching the locale's correct exponent separator, QLocale was
doing a case-insensitive match; but the Cyrillic fall-back was
matching case-sensitively, so failed to catch the case of lower-case e
and its Cyrillic equivalent, when used in a Cyrillic font in place of
the upper-case form of the other, where that's the locale's official
separator. So make this comparison case-insensitive.
Added some test-cases for the lower-case exponential separator.
Pick-to: 6.5
Fixes: QTBUG-113443
Change-Id: I18e22d7b3451fbb61e87d5b93661eadff3c7356e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Add some tests inspired by the initial form of a bug report (before we
found out what the real issue was), that a small fraction with a large
exponent is correctly handled. This should work as long as the result
is representable, even if the fraction itself is too small to be
represented by the floating-point type.
Pick-to: 6.5
Task-number: QTBUG-113443
Change-Id: Ie004197961fc7b603e5024a6ebc5928261a0e2bb
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
I got tired of being told off by the inanity 'bot for faithfully
reflecting existing #if-ery in new #if-ery. Retain only the
documentation and definition of the deprecated define.
Change-Id: I47f47b76bd239a360f27ae5afe593dfad8746538
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Only Ukrainian is actually recorded in CLDR as using U+0415 as
exponent separator; all other Cyrillic-using locales officially use
plain ASCII 'E'. However, it seems reasonable, in all Cyrillic
locales, to recognize both (given that they look very similar).
Task-number: QTBUG-107801
Change-Id: I70a1e60a2d9fe7e254e01d32c5bad909ea4b8c76
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
In some locales signs and the exponent are not single character
tokens. Replace QLocaleData::numericToCLocale() with a tokenizer that
will cope with this. At the same time, cache the locale data needed in
support of that, so that we don't repeatedly recreate QString()
objects just to compare them against input tokens.
The caching class is inspired by Thiago's proposal for fixing the
performance, which also inspires the optimization of the C locale in
the tokenizer used here.
Add some testing that round-tripping numbers via strings works for the
locales with signs and exponents that use more than one character.
Task-number: QTBUG-107801
Change-Id: I9fd8409a371ed62ed969d9ebc8b09584e752f7fb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
New languages (and one local for each) added with v42
- Haryanvi
- Moksha
- Northern Frisian
- Obolo
- Pijin
- Rajasthani
- Toki Pona
It also appears that Canada has changed its date format. Modify the
relevant test case to reflect this change.
Task-number: QTBUG-110333
Pick-to: 6.5
Change-Id: Ia8975c2866cd54c9e565543d05bacd52f4987909
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
TIME_NOSECONDS doesn't really switches to short time format,
just removes the seconds from long time format
Fixes: QTBUG-110627
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: Ie799958f3942c657f00bc8196588258661ddc1d9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For most territories, if we specify only that territory, we should get
a locale specific to that territory. There are exceptions for various
reasons, but check that it's true in most cases, at least. In the
process, convert two QVERIFY(... == ...) into QCOMPARE(..., ...)
Task-number: QTBUG-64940
Change-Id: I7590f20f37b0b459aafb3d1d08f6eb77932fa027
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Not all locales use ASCII hyphen-minus U+002D as minus sign. On macOS
using the nb_NO locale the U+2212 character is used instead when
displaying negative years. Verify that one of the two characters is
found.
Fixes: QTBUG-109853
Change-Id: I424539cc8d427ac199b4528e44bef98e45312d07
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This saves (mostly in corelib/time/) some complications that used to
arise from needing different code-paths for different time-specs.
Task-number: QTBUG-108199
Change-Id: I5dbd09859fce7599f1ba761f8a0bfc4633d0bef9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Underflows should be treated the same as overflows.
Fixes: QTBUG-108628
Change-Id: I23aa7bbe1d103778cefca08bd3e584e72f306583
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Rework QSimpleParsedNumber to store a qsizetype whose sign serves as
ok flag (positive is ok, zero and negative are not) and magnitude is
the number of characters used. This replaces an endptr that was set to
null to indicate !ok, but that deprived us of end-of-parse
information, which is needed for number-parsing. In particular, JS's
parsing of numbers accepts overflow (where qstrntod() flags it as
invalid) as infinity; so qstrntod() does need to say how long the
overflowing (but JS-valid, none the less) number-text was.
Modify all callers of functions using this (recently-introduced) type
and add tests that fail without this fix.
Fixes: QTBUG-108628
Change-Id: I416cd213e1fb8101b1af5a6d43615b970a5db9b4
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This tests that strings using the first Unicode code-point of such a
multi-character token don't get recognized as "valid" number strings.
This would catch an implementation issue if the parsing code
mistakenly matched against only the first code-point of each "single
character" token.
It also adds tests of integer formatting, with multi-character sign,
and reworks some QStringView().toString()s to use u"..."_s.
Task-number: QTBUG-107801
Change-Id: I7b868ce2955bb322b3ecfc200438a21437090a0c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some of the entries in QLocale's single_character_data[] table are
not, in fact, single characters; some RTL languages include
bidi-markers in some of the fields, some locales use some denotation
of "times ten to the power" as the exponent separator. There may be
further complications, but let's just get some tests in that verify we
are correctly serializing numbers in these locales. Include some
parsing tests to show that we are indeed failing them.
Task-number: QTBUG-107801
Change-Id: Iab9bfcea5fdcfcb991451920c9531e0e67d02913
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
And remove the platform-specific code.
fenv is available since c++11.
Change-Id: Ia5540be93b54117d4b5e9c7579100039c151dcc5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The collection of translations available to us need not have anything
to do with whether CLDR has matching data, so preserve the system UI
language list's entries as they are, rather than forcing them through
the QLocale constructor's exercise of likely sub-tag rules.
Instead, simply parse the given locale tags to QLocaleId instances and
use these in the likely-subtag processing to determine what other
entries to add to the list in addition to those supplied by the
operating system. Since going via QLocale did usually supply a
territory, that was included in the BCP 47 name, it's now possible for
the given entry to lack the language_territory name, so be sure to add
that if missing.
This incidentally reduces heap traffic and saves a fair deal of hidden
likely-subtag processing in calls to the constructor and bcp47Name().
Expand testing of QLocale::uiLanguages(), both plain and system. In
the process, cross-link the two closely-related tests, move a comment
on one's _data() to the other's, where it really belongs, and add
reporting of the actual lists on failure. Enable MySystemLocale to
remember the requested locale's ID, before likely sub-tag processing,
so that we can make query() report results for language, script and
territory as requested, to ensure the fake system locale really does
match what was requested. The new german-britain test failed without
it, because there is no de-GB locale in CLDR.
Task-number: QTBUG-99531
Change-Id: Ide041577772c442a4413e3b9a590e11140c48f49
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Have QSystemLocale manage a stack, so that tests can install an
over-ride for the actual system-specific one reliably and restore the
system-specific one when finished. Leave the QSystemLocaleSingleton
out of the stack, all the same. In the process, mark the QDoc comments
for QSystemLocale all as \internal, since this is not public API.
Change-Id: I8faed49780215e42f32be10cf936c32bb46105bf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When the system locale is en_DE, macOS seems to think we should use
en_GB as the right translation. While that probably is a sensible
choice in the absence of an en_DE translation, we should definitely
use the en_DE translation if available, especially if en_GB isn't
available (which lead to a fall-back to de_DE, given later entries in
macOS's list). So prepend the system locale's own pcp47Name() if it
(isn't the C locale and) is missing from what we would otherwise have
used for uiLanguages(), after likely sub-tag perturbations.
Add a test simulating (some approximation to) what macOS was doing
that would have caught this case; and add a scope-guard reporter to
the test to report what shows up when lists don't match.
Fixes: QTBUG-104930
Pick-to: 6.4 6.4.0 6.3 6.2 5.15
Change-Id: I116234708067e1717d9157aebc84da76e04a9f38
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Certain masks are not supported outside 32-bit x86, and will assert on
x64.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-106000
Change-Id: Ic9f58e5a19c1db3309edeb5ec529e7a78c929665
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Also document the (seldom helpful) handling of over-long repeats of a
format. Add test to QDateTime and amend QLocale test.
[ChangeLog][QtCore][QDateTime] Doubling the 'z' format in a date-time
or time format string now produces the same output as a single 'z'.
Previously, this would have produced two copies of the milliseconds
field (eliding any trailing zeros in each). Contrast with 'zzz', which
produces the full milliseconds field, including any trailing zeros.
Change-Id: I4c60462b062fee4079370096d745c191c1939506
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Some languages have, in the same territory, locales for more than one
script. In such cases, since we ignored the script, we got the one
that is used by default, instead of the one actually asked for. Take
the script into account.
Added TODO comment in test listing the known examples of this;
manually tested before and after the fix to verify the prior code was
indeed getting it wrong and now does do it right.
Change-Id: Iaf9201d6992bc39e6e9346ef8b7c69d418db7253
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The documentation overtly listed entries in this order but the code
gave less specific entries before more specific (and the tests
verified the same). This is now reversed.
[ChangeLog][QtCore][QLocale] uiLanguages() now prefers more specific
locale names over less specific ones, matching its own documentation,
except where the system backend supplies them in some other order.
This means a translation with the expected script and/or territory as
well as language will be used in preference to a generic one for just
the language, rather than only as a fall-back when the more generic
one is missing.
Fixes: QTBUG-102796
Change-Id: I3c7b3627afb51246df5a6ad0230e23b60af78071
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
When the date-time string falls in a spring-forward (so is invalid)
and one of the fields of the parsed string doesn't match the format
it's meant to (e.g. a single-digit seconds field when format ss was
specified), a check that the current fall-back date-time is between
the minimum and maximum for the parser object failed, triggering an
assertion.
In any case, an invalid default-value wasn't useful to the code that
parsed a single section of the date-time string, so brute-force the
current value to a valid date-time (when possible) using the usual
round-trip via milliseconds since the epoch.
Added the test-case which first revealed the problem, plus a couple
more informed by it, to exercise the same code-paths with fewer things
failing.
Fixes: QTBUG-102199
Pick-to: 6.3 6.2 5.15
Change-Id: I658308614505ef25f4c97d0de6148acb54a65a0f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Update docs and add tests.
[ChangeLog][QtCore] Documented existing support for 'F' format when
converting floating-point numbers to strings in QLocale::toString(),
hence equally for QString's floating-point formatting. Previously it
was supported but the documentation neglected to mention it; it only
differs from 'f' for infinities and NaN.
Change-Id: Ic946c0f7b9e86fdf512daa3124bea57fc664b34b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
The testing of infinity and NaN somewhat duplicated existing tests in
tst_QNumeric and, in any case, belongs there.
Change-Id: I6b5d1ff9767daf8e4bbe0025d3efab3d74ed35de
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
