42339ca77f
Expand loop canonicalizer to recognize parse_string patterns with both
continue (escape handling) and return (quote found) statements.
## Implementation
### New Pattern Detection (ast_feature_extractor.rs)
- Add `detect_parse_string_pattern()` function
- Support nested continue detection using `has_continue_node()` helper
- Recognize both return and continue in same loop body
- Return ParseStringInfo { carrier_name, delta, body_stmts }
- ~120 lines added
### Canonicalizer Integration (canonicalizer.rs)
- Try parse_string pattern first (most specific)
- Build LoopSkeleton with HeaderCond, Body, Update steps
- Set ExitContract: has_continue=true, has_return=true
- Route to Pattern4Continue (both exits present)
- ~45 lines modified
### Export Chain
- Add re-exports through 7 module levels:
ast_feature_extractor → patterns → joinir → control_flow → builder → mir
- 10 lines total across 7 files
### Unit Test
- Add `test_parse_string_pattern_recognized()` in canonicalizer.rs
- Verify skeleton structure (3+ steps)
- Verify carrier (name="p", delta=1, role=Counter)
- Verify exit contract (continue=true, return=true, break=false)
- Verify routing decision (Pattern4Continue, no missing_caps)
- ~180 lines added
## Target Pattern
`tools/selfhost/test_pattern4_parse_string.hako`
Pattern structure:
- Check for closing quote → return
- Check for escape sequence → continue (nested inside another if)
- Regular character processing → p++
## Results
- ✅ Strict parity green: Pattern4Continue
- ✅ All 19 unit tests pass
- ✅ Nested continue detection working
- ✅ ExitContract correctly set (first pattern with both continue+return)
- ✅ Default behavior unchanged
## Technical Challenges
1. Nested continue detection required recursive search
2. First pattern with both has_continue=true AND has_return=true
3. Variable step updates (p++ vs p+=2) handled with base delta
## Statistics
- New patterns: 1 (parse_string)
- Total patterns: 4 (skip_whitespace, parse_number, continue, parse_string)
- New capabilities: 0 (uses existing ConstStep)
- Lines added: ~300
- Files modified: 9
- Parity status: Green ✅
Phase 143 P1: Complete
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Phase ドキュメント
このフォルダは、実装フェーズ（Phase 131, Phase 33 等）ごとの詳細記録を保管します。
現在の Phase
- Phase 132: Exit Values Parity (VM == LLVM)
- Phase 133: Promoted carrier join_id（Trim）修正
- Phase 134: Plugin loader best-effort loading
- Phase 135: ConditionLoweringBox allocator SSOT（ValueId 衝突の根治）
- Phase 136: MirBuilder Context SSOT 化（+ ValueId allocator 掃討）
- Phase 137–141: Loop Canonicalizer（前処理 SSOT）導入（Phase 137 フォルダに統合して記録）
Phase フォルダ構成（推奨）
phases/phase-131/
├── README.md (Phase 全体概要)
├── 131-03-llvm-lowering-inventory.md (LLVM 部分のテスト・検証)
├── 131-11-case-c-summary.md (Case C 実装サマリー)
└── phase131-11-case-c-root-cause-analysis.md (根本原因分析)
参照方法
- 現在の Phase を知りたい → ../10-Now.md
- 該当 Phase を詳しく知りたい → フォルダを開く
- 設計背景を知りたい → ../design/
- 調査ログを見たい → ../investigations/
Phase 命名規則
- ファイル名:
phase-<N>-<title>/(例:phase-131/) - 文書名:
<N>-<NN>-<topic>.md(例:131-11-case-c-summary.md)- Phase 番号で自然にソート可能
- 同一 Phase 内で段階的に追跡可能
作成ルール（SSOT）
詳しくは ../DOCS_LAYOUT.md を参照。
- ✅ 置き場所:
phases/phase-<N>/配下のみ - ✅ 内容: Phase の実装記録・進捗・チェックリスト・検証結果
- ❌ 避けるべき: 複数 Phase で参照される設計・アーキテクチャ（→ design/ へ）
最終更新: 2025-12-15