Repository navigation
feat(tests): generate folding-ranges doc from snapshot fixtures - #535
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds fixture-driven folding-range documentation generation and checking, expands C++ folding-range fixtures with snapshot records, and updates the snapshot harness to recognize unsupported cases. Unit-test execution now also validates generated feature documentation. ChangesFolding range documentation and test coverage
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9eb393f7dc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: faece4ea5d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a9e5037f43
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9765c48a3f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9db322593f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8aaf34a315
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 42b947b73a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The /// spec header tripped AnnotatedSource::from's @key[...] assertion in Debug builds (@section etc. parsed as range annotations), and would pollute folding output once comment folding exists. Stripping it before add_main fixes both and aligns snapshot positions with the doc examples. Also per review: give fold_from_declaration_line a real compilable body, and correct the inactive_preprocessor_branch description (only the condition-to-#else region folds today).
A plain /// doc comment atop a supplementary fixture (no @key lines) now stays in the compiled input, matching parse_fixture's rule.
Doxygen tags after prose in a supplementary fixture's doc comment no longer count as spec keys, and a bare @status with no value is now rejected instead of silently rendering as unchecked.
Stop the C++ header scan at the first non-/// line (a blank separator followed by /// body comments previously hit an LLVM drop_front assert), and reject duplicate and empty required keys in feature_docs.py.
Spec-key detection now requires a word char after @, matching parse_fixture's @(\w+) grammar; generated code fences grow past any backtick run in the example so it cannot close the fence early.
Drop the @-prefixed spec header and the fence experiment: frontmatter is now the leading run of '/// key: value' lines, terminated by a bare /// separator. The block is an ordinary comment to the compiler, so no stripping and no annotation-parser interaction; the C++ side only does a status lookup via the shared test/fixture.h helper. A typo in the first key is reported instead of silently demoting the file to a supplementary fixture.
The check guarded against the old ASCII $ sigil colliding with real fixture content. The redesigned grammar reserves only §/⟦/⟧, which cannot occur naturally, and cursor-based features will later place these annotations in doc fixtures deliberately.
The fixture doc header is now a plain markdown document: an h1 title line (which doubles as the doc-item marker), a '- key: value' metadata list (status/issues/order) and a markdown description. The section key is gone — grouping comes from one-level section subdirectories (fold_kinds/, refinements/), and doc region markers use the directory name. Stripped of the /// prefix the whole header renders as-is in any markdown viewer.
6f7b649 to
4e803ce
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4e803ce8b1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
1 participant
Why
Feature docs are hand-maintained support checklists with no mechanical connection to tests: nothing verifies that a checked item actually works, and nothing flags when behavior changes. This PR pilots the inversion for folding ranges: snapshot fixtures become the single source of truth and the doc checklist is generated from them.
Design
Each fixture under
tests/data/folding_range/<section>/carries a doc header that is a plain markdown document behind///:///prefix the whole header renders as-is in any markdown viewer.fold_kinds/,refinements/); generated doc regions are keyed by the directory name, while human headings and prose stay hand-written.statussemantics:supported→[x], compiled, snapshot proves the behavior;partial→[ ]with a (partial) marker, compiled, snapshot records the current partial behavior so improvements surface as diffs;unsupported→ skipped by the snapshot glob, snapshot pinned toUNSUPPORTED, implementing the capability later surfaces as a diff prompting the status flip.tests/tools/feature_docs.pyrenders headers into marker-delimited regions ofdocs/en/features/folding-ranges.md(update) and fails on drift (check, now part ofpixi run unit-test). The C++ side reads only thestatuskey via a shared ten-line helper — there is no grammar to drift between the two parsers.Notable corrections found by review
#else-delimited branches today; they are nowpartialwith snapshots recording the true current behavior (bare#if...#endifstill does not fold — clangd#1661). Thepartialtier exists because of this finding.Migration
The 14 checklist items of the old hand-written doc are preserved (titles, statuses, examples, issue links, client-support notes). Legacy inline test cases are untouched and migrate in follow-up per-feature PRs.
Tests
format→checkround-trip verified stable