feat(loomgen): add line-mode lexer fallback#703
Conversation
|
Warning Review limit reached
Next review available in: 40 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: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds ChangesLine-mode fallback lexer
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant AnnotationParser
participant emit_line_lexer
participant GeneratedModeLexer
participant FallbackLexer
AnnotationParser->>emit_line_lexer: provide validated fallback_lex metadata
emit_line_lexer->>GeneratedModeLexer: generate mode-specific no-match handling
GeneratedModeLexer->>FallbackLexer: call fallback function for unmatched input
Possibly related issues
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
loomgen/emit_lexer_wbtest.mbt (3)
1074-1078: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winAssert the no-fallback behavior per mode.
generated.contains(...)only proves that at least one generated function contains theInvalidpath. Slicelex_line_startandlex_block_quote_line_startseparately and assert both retain the no-fallback behavior.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@loomgen/emit_lexer_wbtest.mbt` around lines 1074 - 1078, Update the no-fallback assertions in the relevant lexer workbench test to inspect generated code separately for lex_line_start and lex_block_quote_line_start, and assert that each mode retains the “Not a block-level token (line_pattern)” Invalid path instead of relying on one aggregate generated.contains check.
888-921: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winAdd a multi-mode fallback isolation test.
This test has only one line mode, so it cannot detect accidentally applying
lex_inlineto every generated mode. Add a second mode without a fallback and assert that only the declared mode delegates while the other retainsInvalid.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@loomgen/emit_lexer_wbtest.mbt` around lines 888 - 921, Extend the test around emit_line_lexer to declare a second line lex mode without fallback_lex, then assert generated code delegates to lex_inline only for the mode that declares it. Also assert the fallback-free mode retains Invalid handling, using the existing generated output and mode-specific symbols to distinguish both paths.
924-985: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winCover invalid fallback function names.
The new negative tests cover placement and conflicting declarations, but not the promised function-reference validation. Add invalid-name cases such as
bad name)ora..b, plus a qualified@pkg.fnpositive case.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@loomgen/emit_lexer_wbtest.mbt` around lines 924 - 985, The annotation parser tests need coverage for fallback_lex function-reference validation. Add negative cases using malformed names such as “bad name)” and “a..b”, asserting the appropriate parse errors, and add a positive case confirming a qualified reference like “@pkg.fn” is accepted; place these alongside the existing fallback_lex tests and preserve their current placement/conflict coverage.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/README.md`:
- Line 73: Reorder the ADR index entry for
decisions/2026-07-12-line-mode-fallback-lexer.md so it appears before all July
10, 2026 entries, preserving the section’s descending-date order and leaving the
entry text unchanged.
---
Nitpick comments:
In `@loomgen/emit_lexer_wbtest.mbt`:
- Around line 1074-1078: Update the no-fallback assertions in the relevant lexer
workbench test to inspect generated code separately for lex_line_start and
lex_block_quote_line_start, and assert that each mode retains the “Not a
block-level token (line_pattern)” Invalid path instead of relying on one
aggregate generated.contains check.
- Around line 888-921: Extend the test around emit_line_lexer to declare a
second line lex mode without fallback_lex, then assert generated code delegates
to lex_inline only for the mode that declares it. Also assert the fallback-free
mode retains Invalid handling, using the existing generated output and
mode-specific symbols to distinguish both paths.
- Around line 924-985: The annotation parser tests need coverage for
fallback_lex function-reference validation. Add negative cases using malformed
names such as “bad name)” and “a..b”, asserting the appropriate parse errors,
and add a positive case confirming a qualified reference like “@pkg.fn” is
accepted; place these alongside the existing fallback_lex tests and preserve
their current placement/conflict coverage.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 36f85698-0cc3-46e6-8444-5577738ca92c
📒 Files selected for processing (10)
docs/README.mddocs/archive/completed-phases/2026-07-fallback-lex.mddocs/decisions/2026-07-12-line-mode-fallback-lexer.mddocs/superpowers/specs/2026-07-12-fallback-lex-design.mdloomgen/README.mdloomgen/emit_lexer_wbtest.mbtloomgen/emit_line_lexer.mbtloomgen/fixtures/line_pattern_fixture.g.mbtloomgen/fixtures/line_pattern_fixture.mbtloomgen/parse_annotations.mbt
1 participant
Summary
#loom.fallback_lex("fn")for#loom.line_modeterm variants.Invalidbehavior when no fallback is declared.Map.Verification
moon fmt --checkmoon check loomgen --target nativemoon test loomgen --target native— 169/169moon test --target native— 3323/3323The existing test runner diagnostic for the intentional
ATokencollision remains present, but all tests pass.Codex pre-PR review was attempted twice but was unavailable in this environment (unsupported requested model and default retry timeout); the focused diff was self-reviewed and all verification commands passed.
End-to-end compilation and runtime tokenization of generated line lexers is tracked separately in #701. Skeleton integration is tracked in #699. Ambiguous
#loom.patternplus#loom.line_patternvalidation is tracked in #702.Closes #700
Summary by CodeRabbit
New Features
#loom.fallback_lex("function_name")support for line-mode lexers.Invalidbehavior remains unchanged when no fallback is configured.Documentation
Tests