render/forms: escape the bidi controls in the QML i18n tests, and support native digit sets at both control edges (fixes #610, fixes #591)

[Yaraslaut]

Two commits, one per ticket, in this order deliberately: #610 is mechanical and
lands regardless, and doing it first meant #591's edits landed on already-escaped
source.

fixes #610
fixes #591

---

1. forms/tests: spell the bidi controls in tst_i18n.qml as escapes (#610)

Nine assertion lines in src/qt/forms/tests/tst_i18n.qml embedded U+061C,
U+200E and U+200F as raw code points while the morph#583 block sixty lines
above, the corpus #609 added, and the C++ mirror in
tests/test_render_locale_format.cpp all spell the same characters explicitly.
Seventeen raw code points become \uXXXX. No string value changes.

How that was proved, since the suite cannot prove it. A green run is not
evidence here: a mangled invisible character still leaves the suite green,
because ASCII '+' is accepted in every locale by design (morph#596). So:
every double- and single-quoted literal in the file was extracted and its
QML/JS escapes decoded, before and after, and the two hex dumps of the decoded
values are byte-identical (408 literals). Negative control — a harness that
drops one ‎ from the converted file is detected by that same comparison,
so it is measuring something.

The issue's own acceptance command:

$ grep -cP '[\x{061C}\x{200E}\x{200F}]' src/qt/forms/tests/tst_i18n.qml
0
$ grep -rlP '[\x{061C}\x{200E}\x{200F}\x{202A}-\x{202E}\x{2066}-\x{2069}]' src/ tests/ examples/
(no output)

The repo-wide lint the issue floats as optional is deliberately not here —
it is a policy decision. Filed as #628 instead, with evidence: I hit the
opposite-direction version of the same hazard twice while writing #591.

2. render/forms: carry the locale facts in a NumericLocale (#591)

normalizeLocaleNumber compared one byte against ['0','9'], so a user of any
locale whose digits are not ASCII could not enter a number at all — a flat
rejection, not a wrong value. formatCanonicalNumber was its consistent
inverse: it copied the canonical ASCII digits out and wrapped them in the
locale's separators and sign. That is why the pair round-tripped and the gap
was invisible from either side alone, and it is why both edges and both QML
mirrors move together.

The measurement the issue left open

Which of Qt's 711 locales actually use non-ASCII digits was not
enumerated. The original defends 24 from sign data only and says so.

Now measured, QLocale::matchingLocales under Qt 6.11.2:

zeroDigit	locales	e.g.
U+0030	604	C
U+0660	26	ar_BH
U+06F0	19	fa_IR
U+1E950	12	ff_Adlm_BF
U+0966	8	bgc_IN
U+09E6	4	as_IN
U+11136	2	ccp_BD
U+07C0 / U+0F20 / U+1040 / U+1C50 / U+ABF0	1 each	nqo_GN, dz_BT, my_MM, sat_IN, mni_IN

76 of 711, across eleven sets. Two of them (Chakma, Adlam) are outside the
BMP, so a digit is four UTF-8 bytes and two UTF-16 units — which is why both
scans decode a code point rather than comparing a unit, and why the test
corpus includes them.

The aggregate, and the suppression

struct NumericLocale {
    std::string_view decimalSeparator = ".";
    std::string_view groupSeparator;
    std::string_view negativeSign     = "-";
    std::string_view positiveSign     = "+";
    std::string_view zeroDigit        = "0";
};

Both edges take it; the QML mirrors take the parallel object literal. No
back-compatible positional overload — two spellings of one call is how the two
edges drifted apart to begin with.

The NOLINTBEGIN blocks are gone, and that was verified rather than
assumed. There were three suppressions of
bugprone-easily-swappable-parameters in the header (on normalizeLocaleNumber,
on formatCanonicalNumber, and on detail::leadingSign). Before touching
anything I copied the header, stripped every suppression marker, and ran
clang-tidy 22.1.8 under this repo's own .clang-tidy:

locale_format.hpp:189:67: error: 2 adjacent parameters of 'leadingSign' of similar type ('std::string_view') are easily swapped by mistake [bugprone-easily-swappable-parameters,...]
locale_format.hpp:318:71: error: 2 adjacent parameters of 'normalizeLocaleNumber' of similar type ('std::string_view') ...
locale_format.hpp:441:56: error: 2 adjacent parameters of 'formatCanonicalNumber' of similar type ('std::string_view') ...

Three sites, matching the three suppressions exactly — so the check does fire
here, and deleting the markers is not a no-op. After the change, with no
suppression of that check anywhere in the header, the same command reports
nothing at all, across the full check list. detail::leadingSign now takes
(rest, const NumericLocale&), which is why its block could go too.

One methodological note that cost me a wrong conclusion and is worth passing
on: this only reproduces when the header's path matches HeaderFilterRegex
(include/morph/.*). Point clang-tidy at a copy under another path and it
reports nothing, silently.

Behaviour

• Entry accepts a digit in [zeroDigit, zeroDigit+9] or in ['0','9'];
  display emits only the locale's. The header states this next to the existing
  sign reasoning, because it is morph#596's rule applied to digits: the
  locale's own digits are on the user's keyboard only if their keyboard has
  them, and an extra accepted spelling cannot change a value because the
  canonical output always spells digits in ASCII.
• Mixed-digit entry is rejected. "٥5" is malformed, not "55" —
  the recommended choice, matching the existing "a sign anywhere but the leading
  position is malformed" strictness. Pinned by a test on each edge, since
  accepting it was equally implementable.
• An empty or undecodable zeroDigit reads as ASCII "0", the reading an empty
  negativeSign gets.

Default output is byte-identical — asserted, not assumed

A 1680-case sweep (14 locale configurations × 60 entries × both edges, including
malformed UTF-8) run against the pre-change header and against this one produces
identical output. Negative control: removing the decoder's overlong-encoding
guard changes 13 of those rows, so the sweep measures something — and that guard
is load-bearing for exactly this reason. The digit test is a range test on a
decoded code point, so a lenient decoder would read the overlong C0 B5 as the
digit '5' in the default locale, where the old byte-range scan rejected it.

The acceptance test, and why it has two halves

A round trip over a native-digit corpus, on both edges, over all eleven sets:

normalizeLocaleNumber(formatCanonicalNumber(canonical, loc), loc) == canonical

asserted byte-for-byte, and the intermediate display text asserted to
contain no ASCII digit. The second half is not decoration. The round trip alone
does not fail for the half-fix this ticket exists to prevent — if only the
entry edge moved, display still emits '5', entry accepts ASCII digits, and the
round trip passes. Mutation-checked rather than argued; each edge reverted in
turn, plus the mixing rule:

mutant	result
C++ display edge reverted	2 cases / 100 assertions fail
C++ entry edge reverted	4 cases / 106 assertions fail
C++ mixing allowed	1 case fails
QML display edge reverted	test_theDisplayEdgeEmitsTheLocalesDigits, test_thePairRoundTripsThroughEveryMeasuredDigitSet
QML entry edge reverted	4 functions fail
QML mixing allowed	test_anEntryMayNotMixDigitFamilies

The C++ display mutant's real output is the defect shape from the issue body:

CHECK( formatCanonicalNumber("-1050.25", {...ar_BH...}) == "\xD8\x9C-\xD9\xA1..." )
with expansion:
  "؜-1٬050٫25" == "؜-١٬٠٥٠٫٢٥"

The display edge also cross-checks against Qt itself: the bytes asserted for
ar_BH are exactly what QLocale("ar_BH").toString(-1050.25) produces.

Local results (incomplete — CI not waited on)

• morph_tests: 1548 cases / 22880 assertions, 1 failed-as-expected (pre-existing).
• [locale] subset: 403 assertions in 49 cases.
• QML suite: 292 passed, 0 failed (284 before; +8 functions).
• Doxygen with WARN_AS_ERROR = FAIL_ON_WARNINGS: clean.
• qmllint: clean bar one pre-existing WizardView.qml warning.
• clang-tidy 22.1.8 over locale_format.hpp: clean, with no suppression of
  bugprone-easily-swappable-parameters in the file.

Findings filed, not folded in

• clang-tidy 22 reports cppcoreguidelines-pro-bounds-avoid-unchecked-container-access on locale_format.hpp, which the repo's own config makes an error #626 — clang-tidy 22 reports
  cppcoreguidelines-pro-bounds-avoid-unchecked-container-access on this header
  at 0e3b8823, which the repo's own config makes an error. The #591 rewrite
  happens to remove that line as a side effect; the issue is about the policy
  and the tree-wide sweep, not that line.
• No lint keeps raw bidi controls out of first-party sources, and the authoring path that introduces them was hit twice while fixing #610 #628 — no lint keeps raw bidi controls out of first-party sources. tst_i18n.qml embeds raw invisible bidi control characters in its assertions, while its C++ mirror escapes them #610
  deferred it; I hit the opposite-direction version of the hazard twice writing
  render/forms: support native digit sets at the control edge, via a NumericLocale aggregate carrying a digit base #591, which is the evidence the issue carries.
• Qt.locale(displayLocale) silently resolves a script-split locale name to the wrong digit set (ff_BF, mni_IN) #629 — Qt.locale(displayLocale) silently resolves ff_BF and mni_IN
  to the wrong digit set, because the name drops the script subtag. Reported
  as weak evidence: reproduced in Qt, no demonstrated morph consumer.

Still not verified

Whether any shipped rung is configured to an affected locale — the issue's own
priority-raising trigger — remains unanswered. I measured the locale set, not
the rung configurations.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AbwhcguQFkhvVi2AH19sWk

[Yaraslaut]

[codecov]

Codecov Report

❌ Patch coverage is 97.67442% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
include/morph/render/locale_format.hpp	97.67%	1 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[Yaraslaut]

Landing sweep, 2026-09-20 21:30 CEST — rebased, not merged.

The previous run (35502221064) was red on 5 of 51 checks, and its logs are purged — gh api .../jobs/106060003242/logs returns BlobNotFound, so there is nothing left to read. Only one of the five named a failing step at all:

Linux / all optional features (clang)   → Test (offscreen Qt platform)

The other four (Application ladder, Application ladder / ASan+UBSan, Linux / all optional features (gcc), Linux / clang-ubsan) recorded no failing step and all completed within 51 s of each other (10:15:11Z–10:16:02Z), which is the shape of a cancellation rather than five independent defects. That is inferred from the job timings, not measured — the logs that would settle it are gone.

Staleness verdict: rebase, on the gate limb of the test. Since this PR's base (0e3b8823), master has moved .github/workflows/ci.yml, drift-guard.yml, suppression-guard.yml, CMakePresets.json and added check_workflow_option_coverage.py, check_nolint_directives.sh and its self-test. Its CI was judged by rules that no longer exist. #617 also landed in that window, so a red leg now names every failing test rather than the first — a rebased run diagnoses itself better than a re-run of the old one would.

Rebased onto a8511aa6, cleanly, no conflicts. The three newly-landed gates this branch had never been judged by were run locally against the rebased tree first:

NOLINT directive lint OK: 165 NOLINTNEXTLINE directive(s), all annotating code.
ok: 7 structured citation(s) in scripts/mutation_survivors.json resolve to the line they name.
(check_workflow_option_coverage.py: every declared MORPH_BUILD_* option accounted for)

So the new gates are not the cause. Not verified: the Qt offscreen test itself — not built locally. If the fresh run is red on Test (offscreen Qt platform) again, it is a real defect in this branch and the next sweep will dispatch a lane with the surviving log.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW