docs: Update Phase 212.5 completion status and add Phase 213 plan

Phase 212.5 完了を記録し、Phase 213 への継続を明記。

- phase212-5-implementation-complete.md: Phase 213 への継続を追記
- CURRENT_TASK.md: Phase 212.5 完了エントリ + Phase 213 計画を追加

🤖 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 23:37:18 +09:00
parent aeb6282c2d
commit 577b5b01d5
2 changed files with 193 additions and 2 deletions

View File

@ -87,6 +87,9 @@
**バグ修正**: Trim pattern の loop_var_name 上書き問題、InstructionRewriter の latch_incoming 設定問題。 **バグ修正**: Trim pattern の loop_var_name 上書き問題、InstructionRewriter の latch_incoming 設定問題。
- 今後 1〜2 フェーズの TODOJoinIR 周りのサマリ) - 今後 1〜2 フェーズの TODOJoinIR 周りのサマリ)
- [x] **Phase 213-E: NYASH_JOINIR_CORE deprecate cleanup** ✅ (2025-12-09)
- JoinIR は常時 ONLoopBuilder 削除済み)。`NYASH_JOINIR_CORE` は警告のみで無視する。
- config/env でガード追加済み、スクリプトからの export を撤去、docs に「常時 ON + Fail-Fast」の注記を追加。
- [x] **Phase 177: Multi-carrier PHI 接続修正** ✅ (2025-12-08) - [x] **Phase 177: Multi-carrier PHI 接続修正** ✅ (2025-12-08)
- Task 177-STRUCT-1: CarrierVar に join_id 追加 - Task 177-STRUCT-1: CarrierVar に join_id 追加
- Task 177-STRUCT-2: carrier_order で順序保持LoopHeaderPhiInfo - Task 177-STRUCT-2: carrier_order で順序保持LoopHeaderPhiInfo
@ -581,8 +584,179 @@
- ✅ PHI dst match (Phase 200-3) - ✅ PHI dst match (Phase 200-3)
- ✅ PHI dst not overwritten (Phase 204-2 ✨) - ✅ PHI dst not overwritten (Phase 204-2 ✨)
- ✅ PHI inputs sanity (Phase 204-3 ✨) - ✅ PHI inputs sanity (Phase 204-3 ✨)
- ⚠️ PHI inputs DFA (Phase 205+ 計画) - ⚠️ PHI inputs DFA (Phase 206+ 計画)
- ⚠️ ValueId regions (Phase 205+ 計画) - ValueId regions (Phase 205)
- [x] **Phase 205: JoinValueSpace & ValueId 領域契約の締め** ✅ (完了: 2025-12-09)
- **目的**: Box-First アプローチで ValueId 領域境界を完全確立
- **実装内容**:
- 205-1: 設計ドキュメント作成 ✅ (phase205-valueid-regions-design.md)
- ValueId 領域契約の詳細定義
- Box 境界設計ValueIdAllocator, RegionVerifier
- 205-2: 現状棚卸し ✅
- Pattern1-4 の ValueId 使用箇所リストアップ
- 素の ValueId(..) 直接生成箇所の特定
- 結果: Pattern1/2 統合済み、Pattern3/4 テストコードのみ
- 205-3: ValueIdAllocator Box 強化 ✅
- 明示的領域定数追加PHI_RESERVED_MIN/MAX, PARAM_MIN/MAX, LOCAL_MIN/MAX
- 衝突検出check_collision(), allocated_ids: HashSet
- 領域検証verify_region(id, expected_region)
- 205-4: RegionVerifier Box 実装 ✅
- verify_valueid_regions() 実装merge/mod.rs
- 検証項目: boundary.join_inputsParam 領域), condition_bindingsParam 領域), carrier_phis dst有効範囲内
- 205-5: パターン統合監査 ✅
- Pattern1-4 で raw ValueId(..) 使用がテストコードのみであることを確認
- すべて alloc_param()/alloc_local() 経由の正規ルート使用確認
- 205-6: テスト & ドキュメント更新 ✅
- loop_min_while.hako (P1), loop_if_phi.hako (P3) 動作確認
- joinir-architecture-overview.md に Phase 205 セクション追加
- **統計**:
- 変更ファイル: 2ファイル (join_value_space.rs, merge/mod.rs)
- 新規ドキュメント: phase205-valueid-regions-design.md
- テスト: 全テスト PASS、退行なし
- **成果**:
- 衝突検出debug-onlyで二重割り当てを即座に検出
- 領域検証で Param/Local 境界違反を即座に検出
- RegionVerifier で merge 時の境界契約を自動検証
- 明示的定数で領域境界が一目瞭然(デバッグ容易性向上)
- **Box-First 原則の実践**:
- 箱にする: ValueId 管理・検証ロジックを Box 化
- 境界を作る: Param/Local 領域の境界を明確化100, 1000
- 戻せる: debug assertions で切替可能
- 見える化: 領域違反を即座に検出
- **Fail-Fast 実装**:
- 領域違反は即座に panicデバッグモード
- フォールバックやサイレント修正は一切なし
- エラーメッセージに修正ヒント含む
- **次フェーズへの引き継ぎ**:
- Phase 206: PHI inputs DFA 完全検証(予定)
- Phase 207: LoopUpdateSummary 完全統合(予定)
- [x] **Phase 210: JsonParser JoinIR ミニ統合ラウンド1** ✅ (完了: 2025-12-09)
- **目的**: 既存 JoinIR インフラP1-P5/JoinValueSpace/PHI契約で実戦ループ 2〜3 本を観測
- **戦略**: 新機能実装なし、既存箱の実戦投入による観測フェーズFail-Fast で制約発見)
- **対象ループ3本**:
1. _atoi 最小版 (P2 Break, NumberAccumulation)
2. _parse_number 最小版 (P2 Break, Multi-carrier)
3. _match_literal 最小版 (P1 Simple)
- **実行結果**:
-**3本すべて完全成功** - JoinIR → MIR → Runtime まで到達
- ✅ phase190_atoi_impl.hako → RC=12 (Pattern2, NumberAccumulation)
- ✅ phase190_parse_number_impl.hako → RC=123 (Pattern2, Multi-carrier)
- ✅ phase210_match_literal_min.hako → RC=1 (Pattern1, Simple)
- **観測ポイント全達成**:
- ✅ Pattern1 & Pattern2 自動ルーティング成功
- ✅ NumberAccumulation: Mul + Add 2命令生成確認
- ✅ Multi-carrier: 2 carrier 同時動作 & Exit PHI 正常配線
- ✅ PHI Contract: LoopHeader PHI + Exit PHI 完璧に動作
- ✅ ValueId Regions: Param (100-999) / Local (1000+) 正常分離
- **重要な発見**:
-**予想を超える成功**: 「理論上いけるはず」を超えて「実戦でも完全動作」
- ✅ Phase 190 (NumberAccumulation), 201 (JoinValueSpace), 204/205 (PHI Contract) の統合が完璧に機能
-**制約発見ゼロ** - すべてのループが制約なく動作Fail-Fast 発動せず)
- **成果物**:
- ドキュメント: phase210-jsonparser-mini-integration.md設計・実行ログ・総合評価
- テストハーネス: phase210_match_literal_min.hako新規作成
- **Phase 210 の結論**:
> **JoinIR インフラは実戦投入可能な成熟度に達している** ✨
- **次フェーズへの接続**:
- Phase 211: JsonParser 残り8ループへの段階的展開_parse_array, _parse_object, _unescape_string 等)
- Phase 212: MethodCall in condition / Complex addend 対応強化
- [x] **Phase 211: JsonParser 次の 1 手(中規模ループ候補選定)** ✅ (完了: 2025-12-09)
- **目的**: Phase 210 成功を受け、中規模ループ 1 本を選定して既存 boxes 組み合わせを設計
- **戦略**: コード実装なし、設計のみPhase 212 で実装)
- **候補選定**: 候補 B (`selfhost if-sum` パターン) を Phase 212 実装対象に選定
- 理由: 既存 boxes で完全カバー可能 + ループ内 if の実戦検証価値が高い
- 候補 A (`_parse_string` 簡略版) は Phase 214 に延期3-carrier を Phase 213 で先に確認)
- **Boxes マッピング**:
- Pattern 1 Simple + IfPHI + Multi-carrierすべて Phase 210 で確認済み)
- 新規要素: IfPhiContext のループ内 if 適用Phase 61 実装済みだが実戦未確認)
- **組み合わせ戦略設計**:
```
LoopPatternRouter → SimpleWhileMinimal → CarrierInfo (sum, i)
→ IfPhiContext (ループ内 if の Merge PHI 生成)
→ Header PHI back_edge 接続 → Exit PHI 配線
```
- **Phase 212+ ロードマップ**:
- Phase 212: if-sum ハーネス実装・実行
- Phase 213: 3-carrier テスト
- Phase 214: `_parse_string` 簡略版
- Phase 215+: 残りの JsonParser ループ
- **成果物**: phase211-loop-candidate-selection.md設計ドキュメント
- [x] **Phase 212: if-sum ミニ実装 & 実行フェーズ** ⚠️ **BLOCKED** (2025-12-09)
- **目的**: Phase 211 設計の if-sum パターンを既存 JoinIR インフラで実装・実行
- **戦略**: Fail-Fast問題があれば制約層を記録して中断
- **テストファイル**: `apps/tests/phase212_if_sum_min.hako`
```hako
loop(i < len) {
if i > 0 {
sum = sum + 1 // ← 条件付き更新
}
i = i + 1
}
```
- **実行結果**: ⚠️ **制約発見により中断**
- Pattern 1 (Simple While) が選ばれた(想定通り)
- Carrier は `i` のみ(`sum` が carrier になっていない)
- 期待: RC=2 / 実際: RC=0
- **🚨 重大な発見**: **AST→MIR 変換層でループ内 if/else が消失**
- MIR ダンプで確認: if/else ブロックが MIR に存在しない
- `.hako` には `if i > 0 { sum = sum + 1 }` があるのに、MIR には `print(i)` と `i = i + 1` しかない
- `sum` 変数に関する処理条件分岐・加算・PHIが完全に消失
- **制約の層**:
| 項目 | 内容 |
|-----|-----|
| **制約層** | AST → MIR 変換Parser or MIR Builder |
| **現象** | ループ内 if/else の代入文が MIR に変換されない |
| **影響範囲** | JoinIR Pattern 3 (IfPHI) が動作する以前の問題 |
| **エラーメッセージ** | なしsilent failure |
| **再現性** | 100%print 追加でも変わらず) |
- **Fail-Fast 成功**: Phase 211 では見えなかった制約を 1 回の実行で発見・層を特定
- **Phase 213 への影響**: Phase 213 (3-carrier) も同じ問題に遭遇する可能性が高い
- **成果物**: phase212-if-sum-impl.md観測レポート・制約詳細
- **次のアクション**: ~~Phase 212.5AST→MIR ループ内 if 修正)~~ ✅ **完了** (commit `aeb6282c`)
- [x] **Phase 212.5: 構造ベース if 検出 for Pattern 3 Routing** ✅ (完了: 2025-12-09, commit `aeb6282c`)
- **目的**: Phase 212 で発見した「ループ内 if が Pattern 1 に誤ルーティング」問題を修正
- **原因特定**: `has_if_else_phi = carrier_count > 1` ヒューリスティックの限界
- 単一キャリアの if-update パターン(例: if-sumを Pattern 1 に誤判定
- **実装内容**:
1. **AST Feature Extractor** (`ast_feature_extractor.rs`)
- `detect_if_in_body()` 関数追加ANY if 文検出)
- `extract_features()` を構造ベース検出に更新
2. **Loop Pattern Classification** (`loop_pattern_detection/mod.rs`)
- Pattern 3: `carrier_count > 1` → `has_if && carrier_count >= 1`
- Pattern 1: `!has_if_else_phi` → `!has_if`
- **検証結果**: `phase212_if_sum_min.hako`
- ✅ Pattern 3 (If-Else PHI) に正しくルーティング
- ✅ MIR に PHI ノード生成: `%31 = phi [%25, bb9], [%29, bb10]`
- ✅ Carriers 検出: `i`, `sum`, `count`
- **制約発見**: Pattern 3 lowerer は **test-only PoC 実装**
- Loop condition: `i <= 5` (hardcoded)
- If condition: `i % 2 == 1` (hardcoded)
- Update logic: `sum + i` (hardcoded)
- → そのため RC=0期待: RC=2
- **成果**: Pattern routing は完全に成功、AST-based lowerer 汎用化は Phase 213 へ
- **ドキュメント**: phase212-5-implementation-complete.md
- [ ] **Phase 213: Pattern 3 Lowerer 汎用化if-sum minimal** 🚧 **次のフェーズ**
- **目的**: Pattern 3 lowerer を AST-based に汎用化し、`phase212_if_sum_min.hako` で RC=2 達成
- **スコープ**:
1. 設計ドキュメント作成
- `phase213-pattern3-if-sum-generalization.md`
- 入力: LoopPatternContext + LoopUpdateSummary + IfPhiContext
- 出力: JoinModule + ExitMeta複数キャリア対応
2. P3 lowerer から定数ハードコード削除
- `loop_with_if_phi_minimal.rs` の固定条件/更新(`i<=5`, `i%2==1`, `sum+i`)を削除
- LoopUpdateSummary / BoolExprLowerer / CarrierInfo から動的に AST を読み込み
3. `phase212_if_sum_min.hako` 再実行
- 期待: Pattern 3 routing → JoinIR/MIR/VM → RC=2
- **Fail-Fast 戦略**: Verifier panic や制約エラーがあればログを Phase 213 doc に記録
- **ドキュメント更新**:
- phase212-5-implementation-complete.md に Phase 213 への継続を明記
- CURRENT_TASK.md 本項目
--- ---

View File

@ -214,4 +214,21 @@ loop(i <= 5) { // Actual: i <= 5 (hardcoded)
- [x] Pattern 3 lowerer constraints documented - [x] Pattern 3 lowerer constraints documented
- [x] Implementation report created - [x] Implementation report created
---
## 🔖 Status Update
**Phase 212.5: COMPLETE ✅** (Commit: `aeb6282c`)
**Scope Completed**:
- ✅ Structural if detection (`detect_if_in_body`)
- ✅ Pattern routing logic (classify with `has_if && carrier_count >= 1`)
- ✅ Test verification (Pattern 3 routing confirmed)
- ✅ MIR PHI generation verified
**Out of Scope (Phase 213)**:
Pattern 3 lowerer (`lower_loop_with_if_phi_pattern`) is currently a **test-only PoC implementation** with hardcoded conditions and updates. AST-based generalization for if-sum patterns is handled in Phase 213.
**Next**: Phase 213 will generalize Pattern 3 lowerer to read actual AST conditions and update expressions dynamically.
**Phase 212.5: COMPLETE ✅** **Phase 212.5: COMPLETE ✅**