Find the undrawable glyphs by parsing the source, not by listing them

[JamesKane]

What was wrong

The boxes on the Genealogy card were ✕ (kit-remove, MDKA-remove) and ✎ (MDKA-edit). The last round of this fixed the locale catalogs and stopped there — but icons are not translated copy, they are bare literals in the source, and ui.small_button("✕") is invisible to a scan of en.txt.

Reading the sources instead found ~20 more that no screenshot had reached yet: every clear-filter ✕, the Y-STR agreement ✓/✗, the sortable-table sort arrows ▲/▼, the unread dots on threads and DMs, the match-strength meter, the STR group banner ▸, and → in a dozen status lines.

Every replacement was probed against the actual fonts rather than chosen by eye — ✕ (U+2715) sits one codepoint from ✖ (U+2716) and only the latter has a glyph, which is precisely how this recurs:

was	now
✕ ✎ ✓ ✗	✖ ✏ ✔ ✖
● ○	⚫ ⚪
▲ ▼ ▸ →	⏶ ⏷ ▶ ›

Two of them were in navigator-app, not the UI crate: a consensus warning and the import summary's reference notes, both built there and drawn by egui via sources.rs and events.rs.

The part meant to outlast it

every_source_string_literal_is_renderable parses this crate's own sources with syn and checks every string literal against egui's own fonts, so a new icon is covered the moment it is typed rather than when someone remembers to extend a list.

Parsing rather than grepping is what makes that safe — comments are full of → and ◆ naming the very bug they describe, and the AST has literals and no comments. Two things had to be right for it to see anything:

• doc comments arrive as #[doc = "…"] attributes, and
• syn hands macro bodies over as an unparsed TokenStream, which would have hidden nearly every label in the app, since they are built by format!.

The first version had that second hole and passed vacuously. It is only trustworthy because a bad glyph was injected into a format! and the test was watched failing with both codepoints named, before being reverted.

Scope, deliberately

The gate covers navigator-ui only, and the doc comment says why rather than papering over it: navigator-app also feeds the CLI and the HTML exporter, where → and ✓ are correct, so which of its strings reach a window is a dataflow question rather than a syntactic one. cli.rs and #[cfg(test)] modules are excluded here for the same reason — a terminal renders in the user's own font.

Verification

cargo fmt --all clean · cargo clippy --all-targets -- -D warnings clean · cargo test --workspace all green (0 failed).

Worth a glance in the running app

⏶/⏷ are heavier than the ▲/▼ they replace, and ⚫/⚪ are chunkier than ●/○ in the match-strength meter. They were the only drawable options in that shape family.

🤖 Generated with Claude Code