Formatter: discarded `checked_sub` never reserves separator width in one-per-line `SeparatedExprs`

[prql-bot]

The nightly code-quality survey flagged a discarded computation in the code formatter that looks like it was meant to reserve width for a trailing separator but doesn't.

In SeparatedExprs::write, the one-per-line branch does:

opt.reset_line()?;
opt.rem_width.checked_sub(self.line_end.len() as u16)?;   // result discarded

r += &expr.write(opt.clone())?;
r += self.line_end;

codegen/mod.rs:168-172

checked_sub is non-mutating, so its result is thrown away — the line only functions as an underflow guard (via ?), it never actually reserves the line_end width before expr.write. Compare the sibling write_inline path, which uses the mutating consume_width to charge width against rem_width.

line_end is "," for tuples and arrays (ast.rs:103-114). Because the separator width is never reserved, an element that exactly fills the remaining width leaves no room for the trailing ,, so that formatted line can exceed max_width by one character.

This is a minor cosmetic edge case, not a correctness bug in the emitted PRQL. But the current line is either a latent off-by-line_end.len() bug (should be opt.consume_width(self.line_end.len() as u16)?; to actually reserve the separator) or the reservation is unwanted and the line is redundant. Which of the two is the intended behavior is a formatter-design call, and changing it would shift fmt snapshot output for elements near the width boundary — so flagging for a maintainer decision rather than opening a speculative PR.

Found during the nightly survey of codegen/mod.rs.

[prql-bot]

Reproduced the off-by-one, and the investigation turns up a wrinkle worth recording before anyone reaches for the obvious fix.

Reproduction (default max_width = 50). A nested tuple sized to sit exactly at the boundary overflows by one:

$ echo 'let x = [{<22×a>, <22×b>}]' | prqlc fmt
let x = [
  {aaaaaaaaaaaaaaaaaaaaaa, bbbbbbbbbbbbbbbbbbbbbb},   ← 51 chars (max_width is 50)
]

The inner tuple's inline form is 48 chars; with indent (2) it fills rem_width exactly, so the trailing , spills one over.

The obvious fix isn't clean. Swapping the discarded checked_sub for the mutating opt.consume_width(self.line_end.len() as u16)? does not produce the tidy one-per-line-inner wrap you'd hope for. Because the inner tuple then no longer fits the (now correctly reserved) slot, expr.write returns None, which bubbles up through write_or_expand's ? and re-renders the whole statement inline at a grown width:

# with opt.consume_width(...) applied:
let x = [{aaaaaaaaaaaaaaaaaaaaaa, bbbbbbbbbbbbbbbbbbbbbb}]   ← 58 chars

So the "fix" trades a 1-over one-per-line line for an 8-over inline line — arguably worse. Getting the intended rendering (inner tuple wrapped one element per line, every line ≤ 50) would take more than the one-line change; the expansion fallback swallows the local wrap. That makes this a genuine formatter-design decision, not a mechanical correctness fix — consistent with the original framing here.

One data point in the fix's favor: applying consume_width shifts zero existing snapshots — the full prqlc suite (471 tests) stays green. The test corpus has no elements sitting on the boundary, so nothing regresses; the change is purely latent-edge-case behavior.

Details & method

• Buggy line: codegen/mod.rs:169 — opt.rem_width.checked_sub(...) computes and discards; only functions as an underflow guard, which reset_line makes near-unreachable.
• Sibling inline path reserves separator width correctly via consume_width.
• Expansion fallback that swallows the local wrap: write_or_expand.
• Before/after captured by building prqlc fmt with and without the consume_width change and diffing output over a sweep of nested-collection widths; the flip happens at inner-inline-width 48. Atomic-ident elements (e.g. [<48×a>]) show no visible change — they can't shorten, so both versions expand to the same 51-char line.

Leaving the design call (reserve-and-accept-the-expansion vs. drop-the-redundant-line vs. a smarter wrap) open rather than shipping a speculative snapshot-shifting change.