render/forms: tst_i18n.qml still embeds five raw bidi controls, in the half of the file #630 added

[Yaraslaut]

Found during the landing sweep that merged #630, while checking #628's premise. Filed rather than folded, per AGENTS.md — and filed although it contradicts a PR this sweep had just merged, which is the case AGENTS.md calls out explicitly.

The finding

#630 (513145a1, "escape the bidi controls in the QML i18n tests", fixes #610 and #591) escaped one half of src/qt/forms/tests/tst_i18n.qml and left the other half raw. The raw survivors are in the code that PR added for #591.

Verification status: reproduced on master @ 513145a1

Five lines carry raw U+200E / U+200F bytes:

$ grep -nP '[\x{202A}-\x{202E}\x{2066}-\x{2069}\x{200E}\x{200F}]' src/qt/forms/tests/tst_i18n.qml | cat -A
284:  compare(Qt.locale("az_IR").positiveSign, "M-bM-^@M-^N+M-bM-^@M-^N")
309:  compare(localeForm.normalizeLocaleNumber("M-bM-^@M-^N+5", ".", "", "-", "M-bM-^@M-^N+"), "5")      // ar_DZ
310:  compare(localeForm.normalizeLocaleNumber("M-bM-^@M-^N+M-bM-^@M-^N5", ".", "", "-", "M-bM-^@M-^N+M-bM-^@M-^N"), "5")  // az_IR
311:  compare(localeForm.normalizeLocaleNumber("M-bM-^@M-^O+5", ".", "", "-", "M-bM-^@M-^O+"), "5")      // ckb_IQ
318:  compare(localeForm.normalizeLocaleNumber("M-bM-^@M-^N+M-bM-^@M-^N5", ".", ""), null)

$ grep -cP '…' src/qt/forms/tests/tst_i18n.qml
5

M-bM-^@M-^N is E2 80 8E = U+200E LEFT-TO-RIGHT MARK; M-bM-^@M-^O is E2 80 8F = U+200F RIGHT-TO-LEFT MARK.

The same file uses the escaped form 13 times, so this is an inconsistency inside one file rather than a convention nobody adopted:

$ grep -c '\\u200' src/qt/forms/tests/tst_i18n.qml
13
226:  compare(signForm.normalizeLocaleNumber("‎−5", ".", "", "‎−"), "-5")  // fa_IR
227:  compare(signForm.normalizeLocaleNumber("‎-‎5", ".", "", "‎-‎"), "-5")  // az_IR
228:  compare(signForm.normalizeLocaleNumber("‎-5", ".", "", "‎-"), "-5")  // ar_DZ

Lines 226–234 are the negative-sign block — #610's original subject, escaped exactly as asked. Lines 284–318 are the positive-sign block — #591's addition, raw. Both landed in the same commit.

What I did not verify: whether the five raw spellings are deliberate — e.g. a case meant to prove the parser handles a raw literal. I read the surrounding comments (lines 276–286, 314–320) and found no statement to that effect; they explain why a bidi-prefixed sign is two or three UTF-16 units, not why these five are written raw while their thirteen neighbours are escaped. If a reason exists, it was not written down, which is itself worth fixing given that #610's whole argument was that an invisible character in a source file is a maintenance hazard.

Why it matters beyond tidiness

#610's case was that a reviewer cannot see these characters, so a wrong one survives review. That is precisely what happened here: the PR closing #610 introduced five more, and the review — mine included — did not catch it, because the diff renders them invisibly.

#628 already argues that no lint keeps raw bidi controls out of first-party sources and notes "the authoring path that introduces them was hit twice while fixing #610". This is the third time, in the merged result. This issue is evidence for #628, not a substitute for it: fixing these five lines without the lint leaves the next occurrence to be found by whoever next greps for it.

What would change the verdict

• Close as invalid if the five raw spellings turn out to be deliberate and a comment saying so is added — the requirement is that the reason be written down, not that the bytes change.
• Close as resolved when the five are escaped and 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's lint exists to keep them out; escaping them alone re-opens the same gap for the next edit.

Related

• tst_i18n.qml embeds raw invisible bidi control characters in its assertions, while its C++ mirror escapes them #610 — the original ticket, closed by render/forms: escape the bidi controls in the QML i18n tests, and support native digit sets at both control edges (fixes #610, fixes #591) #630.
• render/forms: support native digit sets at the control edge, via a NumericLocale aggregate carrying a digit base #591 — the positive-sign support whose new cases carry the raw controls.
• 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 — the missing lint, which is the durable fix.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Closing as invalid — this was my measurement error, not a defect

#630 escaped all of them. The tree has never carried these characters since it landed. Ground truth, counting codepoints with Python rather than a grep, over the stored blobs:

blob @ a8511aa6   lines_with_raw_bidi=9   [283, 284, 308, 309, 310, 311, 317, 318, …]
blob @ 513145a1   lines_with_raw_bidi=0   []
blob @ c55ea5b7   lines_with_raw_bidi=0   []
worktree file     lines_with_raw_bidi=9   [283, 284, 308, 309, 310, 311, 317, 318, …]

a8511aa6 is the revision before #630; 513145a1 is #630 itself; c55ea5b7 was master when I filed this.

What went wrong: my local checkout was still at a8511aa6. I had merged the four PRs through the API and run git fetch, which updates origin/master but not the working tree — so every path I grepped was the pre-fix revision, and I attributed the result to post-merge master. The file I was looking at was the one #610 described, exactly as #610 described it. git status showed the file unmodified, which it was, against the stale HEAD I was on.

This is the failure mode the runbook names first — "A fast-forwarded main checkout matters: triaging or dispatching against a stale tree produces stale verdicts" — and I did not apply it to myself. Checkout is now fast-forwarded to c55ea5b7.

Two details worth recording, since they made the wrong answer look solid:

1. The count I published was five lines; the true count at that revision is nine. grep -P under the ugrep this machine aliases to grep under-reported, and it also reported 0 for the same bytes when they arrived on a pipe rather than as a file — same blob hash, same byte count, different answer. Any bidi measurement on this machine should use a codepoint-level reader, not grep -P.
2. The signature in my excerpt (normalizeLocaleNumber(s, ".", "", "-", sign), positional) does not exist on master, which has an options object. That was visible in what I quoted and would have caught this, had I read my own evidence against the current file.

#628 is unaffected in substance — no bidi lint exists, which I have re-checked on c55ea5b7 (ls scripts/ | grep -i bidi → nothing). What this issue removes is the "and here are five live examples" part of its argument, which was never true. I have posted a correction there.

Closing triage: invalid. Re-open only if a raw bidi control is measured in a tracked file at a revision named explicitly, by a codepoint-level reader.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW