No actionable comments were generated in the recent review. 🎉

• Fix all pre-merge checks with AI

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Merging this PR will degrade performance by 10.1%

❌ 1 regressed benchmark
✅ 65 untouched benchmarks

Performance Changes

_{Comparing rawsun007:fix/format-parse-error-messages (21857cc) with main (82cd595)}

Took this one — it was the case I had deliberately left out, and it turned out to be smaller than "heavy lift" suggested.

The mechanism is not a missing parser state. parse_literal already reports UnescapedStartBracketInLiteral for a brace that was not doubled; FormatString::from_str then discards that error with or_else and retries the text as a field, so what surfaced was parse_spec's UnmatchedBracket. So the specific error existed and was thrown away — which is also why the previous commit could map the variant but not trigger it.

CPython's rule is whether anything follows the brace:

"{"    "a{"     Single '{' encountered in format string
"{s"   "a{b"    expected '}' before end of string
"{0"            expected '}' before end of string

parse_spec now returns the literal error when the text is the brace on its own, and UnmatchedBracket otherwise. Ten cases checked against CPython 3.14.0, including {{, {{}}, {} and {0} so the escapes and the working paths are covered.

Two tests, since this is now a parser change rather than a message mapping:

• format_parse_lone_start_bracket in crates/common/src/format.rs pins both directions at the parser level ({, a{ → UnescapedStartBracketInLiteral; {s, a{b, {0 → UnmatchedBracket).
• The snippet asserts the four resulting messages, and passes under CPython too.

The existing format_parse_fail assertion for "{s" is untouched and still passes. cargo test --workspace (42 binaries), -m test test_str, and cargo fmt --check are all clean.

Your web-query citation for the "{" message matches what I measured locally, so no disagreement there.

One case from the same family stays generic on purpose, and I would rather flag it than fix it badly: UnknownConversion is raised both for a multi-character conversion ({0!xy}, CPython: "expected ':' after conversion specifier") and an empty one ({0!}, "unmatched '{' in format spec"). One variant cannot carry both messages, so distinguishing them needs the parser to report which it hit — a separate change from this one.

(I am Claude Code, working through @rawsun007's account; disclosure is in the PR body and the commit trailers.)

On the CodSpeed regression — I measured it rather than reasoning about it, and I do not think this diff can be the cause.

The benchmark cannot reach the changed code. benches/benchmarks/gc_traversal.py builds nested lists and calls gc.collect(); it contains no str.format, f-string or % formatting at all (grep -cE '\.format\(|f"|%' → 0). Both changed functions run only when a format-string parse has already failed: ToPyException for FormatParseError maps an error to a message, and the parse_spec branch is in its else. Nothing on a success path moved, and no allocation, layout or type changed.

Local A/B against the same base. Built 82cd595 (the base in the report) and HEAD, and timed 20 GC loops of that benchmark's own body, discarding the first run as warm-up:

base (82cd595)   0.20  0.20
HEAD             0.20  0.20  0.20  0.21  0.21

Median 0.20s either side, spread ±0.01s. No 10% signal — though I would not read a laptop wall clock as refuting a CI measurement on its own; it is the unreachability above that I would rely on.

The report also flags its own caveat: "⚠️ Different runtime environments detected — Some benchmarks with significant performance changes were compared across different runtime environments, which may affect the accuracy of the results." gc_traversal is the one benchmark that moved, out of 66.

That run compared 21857cc; a180ef0 has since been pushed, so a fresh run may settle it either way. If it comes back and a maintainer still sees a real signal, I will happily dig further — and if it is judged noise, the acknowledgement on CodSpeed needs someone with access to that dashboard, which I do not have.

(Claude Code, working through @rawsun007's account.)