Twenty-six values Forme computes and never reads

Over the past few months the same kind of bug kept surfacing in this project, always by accident and usually because a user rendered something new. A font parser read the hhea ascender and descender out of every font and stored them, and the baseline model used font size instead. A layout-pass counter was computed, returned across the WASM boundary, declared in five packages' types, and returned by one. A flex: none was parsed correctly by the CSS layer and dropped by the mapper. The engine's render warnings were destructured in a shared function and then left out of the object it returned.

None of these are bugs in the code that produces the value. That code is fine. It computes the right thing and puts it somewhere reachable. The bug is that the code which needs it never asks.

At eight or nine instances, finding them one at a time is the expensive way. So the whole tree got swept in one pass: the Rust engine, the HTML input crate, and every TypeScript package. The result was twenty-six live defects, a shorter list of deliberate deferrals where the gap is real but the choice was made on purpose, and a longer list of candidates that looked exactly like the shape and turned out to be fine.

This post is three of the twenty-six, shown rendered, and two things the sweep exposed about the checks themselves.

Why this shape is hard to see

Start with the obvious question: why doesn't the compiler catch it?

For the Rust crates, it mostly can't. dead_code analysis stops at pub. These are library crates, so almost every field is public, and a public field that nothing reads looks identical to a public field that exists for callers outside the crate. cargo clippy is clean in every configuration across both crates, on a codebase where the sweep then found fourteen real instances. A clean lint here is not evidence.

On the TypeScript side the question was never put to the compiler at all. noUnusedLocals and noUnusedParameters are off in all eighteen package tsconfigs, with no root config they inherit from. Turning both on across ten packages produces six warnings, all benign, and about four lines of edits. The door was never locked because nobody tried the handle.

What actually found these was counting read sites per field and then reading what the reads do. A field whose only "read" is its own assignment, a Default impl, or a debug-print derive is not being consulted by anything.

A border that silently cancelled fifteen other properties

This is the one that is hardest to believe from a description, so here it is rendered. Same input, same engine, two builds.

Each numbered row declares an ordinary property together with a border, padding or a background. On the left, the presence of the second property silently discarded the first. text-transform: uppercase renders in lower case. A border declared dashed paints solid. letter-spacing collapses. max-width is ignored and the paragraph runs the full column.

The cause is a function that splits a paragraph's style in two, because a text block with a background needs a wrapping box around the text node. It called the complete style resolver, then hand-copied eight properties onto the box and eight onto the text, and dropped everything else. Those two lists were correct when they were written, because sixteen properties were most of the struct at the time. Every property added since landed in neither list.

Some of those the README already documents as out of scope, so they were going nowhere regardless. The ones that matter are the properties the README documents as supported, and that work perfectly well on a paragraph without a border: border style, text transform, letter spacing, orphan and widow control, position and its four offsets, minimum and maximum width, grid placement, and vertical alignment.

That conditional is what kept it hidden. The same declaration works on a bare paragraph and stops working the moment the paragraph gets a background, so the property never looks broken in isolation.

The fix is not to add fifteen entries to a list. It is to stop keeping a list. The text node now names the handful of properties it needs, and the box keeps everything else. A property added next month lands on the box without anyone editing that function. It might land on the wrong half, which is a visible bug, instead of on neither half, which is not.

Headings and lists deleted from the document

Forme has two serializers: the normal one, and a second that compiles a template with data placeholders so a PDF can be generated later without a JavaScript runtime. They are two hand-written dispatch chains over the same set of components, and they drifted.

Headings, ordered lists, unordered lists and list items had no branch in the template serializer. They are components that return null, so each one fell through to the "unknown component, call it and see" fallback, produced nothing, and was dropped from the document along with everything inside it. No error, no warning. The document on the left is the same source file as the one on the right.

The repair followed the same principle as the border fix. The builders are written once and take a small description of which path is calling them, so a component cannot be supported by one serializer and missing from the other.

More useful than the fix is the guard behind it. The obvious test is a list of components to check, which is exactly the artifact that drifted in the first place: it covers the names somebody remembered. So the test walks everything the package actually exports, drives each component through both serializers, and asserts they agree about whether it survives. Export a component and it is covered, with nothing to remember.

Relative units that parsed correctly and did nothing

Four parse sites shared one shape: match the parsed length, handle the case where it is in points, and have no other branch. The value parsed correctly and then fell off the end of the if. gap: 1rem produced no gap while gap: 12pt worked. border-radius: 0.5rem, which is what Tailwind's rounded-lg compiles to, did nothing.

The cause sat one layer up. Those fields were typed as already-resolved point values, so a relative unit had nowhere to be stored, while width and padding in the same file kept the unit and resolved it later against the element's font size. The fix was to let the fields carry the unit and resolve them where everything else resolves.

The third row is the worst of the three, because it is not a drop. The border shorthand kept its default width when the unit did not match, so border: 0.5em solid painted at 2.25pt rather than the 6pt asked for. A wrong value, not a missing one, and no warning could have caught it because nothing in the code knew anything had gone wrong.

The byte-identity wall reported no change on two of these

Forme has a wall that renders a fixture corpus through two builds of the engine and compares the PDFs byte for byte. It exists so that a refactor which should change nothing can be shown to change nothing, and it has caught real regressions.

It reported six of six identical on both of the HTML fixes above, while both were visibly changing rendered output.

That is not the wall failing. The wall did exactly what it says. It is that the corpus did not reach the code being fixed. The dashed-border fixture carries thirteen dashed and dotted borders and not one of them is on a paragraph or a heading, so the wall never rendered the box-splitting path at all. No fixture and no shipped template writes gap: 1rem or border: 0.5em, so it could not see the units fix either.

A coverage result was sitting exactly where a no-change result appears to be, and "byte-wall identical" is a claim the commit messages lean on. So the fixture that would have spoken now exists, and it was checked against the thing it is supposed to catch: rendered across the commit pair those fixes span, the new fixture reports a difference and all six existing fixtures report nothing, on the same two binaries. On a build without the fixes it reports no difference either, which is the check that distinguishes a real coverage fixture from one that simply differs from everything.

The rule now sits in the script next to the fixture list. A wall is only as wide as its corpus, so when a fix lands with the wall silent, add the fixture that would have spoken.

Two checks that ran and measured nothing

While these fixes were being written, the same shape turned up twice in the checking itself.

The first was the guard for the deleted headings. To decide whether a component survived serialization, the test counted the nodes in the output document and asserted the count was above zero. All nine failing cases turned green. The count is above zero for every document, because the page itself is a node, so a deleted component scores exactly the same as a present one. The version that shipped subtracts the node count of the same document without the component, which measures the component rather than the wrapper.

The second was the before-and-after comparison built for this post. The first run showed no difference at all between the old build and the new one. The reason was that the branch it ran on predated the merge, so both sides were running pre-fix code. A demo that reports "nothing changed" looks exactly like a fix that does not work.

Both are the same mistake as the bug being fixed. A check that runs and measures nothing is indistinguishable from a check that passes, in the same way a value nobody reads is indistinguishable from a value that is correct. The habit that catches it is not cleverness, it is making the probe fail on purpose before believing it when it passes. Every fix in this post is pinned by tests that were verified to fail without the source change, by stashing the change and running them.

What actually surfaced these

Forme reports render defects through the same warnings channel as unsupported CSS, on the principle that if a document renders wrong and nothing names the reason, that is a bug in Forme rather than in the document. Two of the twenty-six were holes in that channel itself: the template render path discarded the engine's warnings before returning them, and the dev server shipped a complete warnings badge that nothing ever populated.

Those two are worth more than their individual severity. A defect channel that is silent on one path is worse than having no channel, because it trains you to read "no warnings" as good news on the one path where "no warnings" was the only answer it could ever give.

Each entry in the sweep has a verdict and the evidence behind it, including the candidates that looked like the shape and turned out to be fine. The three shown here are fixed and merged, and will be in the next release. The rest are being filed as issues rather than carried in someone's head, which is the entire reason for doing the sweep in one pass instead of discovering them one render at a time.