docs: Phase 195 implementation status + Phase 196 (Select bug) planning

Phase 195 implementation complete (Lowerer side):
- loop_with_if_phi_minimal.rs: multi-carrier PHI generation (sum + count)
- pattern3_with_if_phi.rs: dynamic single/multi-carrier handling
- ExitLine/CarrierVar.join_id: NO CHANGES NEEDED (existing infra worked!)
- YAGNI principle validated - PhiGroupBox was not necessary

Blocker discovered: Nested Select→Branch+Phi conversion bug
- JoinIR correctly generates: ValueId(20) = phi [(bb3, 14), (bb4, 18)]
- MIR incorrectly produces: %27 = phi [%28, bb8], [%32, bb9] (undefined)
- Root cause: joinir_block.rs Select expansion (bridge layer)
- NOT a Phase 195 issue - pre-existing bug in Select conversion

Phase 196 planned (NEW):
- 196-1: Document select_expansion / instruction_rewriter responsibilities
- 196-2: Formalize "1 Select = 3 blocks + 1 PHI" interface
- 196-3: Debug block reuse / block ID mapping
- 196-4: Fix and E2E test (phase195_sum_count.hako → 72)

Documentation updates:
- phase195-pattern3-extension-design.md: Implementation Status section
- CURRENT_TASK.md: Phase 195 complete + Phase 196 TODO
- joinir-architecture-overview.md: P3 Lowerer complete, bridge blocker noted

Key insight: "Pattern side is done, problem is in bridge side"

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
nyash-codex
2025-12-09 13:58:31 +09:00
parent 8e837accdd
commit dc4eda9cdc
3 changed files with 101 additions and 18 deletions

View File

@ -334,22 +334,33 @@
- Phase 195: Pattern 3 extensionif-in-loop + multi-flag carriers
- Phase 200+: ConditionEnv expansionfunction-scoped locals
- Phase 201+: MethodCall extensionmultiple calls in body
- [ ] **Phase 195: Pattern 3 拡張(設計フェーズ)**
- **目的**: P3If-Else PHIを複数キャリア対応に拡張する設計
- 195-1: 対象ループ絞り込み_parse_string 簡易版、if-sum
- 195-2: LoopUpdateSummary/CarrierInfo 設計整理(複数キャリア対応
- 195-3: Pattern3 lowerer 設計更新PhiGroup vs ExitLine 拡張判断)
- 195-4: 実装スコープ決定2-3キャリア、既存 UpdateKind 範囲内
- 195-5: ドキュメント更新CURRENT_TASK.md + overview 更新)
- **設計判断**:
- ✅ ExitLine 拡張で対応PhiGroupBox は作らない - YAGNI 原則)
- [x] **Phase 195: Pattern 3 拡張(設計 + Lowerer 実装完了)** (2025-12-09)
- **目的**: P3If-Else PHIを複数キャリア対応に拡張
- **実装完了**:
- `loop_with_if_phi_minimal.rs`: multi-carrier PHI 生成sum + count
- `pattern3_with_if_phi.rs`: 単一/複数キャリアを動的処理
- ✅ ExitLine / CarrierVar.join_id: **変更不要**(既存インフラ活用
- ✅ テストファイル: `phase195_sum_count.hako` 作成
- **設計判断の証明**:
- ✅ ExitLine 拡張で対応PhiGroupBox は作らない - YAGNI 原則が正しかった
- ✅ 両分岐での Carrier 定義確認(更新なし = 前の値使用)
- ❌ ConditionEnv 拡張なしPhase 200+ 保留)
- ❌ LoopBodyLocal + MethodCall 混在は Phase 195+ 延期
- **期待成果**:
- phase195-pattern3-extension-design.md完全設計書
- Phase 195-impl の実装スコープ明確化
- JsonParser カバレッジ 40% → 60% への道筋
- **Blocker**: Nested Select→Branch+Phi 変換バグ
- JoinIR: `ValueId(20) = phi [(bb3, 14), (bb4, 18)]` ← 正しい
- MIR: `%27 = phi [%28, bb8], [%32, bb9]` ← %28, %32 が undefined
- **原因**: `joinir_block.rs` の Select 展開処理bridge 層の既存バグ)
- **対応**: Phase 196 として分離Lowerer 側は完了)
- **成果**:
- P3 Lowerer は複数キャリア対応完了 ✅
- ExitLine/CarrierVar は既に対応済み(変更不要)✅
- JoinIR→MIR bridge の Select バグは別 Issue として分離 ✅
- [ ] **Phase 196: Select 展開/変換バグ調査&修正**NEW
- **目的**: Nested Select→Branch+Phi 変換の既存バグを修正
- 196-1: `select_expansion` / `instruction_rewriter` の責務を doc に整理
- 196-2: 「1 Select = 3 ブロック + 1 PHI」変換インタフェース明文化
- 196-3: block reuse / block ID マッピングの切り分け
- 196-4: 修正実装 + E2E テストphase195_sum_count.hako → 72
- **期待成果**: Phase 195 の multi-carrier が E2E で動作
---

View File

@ -523,11 +523,12 @@ JoinIR は Rust 側だけでなく、将来的に .hako selfhost コンパイラ
- Deferred loops: _parse_array, _parse_object (multiple MethodCalls)
- 詳細: phase194-loop-inventory.md, phase194-jsonparser-deployment.md
5. **Pattern 3 拡張(複数キャリア対応)** → Phase 195 設計中
5. **Pattern 3 拡張(複数キャリア対応)** → Phase 195 Lowerer 完了、Phase 196 待ち
- 目的: P3If-Else PHIで 2-3 個の Carrier を同時処理
- 設計判断: ExitLine 拡張で対応PhiGroupBox は作らない - YAGNI 原則)
- 対象: _parse_stringflag+buffer、if-sumsum+count
- Phase 195-impl で実装予定
- **Lowerer 側完了**: multi-carrier PHI 生成sum + count
- **ExitLine**: 変更不要(既存インフラ活用)✅
- **Blocker**: JoinIR→MIR の Select 変換バグPhase 196 で修正予定
- パターン側は終わり、問題は bridge 側
6. **JsonParser 残り複雑ループへの適用Phase 195+, 200+**
- Phase 200+: ConditionEnv 拡張 (function-scoped variables) → _parse_number, _atoi

View File

@ -621,3 +621,74 @@ Section 7.2 "残タスク" に追記:
- 設計フェーズで構造を固める
- 実装フェーズは lowerer のみに集中
- ドキュメント駆動開発
---
## Implementation Status
**完了日**: 2025-12-09
**状態**: Lowerer/ExitLine 側は完了、JoinIR→MIR 変換バグにより E2E ブロック
### 実装サマリ
**Phase 195-impl で実装したこと**:
1. **`loop_with_if_phi_minimal.rs`** (+91行):
- multi-carrier PHI 生成を追加sum + count の 2 キャリア対応)
- 各キャリアについて then/else 値を収集し、個別に PHI を生成
- JoinIR 上で正しい PHI 構造を出力
2. **`pattern3_with_if_phi.rs`** (+68行):
- 単一キャリア(後方互換)と複数キャリアを動的に扱うよう拡張
- exit_bindings に複数キャリアを載せる処理を追加
3. **ExitLine / LoopExitBinding / CarrierVar.join_id**:
- **変更不要!** 既存インフラをそのまま利用できた
- Phase 170-189 で整備された CarrierVar.join_id が multi-carrier を想定していた
- YAGNI 原則の正しさが証明された
### Blocker: Nested Select→Branch+Phi 変換バグ
**問題の概要**:
- JoinIR 側では正しい PHI が生成されている
- MIR 変換時に PHI inputs が undefined を参照するようになる
**具体例**:
```
JoinIR (正しい):
ValueId(20) = phi [(BasicBlockId(3), ValueId(14)), (BasicBlockId(4), ValueId(18))]
MIR (壊れている):
bb10:
%27 = phi [%28, bb8], [%32, bb9] // ← %28, %32 は undefined
```
**原因分析**:
- `joinir_block.rs` の Select 命令処理で、Nested Selectif-else が複数キャリアを持つ場合)の変換が壊れている
- Select → 3ブロック + 1 PHI の展開時に、block ID マッピングまたは ValueId マッピングが不整合
- Pattern3 の multi-carrier 対応自体は問題なく、bridge 層の既存バグ
**対応方針**:
- Phase 195 の scope からは外すLowerer/ExitLine の責務は完了)
- Phase 196 として Select 展開バグの調査・修正を別タスク化
### テスト状況
**後方互換テスト**:
- 単一キャリア P3 テストloop_if_phi.hako 等): 退行確認が必要
- Pattern1/2/4 代表テスト: 影響なしSelect 変換に依存しないパターン)
**multi-carrier E2E テスト**:
- `phase195_sum_count.hako`: JoinIR 生成は正しい、MIR 変換でブロック
### 次のステップ
**Phase 196: Select 展開/変換バグ調査&修正**(別タスク)
- `select_expansion` / `instruction_rewriter` の責務を doc に整理
- 「1 Select = 3 ブロック + 1 PHI」変換インタフェースを明文化
- block reuse / block ID マッピングの切り分け
**Phase 195 完了時点での成果**:
- P3 Lowerer は複数キャリア対応完了 ✅
- ExitLine/CarrierVar は既に対応済み(変更不要)✅
- JoinIR→MIR bridge の Select バグは別 Issue として分離 ✅