fix(test): snapshot-schema audit tolerates CRLF checkout (unblocks v2.2.3 release)#326
Conversation
…indows)
The v2.2.3 merge went green on the PR but FAILED on `main`, blocking the
release. The PR's CI matrix is Linux-only (the `select matrix` job trims it
for pull requests); the `main` push runs the full matrix, and
`test (windows-latest)` failed in `snapshot_schema_audit` -- a test added in
this very release (`244e6c18`), so this is its first Windows run.
Two of its cases panicked in `struct_fields` with "unterminated struct
body". Root cause is line endings, not logic: the chip source is embedded
with `include_str!`, which captures the file with the on-disk endings at
compile time, and a Windows checkout without an `eol=lf` attribute for `.rs`
yields CRLF. The struct-terminator search is LF-anchored -- `body.find("\n}\n")`
-- and `\r\n}\r\n` does NOT contain `\n}\n` (it is `\n}\r`), so the search
returned None and the `unwrap_or_else` panicked. The sibling helpers already
tolerate CRLF and passed: `writer_body`'s `\n }` anchor survives inside
`\r\n }`, and `touches_field`'s `self.<field>` needle never spans a line
break -- only `struct_fields` had the LF-only terminator.
Fix: strip `\r` at the top of `struct_fields` (it returns owned `Vec<String>`,
so a normalized local copy has no borrow implications), making every anchor
and the line scan line-ending-agnostic regardless of how the file was
checked out.
Proven deterministically rather than by waiting on Windows CI (which the PR
matrix cannot exercise): feeding a CRLF-converted real `ppu.rs` to the old
anchor returns index -1 (the exact panic), and to the fixed parser returns a
valid offset. Added `struct_fields_tolerates_crlf_line_endings`, which parses
the same synthetic struct in both LF and CRLF form and asserts identical
output; being a pure string test it runs on Linux CI too, so the guarantee
holds on every platform rather than only where the audit happens to be
checked out LF.
Verification: `cargo test -p rustynes-test-harness --test snapshot_schema_audit`
7 passed / 0 failed; clippy -p rustynes-test-harness --all-targets -D warnings
clean; fmt clean.
|
Warning Review limit reached
Next review available in: 10 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Antigravity review (Gemini via Ultra)This PR normalizes CRLF line endings in Blocking issuesNone found. Suggestions
Nitpicks
Automated first-pass review by |
Unblock the v2.2.3 release: fix the Windows-only
snapshot_schema_auditfailureThe v2.2.3 merge (#325) went green on the PR but failed on
main, sorelease-auto.ymlskipped and no release was cut. The PR CI matrix is Linux-only (theselect matrixjob trims it for pull requests); themainpush runs the full matrix, andtest (windows-latest)failed.Root cause — CRLF, not logic
snapshot_schema_auditis a test added in this release (244e6c18), so themainpush was its first Windows run. Two cases panicked instruct_fieldswith "unterminated struct body":include_str!, which captures the file with its on-disk line endings at compile time. A Windows checkout without aneol=lfattribute for.rsgives CRLF.body.find("\n}\n")— and\r\n}\r\ndoes not contain\n}\n(it is\n}\r), so the search returnedNoneand theunwrap_or_elsepanicked.writer_body's\n }survives inside\r\n };touches_field'sself.<field>needle never spans a line break), which is why onlystruct_fieldsfailed.Fix
Strip
\rat the top ofstruct_fields(it returns ownedVec<String>, so a normalized local copy has no borrow implications), making every anchor line-ending-agnostic regardless of checkout.Verification (deterministic — the PR matrix cannot run Windows)
Feeding a CRLF-converted real
ppu.rsto the old anchor returns index-1(the exact panic); to the fixed parser it returns a valid offset. Addedstruct_fields_tolerates_crlf_line_endings, which parses the same synthetic struct in both LF and CRLF form and asserts identical output — a pure string test, so Linux CI exercises the Windows guarantee too.On merge, the full
mainmatrix (includingwindows-latest) validates the fix, and on successrelease-auto.ymlcuts v2.2.3.🤖 Generated with Claude Code