tomoaki/hakorune
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
0aad016be2b9f931a940fa7ac0f8dcfdbcec87ef
hakorune/CURRENT_TASK.md

411 lines
38 KiB
Markdown
Raw Normal View History

feat(hako_check): Phase 153 - Dead code detection revival (JoinIR version) Implement comprehensive dead code detection for hako_check with JoinIR integration, following Phase 133/134/152 box-based modularity pattern. ## Key Achievements 1. **Comprehensive Inventory** (`phase153_hako_check_inventory.md`): - Documented current hako_check architecture (872 lines) - Analyzed existing HC011/HC012 rules - Confirmed JoinIR-only pipeline (Phase 124) - Identified Phase 153 opportunities 2. **DeadCodeAnalyzerBox** (`rule_dead_code.hako`): - Unified HC019 rule (570+ lines) - Method-level + box-level dead code detection - DFS reachability from entrypoints - Text-based analysis (no MIR JSON dependency for MVP) - Heuristic-based false positive reduction 3. **CLI Integration** (`cli.hako`): - Added `--dead-code` flag for comprehensive mode - Added `--rules dead_code` for selective execution - Compatible with --format (text/json-lsp/dot) 4. **Test Infrastructure**: - HC019_dead_code test directory (ng/ok/expected.json) - `hako_check_deadcode_smoke.sh` with 4 test cases ## Technical Details - **Input**: Analysis IR (MapBox with methods/calls/boxes/entrypoints) - **Output**: HC019 diagnostics - **Algorithm**: Graph-based DFS reachability - **Pattern**: Box-based modular architecture - **No ENV vars**: CLI flags only ## Files Modified - NEW: docs/development/current/main/phase153_hako_check_inventory.md - NEW: tools/hako_check/rules/rule_dead_code.hako - MOD: tools/hako_check/cli.hako - NEW: tools/hako_check/tests/HC019_dead_code/ - NEW: tools/hako_check_deadcode_smoke.sh - MOD: CURRENT_TASK.md ## Next Steps - Phase 154+: MIR CFG integration for block-level detection - Phase 160+: Integration with .hako JoinIR/MIR migration 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-04 14:19:48 +09:00
# Current Task
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
このファイルは「いま何に集中しているか」と「次にやり得る候補」だけを書く軽量ビューだよ。
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
詳細なログや過去フェーズの記録は `docs/development/current/main/` 以下の各 `phase-*.md` と
`docs/development/current/main/joinir-architecture-overview.md` を真実のソースとして扱うよ。
docs(phase130): JoinIR→LLVM ベースライン確立 Phase 130完了: JoinIR → LLVM 経路の現状を観測・記録 実施内容: - 代表ケース7本選定（selfhost/hako_check/JoinIR各系統） - Rust VM / LLVM harness 両経路でテスト実行 - 実行結果を表形式で記録（観測専用、修正なし） - Phase 131への引き継ぎ事項を整理 テスト結果: - Rust VM: 6/7 PASS (85.7%) - peek_expr_block, loop_min_while, phase123_simple_if, phase123_while_loop, joinir_if_select_simple, joinir_min_loop - FAIL: esc_dirname_smoke (ConsoleBox未登録) - LLVM harness: 0/7実行 (Mock backend、要--features llvm) - MIRコンパイルは全て成功 - 実LLVM実行は未対応 検出された問題点: 1. LLVM Backend未対応（最重要） - --features llvm ビルドが必要 - Mock backend実行中 2. ConsoleBox未登録問題 - Rust VM環境での登録不備 - Phase 15.5方針との衝突 3. JoinIR → LLVM経路の不明確性 - MIR → LLVM IR lowering未検証 成果物: - docs/development/current/main/phase130_joinir_llvm_baseline.md - 代表ケース選定理由・実行コマンド整理 - 実行結果詳細・問題点分析 - Phase 131引き継ぎ事項 - CURRENT_TASK.md: Phase 130セクション追加 - 30-Backlog.md: Phase 131予告追加 次フェーズ: Phase 131 - JoinIR→LLVM 個別修正ライン
2025-12-04 10:52:10 +09:00
---
docs(joinir): Phase 43/245B Normalized JoinIR completion summary Complete documentation consolidation for Phases 26-45 Normalized JoinIR infrastructure. All components are implemented and tested (937/937 PASS). Key additions: - PHASE_43_245B_NORMALIZED_COMPLETION.md: Master completion summary - Architecture components (Mode, Capability, Carriers, DigitPos, etc.) - Supported loop patterns (P1, P2 variants including JsonParser) - Complete file reference guide - Test coverage documentation - Future expansion roadmap Updates: - CURRENT_TASK.md: Moved Phase 43/245B to completed section - joinir-architecture-overview.md: Phases 43-45 marked complete - Historical docs: Added completion banners with links - phase223-loopbodylocal-condition-design.md - phase223-loopbodylocal-condition-inventory.md - PHASE_223_SUMMARY.md - phase245b-num_str-carrier-design.md - phase245c-function-param-capture-summary.md Documentation hierarchy established: - Master summary → individual design docs - Historical docs → completion summary - Cross-references complete across all docs Status: Phase 43/245B Normalized infrastructure COMPLETE ✅
2025-12-12 04:19:06 +09:00
## 🎯 今フォーカスしているテーマ（2025-12-12 時点のスナップショット）
### 0. ✅ Phase 43/245B Normalized JoinIR Infrastructure COMPLETE (Phase 26-45)
**完全サマリ**: [PHASE_43_245B_NORMALIZED_COMPLETION.md](docs/development/current/main/PHASE_43_245B_NORMALIZED_COMPLETION.md)
- **達成内容**:
- Structured→Normalized→MIR(direct) パイプライン確立
- P1/P2 + JsonParser (skip_ws/atoi/parse_number) 全対応
- Mode system (Phase 45), Capability system (Phase 44) 完成
- 937/937 tests PASS
- **主要コンポーネント**:
- JoinIrMode enum (StructuredOnly/NormalizedDev/NormalizedCanonical)
- ShapeCapabilityKind (P2CoreSimple/P2CoreSkipWs/P2CoreAtoi/P2MidParseNumber)
- CarrierRole (LoopState/ConditionOnly), CarrierInit
- DigitPos dual-value (is_digit_pos + digit_value)
- NumberAccumulation, Step scheduling, Exit PHI & Jump args
- **今後の拡張候補**（計画のみ）:
- Phase 46+: Canonical set 拡張 (capability-based)
- Pattern3/4 Normalized 適用
- Selfhost loops 対応
### 0-B. JoinIR / ExprLowerer / Pattern2–4 + JsonParser `_parse_number` / DigitPos ライン（Phase 230–247-EX 完了）✅
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
- Pattern1–4（while / break / if‑PHI / continue）＋ P5(Trim) でループ lowering を JoinIR 経路に一本化。
- Phase 231/236/240-EX:
- Pattern2 の header / break 条件を ExprLowerer/ScopeManager 経由（対応パターンのみ）で本番導線化。
- ConditionEnv ベースの意味論と RC/JoinIR 構造が一致することをテストとカタログで確認済み。
- Phase 237–238-EX:
- JsonParser/selfhost の条件パターンをカタログ化し、ExprLowerer/ScopeManager/ConditionEnv の責務境界を docs/README で固定。
- Phase 241–242-EX:
- array_filter 系 3 FAIL を「構造で」解消（hardcode `"sum"` チェック削除、CarrierInfo/ExitMeta 経由に統一）。
- Pattern3 if‑sum / Pattern4 continue から legacy lowerer と by-name `"sum"`/`"count"` を完全削除。
- 複雑条件（`i % 2 == 1`）を ConditionPattern/if-sum lowerer で安全に扱えるよう整理（Fail-Fast + テスト付き）。
- Phase 243–244-EX:
- Pattern3/4 の公開 API を `can_lower + lower` の最小セットに整理し、内部 helper を箱の中に閉じた。
- `loop_pattern_detection` の classify() が代表ループを P1〜P4 に分類することをユニットテストで固定。
feat(joinir): Phase 247-EX - DigitPos dual-value architecture Extends DigitPos promotion to generate TWO carriers for Pattern A/B support: - Boolean carrier (is_digit_pos) for break conditions - Integer carrier (digit_value) for NumberAccumulation ## Implementation 1. **DigitPosPromoter** (loop_body_digitpos_promoter.rs) - Generates dual carriers: is_<var> (bool) + <base>_value (int) - Smart naming: "digit_pos" → "digit" (removes "_pos" suffix) 2. **UpdateEnv** (update_env.rs) - Context-aware promoted variable resolution - Priority: <base>_value (int) → is_<var> (bool) → standard - Pass promoted_loopbodylocals from CarrierInfo 3. **Integration** (loop_with_break_minimal.rs) - UpdateEnv constructor updated to pass promoted list ## Test Results - **Before**: 925 tests PASS - **After**: 931 tests PASS (+6 new tests, 0 failures) ## New Tests - test_promoted_variable_resolution_digit_pos - Full dual-value - test_promoted_variable_resolution_fallback_to_bool - Fallback - test_promoted_variable_not_a_carrier - Error handling ## Impact | Pattern | Before | After | |---------|--------|-------| | _parse_number | ✅ Works (bool only) | ✅ Works (bool used, int unused) | | _atoi | ❌ Failed (missing int) | ✅ READY (int carrier available!) | 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-11 15:08:14 +09:00
- Phase 245-EX / 245C:
feat(joinir): Phase 248 - Normalized JoinIR infrastructure Major refactoring of JoinIR normalization pipeline: Key changes: - Structured→Normalized→MIR(direct) pipeline established - ShapeGuard enhanced with Pattern2 loop validation - dev_env.rs: New development fixtures and env control - fixtures.rs: jsonparser_parse_number_real fixture - normalized_bridge/direct.rs: Direct MIR generation from Normalized - pattern2_step_schedule.rs: Extracted step scheduling logic Files changed: - normalized.rs: Enhanced NormalizedJoinModule with DevEnv support - shape_guard.rs: Pattern2-specific validation (+300 lines) - normalized_bridge.rs: Unified bridge with direct path - loop_with_break_minimal.rs: Integrated step scheduling - Deleted: step_schedule.rs (moved to pattern2_step_schedule.rs) New files: - param_guess.rs: Loop parameter inference - pattern2_step_schedule.rs: Step scheduling for Pattern2 - phase43-norm-canon-p2-mid.md: Design doc Tests: 937/937 PASS (+6 from baseline 931) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 03:15:45 +09:00
- `_parse_number` のループについて、ループ変数 `p` の header/break 条件と `p = p + 1` 更新を Pattern2 + ExprLowerer 経路に載せて本番化。
feat(joinir): Phase 247-EX - DigitPos dual-value architecture Extends DigitPos promotion to generate TWO carriers for Pattern A/B support: - Boolean carrier (is_digit_pos) for break conditions - Integer carrier (digit_value) for NumberAccumulation ## Implementation 1. **DigitPosPromoter** (loop_body_digitpos_promoter.rs) - Generates dual carriers: is_<var> (bool) + <base>_value (int) - Smart naming: "digit_pos" → "digit" (removes "_pos" suffix) 2. **UpdateEnv** (update_env.rs) - Context-aware promoted variable resolution - Priority: <base>_value (int) → is_<var> (bool) → standard - Pass promoted_loopbodylocals from CarrierInfo 3. **Integration** (loop_with_break_minimal.rs) - UpdateEnv constructor updated to pass promoted list ## Test Results - **Before**: 925 tests PASS - **After**: 931 tests PASS (+6 new tests, 0 failures) ## New Tests - test_promoted_variable_resolution_digit_pos - Full dual-value - test_promoted_variable_resolution_fallback_to_bool - Fallback - test_promoted_variable_not_a_carrier - Error handling ## Impact | Pattern | Before | After | |---------|--------|-------| | _parse_number | ✅ Works (bool only) | ✅ Works (bool used, int unused) | | _atoi | ❌ Failed (missing int) | ✅ READY (int carrier available!) | 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-11 15:08:14 +09:00
- FunctionScopeCapture / CapturedEnv を拡張し、関数パラメータ（例: `s`, `len`）をループ条件/本体で読み取り専用なら CapturedEnv 経由で ConditionEnv に載せるようにした。
- これにより、`p < s.length()` のような header 条件や JsonParser 系ループでのパラメータ参照が、ExprLowerer/ScopeManager から安全に解決される。
feat(joinir): Phase 248 - Normalized JoinIR infrastructure Major refactoring of JoinIR normalization pipeline: Key changes: - Structured→Normalized→MIR(direct) pipeline established - ShapeGuard enhanced with Pattern2 loop validation - dev_env.rs: New development fixtures and env control - fixtures.rs: jsonparser_parse_number_real fixture - normalized_bridge/direct.rs: Direct MIR generation from Normalized - pattern2_step_schedule.rs: Extracted step scheduling logic Files changed: - normalized.rs: Enhanced NormalizedJoinModule with DevEnv support - shape_guard.rs: Pattern2-specific validation (+300 lines) - normalized_bridge.rs: Unified bridge with direct path - loop_with_break_minimal.rs: Integrated step scheduling - Deleted: step_schedule.rs (moved to pattern2_step_schedule.rs) New files: - param_guess.rs: Loop parameter inference - pattern2_step_schedule.rs: Step scheduling for Pattern2 - phase43-norm-canon-p2-mid.md: Design doc Tests: 937/937 PASS (+6 from baseline 931) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 03:15:45 +09:00
- Phase 245B-IMPL:
- `_parse_number` 本体で `num_str = num_str + ch` を LoopState キャリアとして扱い、Program(JSON) フィクスチャ `jsonparser_parse_number_real` を Structured→Normalized→MIR(direct) で dev テスト固定（出力は num_str 文字列）。
feat(joinir): Phase 247-EX - DigitPos dual-value architecture Extends DigitPos promotion to generate TWO carriers for Pattern A/B support: - Boolean carrier (is_digit_pos) for break conditions - Integer carrier (digit_value) for NumberAccumulation ## Implementation 1. **DigitPosPromoter** (loop_body_digitpos_promoter.rs) - Generates dual carriers: is_<var> (bool) + <base>_value (int) - Smart naming: "digit_pos" → "digit" (removes "_pos" suffix) 2. **UpdateEnv** (update_env.rs) - Context-aware promoted variable resolution - Priority: <base>_value (int) → is_<var> (bool) → standard - Pass promoted_loopbodylocals from CarrierInfo 3. **Integration** (loop_with_break_minimal.rs) - UpdateEnv constructor updated to pass promoted list ## Test Results - **Before**: 925 tests PASS - **After**: 931 tests PASS (+6 new tests, 0 failures) ## New Tests - test_promoted_variable_resolution_digit_pos - Full dual-value - test_promoted_variable_resolution_fallback_to_bool - Fallback - test_promoted_variable_not_a_carrier - Error handling ## Impact | Pattern | Before | After | |---------|--------|-------| | _parse_number | ✅ Works (bool only) | ✅ Works (bool used, int unused) | | _atoi | ❌ Failed (missing int) | ✅ READY (int carrier available!) | 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-11 15:08:14 +09:00
- Phase 247-EX:
- DigitPos promotion を二重値化し、`digit_pos` から boolean carrier `is_digit_pos`（ConditionOnly）と integer carrier `digit_value`（LoopState）を生成。
- UpdateEnv で `digit_pos` 解決時に `digit_value` を優先し、NumberAccumulation（`result = result * 10 + digit_pos`）と break 条件の両方で DigitPos パターンが安全に利用可能に。
- 現在: `cargo test --release --lib` で 931/931 テスト PASS（既知 FAIL なし）。
Phase 33 NORM canon test: enforce normalized dev route for P1/P2/JP mini
2025-12-11 20:54:33 +09:00
- Phase 28-NORM-P2（dev-only）:
- Normalized JoinIR のミニ実装を Pattern1 に続き Pattern2 最小ケースまで拡張（Structured→Normalized→Structured を比較）。
- 対応外の Structured JoinModule では normalize_pattern2_minimal が Fail-Fast するようガードを追加し、normalized_dev テストで固定。
- Phase 29-NORM-P2-APPLY（dev-only）:
- Phase 34 の break fixture（i/acc/n の単純 break ループ）を Structured→Normalized→Structured の往復に通し、VM 実行結果が Structured 直経路と一致することを dev テストで固定。
- ガードは 3 パラメータまで緩和しつつ、DigitPos/Trim などの重いキャリアはまだ非対応のまま。
- Phase 30-NORM-P2-DEV-RUN（dev-only）:
- JoinIR runner に `NYASH_JOINIR_NORMALIZED_DEV_RUN=1` を追加し、Pattern1/2 ミニケースだけ Structured→Normalized→Structured を挟んで dev 実行できるようにした（`normalized_dev` + debug 限定）。通常経路（Structured→MIR）は不変。
- Phase 31-NORM-JP-MINI（dev-only）:
- JsonParser 系のシンプルな P2 ループ（skip_whitespace ミニ fixture）を Structured→Normalized→Structured 経由でも実行し、runner dev スイッチの比較テストで Structured 直経路と一致することを固定。
- Phase 32-NORM-CANON-PREP（dev-only）:
- JoinIR→MIR ブリッジの入口を `bridge_joinir_to_mir` に一本化し、normalized_dev スイッチ（feature + env）で Structured→Normalized→Structured の dev roundtrip を切り替える準備を整えた。P1/P2/JP mini の比較テストも VM ブリッジ経路で追加。
- Phase 33-NORM-CANON-TEST（dev-only）:
- P1/P2（Phase 34 break fixture）/JsonParser skip_ws mini について、normalized_dev ON 時は shape_guard 経由で必ず Normalized roundtrip を通すようブリッジと runner を固めた。normalized_joinir_min.rs の runner/VM 比較テストを拡張し、Normalized が壊れたら dev スイートが必ず赤になるようにした（本番 CLI は従来どおり Structured→MIR）。
Add dev normalized→MIR bridge for P1/P2 mini and JP _atoi
2025-12-11 22:12:46 +09:00
- Phase 34-NORM-ATOI-DEV（dev-only）:
- JsonParser `_atoi` ミニループ（digit_pos→digit_value + NumberAccumulation）を normalized_dev 経路に載せ、Structured↔Normalized↔Structured の VM 実行結果が一致することをフィクスチャテストで固定。`jsonparser_atoi_mini` を shape_guard で認識し、既定経路は引き続き Structured→MIR のまま。
- Phase 35-NORM-BRIDGE-MINI（dev-only）:
- P1/P2 ミニ + JsonParser skip_ws/atoi ミニを Normalized→MIR 直ブリッジで実行できるようにし、normalized_dev ON 時は Structured→Normalized→MIR（復元なし）経路との比較テストで結果一致を固定。既定経路（Structured→MIR）は不変。
Document Phase 36 normalized direct bridge
2025-12-11 22:52:17 +09:00
- Phase 36-NORM-BRIDGE-DIRECT（dev-only）:
- Normalized ブリッジを direct 実装（Normalized→MIR）と Structured 再構成に分離し、shape_guard で P1/P2 ミニ + JsonParser skip_ws/atoi ミニだけ direct 経路に通すよう整理。非対応は `[joinir/normalized-bridge/fallback]` ログ付きで再構成に落とし、テストで direct/従来経路の VM 出力一致を固定。
feat(joinir): Phase 248 - Normalized JoinIR infrastructure Major refactoring of JoinIR normalization pipeline: Key changes: - Structured→Normalized→MIR(direct) pipeline established - ShapeGuard enhanced with Pattern2 loop validation - dev_env.rs: New development fixtures and env control - fixtures.rs: jsonparser_parse_number_real fixture - normalized_bridge/direct.rs: Direct MIR generation from Normalized - pattern2_step_schedule.rs: Extracted step scheduling logic Files changed: - normalized.rs: Enhanced NormalizedJoinModule with DevEnv support - shape_guard.rs: Pattern2-specific validation (+300 lines) - normalized_bridge.rs: Unified bridge with direct path - loop_with_break_minimal.rs: Integrated step scheduling - Deleted: step_schedule.rs (moved to pattern2_step_schedule.rs) New files: - param_guess.rs: Loop parameter inference - pattern2_step_schedule.rs: Step scheduling for Pattern2 - phase43-norm-canon-p2-mid.md: Design doc Tests: 937/937 PASS (+6 from baseline 931) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 03:15:45 +09:00
- Phase 37-NORM-JP-REAL（dev-only）:
- JsonParser `_skip_whitespace` 本体の P2 ループを Program(JSON) フィクスチャで Structured→Normalized→MIR(direct) に通し、Structured 直経路との VM 出力一致を比較するテストを追加。`extract_value` が `&&`/`||` を BinOp として扱えるようにし、Break パターンの param 推定を柔軟化して real 形状でも panic しないようにした。
- Phase 38-NORM-OBS（dev-only）:
- Normalized/JoinIR dev 経路のログカテゴリを `[joinir/normalized-bridge/*]` / `[joinir/normalized-dev/shape]` に統一し、`JOINIR_TEST_DEBUG` 下だけ詳細を出すよう静音化。Verifier/Fail‑Fast メッセージも shape/役割付きに整え、デバッグ観測性を上げつつ通常実行のノイズを減らした。
- Phase 43-A（dev-only）:
- JsonParser `_atoi` 本体の Program(JSON) フィクスチャを normalized_dev に追加し、Structured→Normalized→MIR(direct) と Structured→MIR の VM 出力を比較するテストで一致を固定（符号あり/なしの簡易パス対応。canonical 切替は後続フェーズ）。
- Phase 43-C（dev-only）:
- JsonParser `_parse_number` 本体の Program(JSON) フィクスチャを normalized_dev に追加し、Structured→Normalized→MIR(direct) と Structured→MIR の VM 出力を比較するテストで一致を固定（num_str は現状仕様のまま据え置き、P2-Mid の足慣らし）。
feat(joinir): Phase 46 - P2-Mid canonical Normalized promotion Promote P2-Mid patterns (_atoi real, _parse_number real) to canonical Normalized→MIR(direct) route, completing P2 line transition. Canonical set expansion (Phase 41 → Phase 46): - P2-Core: Pattern2Mini, skip_ws mini/real, atoi mini - P2-Mid: atoi real, parse_number real (NEW) All JsonParser P2 loops (_skip_whitespace, _atoi, _parse_number) now canonical Normalized - Structured→MIR is legacy/comparison-only. Key changes: - shape_guard.rs: Expanded is_canonical_shape() (+2 patterns) - JsonparserAtoiReal - JsonparserParseNumberReal - Made NormalizedDevShape enum public - bridge.rs: Updated canonical routing comments (Phase 41 → 46) - normalized.rs: Made shape_guard module public - normalized_joinir_min.rs: Added Phase 46 canonical verification test - phase46-norm-canon-p2-mid.md: Complete design documentation Out of scope (deferred): - P3/P4 Normalized support → NORM-P3/NORM-P4 phases - Selfhost complex loops → separate phases Benefits: - Clear P2 boundary: All JsonParser P2 = Normalized canonical - Infrastructure validation: Phase 43/245B proven production-ready - Simplified mental model: P2 = Normalized-first, P3/P4 = future Tests: 937/937 PASS (lib), 20/20 PASS (normalized_dev feature) Phase 46 test: test_phase46_canonical_set_includes_p2_mid ✅
2025-12-12 04:40:46 +09:00
- **Phase 46-NORM-CANON-P2-MID（実装済み✅ 2025-12-12）**:
- P2-Mid パターン（_atoi real, _parse_number real）を canonical Normalized に昇格。
- Canonical set 拡張: P2-Core（mini + skip_ws + atoi mini）+ P2-Mid（atoi real + parse_number real）。
- JsonParser P2 ライン（_skip_whitespace/_atoi/_parse_number）全て canonical Normalized 化完了。
- P3/P4 Normalized 対応は NORM-P3/NORM-P4 フェーズで実施（今回スコープ外）。
- 937/937 tests PASS。
Phase47-B/C: extend P3 normalized shapes and quiet dev warnings
2025-12-12 07:13:34 +09:00
- **Phase 47-B/C（P3 if-sum 拡張 + canonical 化 ✅ 2025-12-21）**:
- フィクスチャ追加: `pattern3_if_sum_multi_min`（sum+count）/ `jsonparser_if_sum_min`（JsonParser 簡約形）
- ShapeGuard: `Pattern3IfSumMulti` / `Pattern3IfSumJson` 追加、capability=P3IfSum、canonical set に P3 minimal/multi/json を追加
- Normalizer/Bridge: P3 if-sum minimal/multi/json を Structured→Normalized→MIR(direct) で dev A/B、canonical ルートでも常時 Normalized 経由
- テスト: normalized_joinir_min.rs に P3 if-sum multi/json の VM ブリッジ比較テスト追加（Structured と一致）
feat(joinir): Phase 45 - JoinIR mode unification Unified JoinIR routing logic through centralized JoinIrMode enum: Key changes: - Added JoinIrMode enum (StructuredOnly / NormalizedDev / NormalizedCanonical) - Added current_joinir_mode() for centralized mode determination - Refactored normalized_dev_enabled() as thin wrapper over mode enum - Updated bridge.rs: mode-based routing with canonical P2-Core special handling - Updated runner.rs: mode pattern matching for dev roundtrip path Files modified: - joinir_dev.rs: JoinIrMode enum + current_joinir_mode() (+49 lines) - bridge.rs: Replaced boolean checks with mode pattern matching (+29 lines) - runner.rs: Mode-based routing logic (+9 lines) - CURRENT_TASK.md: Phase 45 implementation summary Documentation: - phase45-norm-mode-design.md: Complete design spec and implementation guide Behavior preservation: - Canonical P2-Core shapes: always Normalized→MIR(direct) (mode-independent) - NormalizedDev mode: Structured→Normalized→MIR for supported shapes - StructuredOnly mode: Structured→MIR direct (default) Tests: 937/937 PASS (no regression, pure refactor) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 03:31:58 +09:00
- **Phase 45-NORM-MODE（実装済み✅ 2025-12-12）**:
- JoinIR モード一本化: バラバラだったフラグ/feature を `JoinIrMode` enum に集約（StructuredOnly / NormalizedDev / NormalizedCanonical）。
- `current_joinir_mode()` でモード取得、bridge/runner で `normalized_dev_enabled()` → mode pattern matching に移行。
- Canonical P2-Core は mode 無視で常に Normalized→MIR(direct)、それ以外は mode に従う統一ルーティング。
- 937/937 tests PASS（既存挙動完全保持のリファクタ）。
refactor(joinir): Phase 44 - Capability-based shape guard Refactor shape detection from function-name-based to capability-based architecture for better extensibility and maintainability. Key changes: - ShapeCapabilityKind enum: P2CoreSimple/SkipWs/Atoi/ParseNumber - ShapeCapability: Capability descriptor with future extensibility - Helper functions: - capability_for_shape(): Map shape to capability - is_canonical_shape(): Exact shape-level check - is_p2_core_capability(): Broad capability family check - is_supported_by_normalized(): Normalized dev support Benefits: - Extensibility: Easy to add new capability kinds - Clarity: Shape purpose explicit in kind names - Maintainability: Centralized mapping vs scattered ifs - Future-ready: Infrastructure for carrier roles, method signatures Backward compatibility: - Zero behavioral changes (pure refactoring) - Canonical set preserved: Pattern2Mini, skip_ws mini/real, atoi mini - All existing code paths unchanged Tests: 937/937 PASS Files: +78 lines (shape_guard.rs), design doc created
2025-12-12 04:06:03 +09:00
- **Phase 44-SHAPE-CAP（実装済み✅ 2025-12-12）**:
- Shape検出を capability-based に変更: `NormalizedDevShape` → `ShapeCapability` 抽象化層導入。
- `ShapeCapabilityKind` 4種: P2CoreSimple / P2CoreSkipWs / P2CoreAtoi / P2MidParseNumber。
- Shape-level (`is_canonical_shape`) と Capability-level (`is_p2_core_capability`) の二層 API でパターン拡張性を確保。
- 既存挙動完全保持（canonical set: Pattern2Mini, skip_ws mini/real, atoi mini のまま）、937/937 tests PASS。
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
### 1. いまコード側で意識しておきたいフォーカス
docs(joinir): Phase 43/245B Normalized JoinIR completion summary Complete documentation consolidation for Phases 26-45 Normalized JoinIR infrastructure. All components are implemented and tested (937/937 PASS). Key additions: - PHASE_43_245B_NORMALIZED_COMPLETION.md: Master completion summary - Architecture components (Mode, Capability, Carriers, DigitPos, etc.) - Supported loop patterns (P1, P2 variants including JsonParser) - Complete file reference guide - Test coverage documentation - Future expansion roadmap Updates: - CURRENT_TASK.md: Moved Phase 43/245B to completed section - joinir-architecture-overview.md: Phases 43-45 marked complete - Historical docs: Added completion banners with links - phase223-loopbodylocal-condition-design.md - phase223-loopbodylocal-condition-inventory.md - PHASE_223_SUMMARY.md - phase245b-num_str-carrier-design.md - phase245c-function-param-capture-summary.md Documentation hierarchy established: - Master summary → individual design docs - Historical docs → completion summary - Cross-references complete across all docs Status: Phase 43/245B Normalized infrastructure COMPLETE ✅
2025-12-12 04:19:06 +09:00
- **Phase 43/245B Normalized 完了** により JoinIR ループ基盤（Pattern1–4 + ExprLowerer + ScopeManager + CapturedEnv + Normalized layer）は一応の完成状態に入ったので、当面は:
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
- 既存パターン/箱の範囲内での **バグ修正・Fail‑Fast/invariant 追加・テスト強化** を優先する。
- JsonParser/selfhost への新しい適用や大きな仕様拡張は、docs 側で Phase 設計が固まってからコード側に持ち込む。
feat(joinir): Phase 247-EX - DigitPos dual-value architecture Extends DigitPos promotion to generate TWO carriers for Pattern A/B support: - Boolean carrier (is_digit_pos) for break conditions - Integer carrier (digit_value) for NumberAccumulation ## Implementation 1. **DigitPosPromoter** (loop_body_digitpos_promoter.rs) - Generates dual carriers: is_<var> (bool) + <base>_value (int) - Smart naming: "digit_pos" → "digit" (removes "_pos" suffix) 2. **UpdateEnv** (update_env.rs) - Context-aware promoted variable resolution - Priority: <base>_value (int) → is_<var> (bool) → standard - Pass promoted_loopbodylocals from CarrierInfo 3. **Integration** (loop_with_break_minimal.rs) - UpdateEnv constructor updated to pass promoted list ## Test Results - **Before**: 925 tests PASS - **After**: 931 tests PASS (+6 new tests, 0 failures) ## New Tests - test_promoted_variable_resolution_digit_pos - Full dual-value - test_promoted_variable_resolution_fallback_to_bool - Fallback - test_promoted_variable_not_a_carrier - Error handling ## Impact | Pattern | Before | After | |---------|--------|-------| | _parse_number | ✅ Works (bool only) | ✅ Works (bool used, int unused) | | _atoi | ❌ Failed (missing int) | ✅ READY (int carrier available!) | 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-11 15:08:14 +09:00
- 直近のコード側フォーカス候補:
docs(joinir): Phase 43/245B Normalized JoinIR completion summary Complete documentation consolidation for Phases 26-45 Normalized JoinIR infrastructure. All components are implemented and tested (937/937 PASS). Key additions: - PHASE_43_245B_NORMALIZED_COMPLETION.md: Master completion summary - Architecture components (Mode, Capability, Carriers, DigitPos, etc.) - Supported loop patterns (P1, P2 variants including JsonParser) - Complete file reference guide - Test coverage documentation - Future expansion roadmap Updates: - CURRENT_TASK.md: Moved Phase 43/245B to completed section - joinir-architecture-overview.md: Phases 43-45 marked complete - Historical docs: Added completion banners with links - phase223-loopbodylocal-condition-design.md - phase223-loopbodylocal-condition-inventory.md - PHASE_223_SUMMARY.md - phase245b-num_str-carrier-design.md - phase245c-function-param-capture-summary.md Documentation hierarchy established: - Master summary → individual design docs - Historical docs → completion summary - Cross-references complete across all docs Status: Phase 43/245B Normalized infrastructure COMPLETE ✅
2025-12-12 04:19:06 +09:00
- ~~Phase 246-EX（コード）~~: ✅ 完了（_atoi Integration, Phase 43/245B の一部）
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
- Pattern1–4 / ExprLowerer / ScopeManager まわりで、by-name ハードコードやサイレントフォールバックが見つかった場合は、
CarrierInfo / ConditionEnv / Scope 情報を使って「構造で」直す。
### 2. 直近で意識しておきたい設計の芯
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
- **Loop パターン空間**は有限で整理済み:
- P1: Simple While
- P2: Break
- P3: If‑PHI（単一/複数キャリア）
- P4: Continue（then/else‑continue 正規化込み）
- P5: LoopBodyLocal 昇格（Trim/JsonParser 用の部分適用）
- 「増やすべき」は新しい Pattern ではなく、既存 Pattern の前処理箱:
- BoolExprLowerer / ConditionEnv / LoopConditionScopeBox / LoopBodyCarrierPromoter /
TrimLoopHelper / ComplexAddendNormalizer / LoopBodyLocalEnv / UpdateEnv などで
条件式とキャリア更新を吸収し、Pattern1–4 は「ループ骨格」に専念させる方針。
- Fail‑Fast 原則:
- JoinIR 以外のループ lowering パスは存在しない（LoopBuilder は削除済み）。
- 「わからないパターン」は必ず `[joinir/freeze]` 系の明示エラーにして、サイレントフォールバックはしない。
feat(llvm): Phase 134-A - mir_call.py unified 設計完成 681行の giant ファイルを機能別に分割し、箱化モジュール化を達成。 Changes: - NEW: src/llvm_py/mir_call_compat.py (120 lines) - JSON v0/v1 互換層を一元管理 - normalize_callee(), detect_format_version() - NEW: src/llvm_py/instructions/mir_call/ (7 files) - __init__.py: Canonical Dispatcher (lower_mir_call) - global_call.py: Global関数呼び出し (90 lines) - method_call.py: Boxメソッド呼び出し (175 lines) - constructor_call.py: Boxコンストラクタ (122 lines) - closure_call.py: Closure生成 (87 lines) - value_call.py: 動的関数値呼び出し (112 lines) - extern_call.py: 外部C ABI呼び出し (135 lines) - ARCHIVE: mir_call.py → mir_call_legacy.py Technical Achievements: ✅ mir_call.py: 681行 → 分割（各 80-175行、責務 明確） ✅ Phase 133 ConsoleLlvmBridge パターンを継承 ✅ NYASH_MIR_UNIFIED_CALL フラグ完全廃止 ✅ legacy dispatcher 削除（NotImplementedError 根治） ✅ JSON v0/v1 互換層を mir_call_compat.py に一元化 ✅ Fail-Fast 原則確立 ✅ テスト: 全 mir_call 関連テスト PASS Design Principles Inherited: - Phase 133 ConsoleLlvmBridge 箱化パターン継承 - Each module has clear responsibility - mir_call_compat.py で Phase 124+ v0削除が容易 - テスト分割で保守性大幅向上 Next Phase: Phase 134-B - StringBox bridge 分離（boxcall.py:130-282） Phase 134-C - CollectionBox bridge 分離（boxcall.py:325-375） 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-04 12:06:34 +09:00
---
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
## ✅ 最近まとまった大きな塊（超要約）
ここ半年くらいで終わっている主な塊だけをざっくり書くね。
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
細かいタスク・バグ票・議論は `docs/development/current/main/phase-*.md` と
`docs/development/current/main/joinir-architecture-overview.md` に全部残っているので、必要になったときだけそちらを読む想定。
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
- **LoopBuilder 削除ライン（Phase 180 前後）**
- LoopBuilder を dev‑only → hard freeze → 物理削除まで完了。
- Loop lowering の SSOT を JoinIR に一本化。
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
- **LoopPattern / Router ライン（Phase 170–179, 244-EX）**
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
- LoopFeatures / LoopPatternKind / PatternRouter / PatternPipelineContext を整備。
- Pattern1–4 の検出・ルーティングを「構造ベース＋AST features」で統一（関数名ベタ書き依存を除去）。
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
- Phase 244-EX で代表ループ（P1〜P4）の classify() 結果をユニットテストで固定。
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
- **Exit / Boundary / ValueId ライン（Phase 172–205）**
- ExitMeta / ExitLineReconnector / JoinInlineBoundary(+Builder) / LoopHeaderPhiBuilder を箱化。
- JoinValueSpace（Param/Local 領域）＋ PHI 契約 Verifier で ValueId 衝突と PHI 破損を根治。
- **P5(Trim/JsonParser) ライン（Phase 171–176, 173–175, 190–193）**
- LoopBodyLocal 昇格パイプライン（Trim, `_skip_whitespace`, `_parse_string` 簡易版）を構築。
- StringAppend / NumberAccumulation / Complex addend 正規化など、更新式まわりの箱を揃えた。
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
- **P3/P4 (If‑PHI / Continue) 汎用化ライン（Phase 195–196, 212–215, 220–242-EX）**
- multi‑carrier P3 の JoinIR 生成を整理し、if‑sum 最小パターンを AST ベースで一般化（sum+count まで無改造対応）。
- Pattern3/4 if‑sum/continue lowerer を分離箱にして、legacy PoC lowerer と by-name ハードコード（`"sum"`, `"count"`）を削除。
- Pattern4CarrierAnalyzer を純粋な「キャリア解析箱」として仕上げ、continue 正規化・更新式解析をユニットテストで固定。
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
このあたりが「JoinIR ループ基盤の芯」で、以降の Phase は JsonParser/selfhost の各ループへの適用フェーズ、という位置づけだよ。
feat(llvm): Phase 134-A - mir_call.py unified 設計完成 681行の giant ファイルを機能別に分割し、箱化モジュール化を達成。 Changes: - NEW: src/llvm_py/mir_call_compat.py (120 lines) - JSON v0/v1 互換層を一元管理 - normalize_callee(), detect_format_version() - NEW: src/llvm_py/instructions/mir_call/ (7 files) - __init__.py: Canonical Dispatcher (lower_mir_call) - global_call.py: Global関数呼び出し (90 lines) - method_call.py: Boxメソッド呼び出し (175 lines) - constructor_call.py: Boxコンストラクタ (122 lines) - closure_call.py: Closure生成 (87 lines) - value_call.py: 動的関数値呼び出し (112 lines) - extern_call.py: 外部C ABI呼び出し (135 lines) - ARCHIVE: mir_call.py → mir_call_legacy.py Technical Achievements: ✅ mir_call.py: 681行 → 分割（各 80-175行、責務 明確） ✅ Phase 133 ConsoleLlvmBridge パターンを継承 ✅ NYASH_MIR_UNIFIED_CALL フラグ完全廃止 ✅ legacy dispatcher 削除（NotImplementedError 根治） ✅ JSON v0/v1 互換層を mir_call_compat.py に一元化 ✅ Fail-Fast 原則確立 ✅ テスト: 全 mir_call 関連テスト PASS Design Principles Inherited: - Phase 133 ConsoleLlvmBridge 箱化パターン継承 - Each module has clear responsibility - mir_call_compat.py で Phase 124+ v0削除が容易 - テスト分割で保守性大幅向上 Next Phase: Phase 134-B - StringBox bridge 分離（boxcall.py:130-282） Phase 134-C - CollectionBox bridge 分離（boxcall.py:325-375） 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-04 12:06:34 +09:00
docs(joinir): Phase 43/245B Normalized JoinIR completion summary Complete documentation consolidation for Phases 26-45 Normalized JoinIR infrastructure. All components are implemented and tested (937/937 PASS). Key additions: - PHASE_43_245B_NORMALIZED_COMPLETION.md: Master completion summary - Architecture components (Mode, Capability, Carriers, DigitPos, etc.) - Supported loop patterns (P1, P2 variants including JsonParser) - Complete file reference guide - Test coverage documentation - Future expansion roadmap Updates: - CURRENT_TASK.md: Moved Phase 43/245B to completed section - joinir-architecture-overview.md: Phases 43-45 marked complete - Historical docs: Added completion banners with links - phase223-loopbodylocal-condition-design.md - phase223-loopbodylocal-condition-inventory.md - PHASE_223_SUMMARY.md - phase245b-num_str-carrier-design.md - phase245c-function-param-capture-summary.md Documentation hierarchy established: - Master summary → individual design docs - Historical docs → completion summary - Cross-references complete across all docs Status: Phase 43/245B Normalized infrastructure COMPLETE ✅
2025-12-12 04:19:06 +09:00
- **Phase 43/245B Normalized JoinIR（Phase 26–45 完了）** ✅
- Structured→Normalized→MIR(direct) パイプライン確立
- Mode system (JoinIrMode) + Capability system (ShapeCapabilityKind)
- Pattern1/2 + JsonParser (_skip_whitespace, _atoi, _parse_number) 全対応
- 詳細: [PHASE_43_245B_NORMALIZED_COMPLETION.md](docs/development/current/main/PHASE_43_245B_NORMALIZED_COMPLETION.md)
feat(llvm): Phase 134-A - mir_call.py unified 設計完成 681行の giant ファイルを機能別に分割し、箱化モジュール化を達成。 Changes: - NEW: src/llvm_py/mir_call_compat.py (120 lines) - JSON v0/v1 互換層を一元管理 - normalize_callee(), detect_format_version() - NEW: src/llvm_py/instructions/mir_call/ (7 files) - __init__.py: Canonical Dispatcher (lower_mir_call) - global_call.py: Global関数呼び出し (90 lines) - method_call.py: Boxメソッド呼び出し (175 lines) - constructor_call.py: Boxコンストラクタ (122 lines) - closure_call.py: Closure生成 (87 lines) - value_call.py: 動的関数値呼び出し (112 lines) - extern_call.py: 外部C ABI呼び出し (135 lines) - ARCHIVE: mir_call.py → mir_call_legacy.py Technical Achievements: ✅ mir_call.py: 681行 → 分割（各 80-175行、責務 明確） ✅ Phase 133 ConsoleLlvmBridge パターンを継承 ✅ NYASH_MIR_UNIFIED_CALL フラグ完全廃止 ✅ legacy dispatcher 削除（NotImplementedError 根治） ✅ JSON v0/v1 互換層を mir_call_compat.py に一元化 ✅ Fail-Fast 原則確立 ✅ テスト: 全 mir_call 関連テスト PASS Design Principles Inherited: - Phase 133 ConsoleLlvmBridge 箱化パターン継承 - Each module has clear responsibility - mir_call_compat.py で Phase 124+ v0削除が容易 - テスト分割で保守性大幅向上 Next Phase: Phase 134-B - StringBox bridge 分離（boxcall.py:130-282） Phase 134-C - CollectionBox bridge 分離（boxcall.py:325-375） 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-04 12:06:34 +09:00
---
docs: Update CURRENT_TASK.md with Phase 188 completion summary
2025-12-05 16:00:31 +09:00
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
## 🧭 これからの候補（まだ「やる」とは決めていないメモ）
docs: Update CURRENT_TASK.md with Phase 188 completion summary
2025-12-05 16:00:31 +09:00
docs(joinir): Phase 43/245B Normalized JoinIR completion summary Complete documentation consolidation for Phases 26-45 Normalized JoinIR infrastructure. All components are implemented and tested (937/937 PASS). Key additions: - PHASE_43_245B_NORMALIZED_COMPLETION.md: Master completion summary - Architecture components (Mode, Capability, Carriers, DigitPos, etc.) - Supported loop patterns (P1, P2 variants including JsonParser) - Complete file reference guide - Test coverage documentation - Future expansion roadmap Updates: - CURRENT_TASK.md: Moved Phase 43/245B to completed section - joinir-architecture-overview.md: Phases 43-45 marked complete - Historical docs: Added completion banners with links - phase223-loopbodylocal-condition-design.md - phase223-loopbodylocal-condition-inventory.md - PHASE_223_SUMMARY.md - phase245b-num_str-carrier-design.md - phase245c-function-param-capture-summary.md Documentation hierarchy established: - Master summary → individual design docs - Historical docs → completion summary - Cross-references complete across all docs Status: Phase 43/245B Normalized infrastructure COMPLETE ✅
2025-12-12 04:19:06 +09:00
ここは「やることリスト」ではなく「今後やるとしたらこの辺」というメモだよ。
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
実際に着手するタイミングで、別途 Phase/タスクを切る想定。
docs: Update CURRENT_TASK.md with Phase 188 completion summary
2025-12-05 16:00:31 +09:00
docs(joinir): Phase 43/245B Normalized JoinIR completion summary Complete documentation consolidation for Phases 26-45 Normalized JoinIR infrastructure. All components are implemented and tested (937/937 PASS). Key additions: - PHASE_43_245B_NORMALIZED_COMPLETION.md: Master completion summary - Architecture components (Mode, Capability, Carriers, DigitPos, etc.) - Supported loop patterns (P1, P2 variants including JsonParser) - Complete file reference guide - Test coverage documentation - Future expansion roadmap Updates: - CURRENT_TASK.md: Moved Phase 43/245B to completed section - joinir-architecture-overview.md: Phases 43-45 marked complete - Historical docs: Added completion banners with links - phase223-loopbodylocal-condition-design.md - phase223-loopbodylocal-condition-inventory.md - PHASE_223_SUMMARY.md - phase245b-num_str-carrier-design.md - phase245c-function-param-capture-summary.md Documentation hierarchy established: - Master summary → individual design docs - Historical docs → completion summary - Cross-references complete across all docs Status: Phase 43/245B Normalized infrastructure COMPLETE ✅
2025-12-12 04:19:06 +09:00
1. ~~Phase 245B（コード）~~: ✅ 完了（Phase 43/245B の一部）
2. ~~Phase 246-EX（コード）~~: ✅ 完了（Phase 43/245B の一部）
docs(joinir): Phase 48 - Normalized P4 (Continue) design Complete design documentation for Pattern4 (continue) Normalized support, extending unified Normalized infrastructure to all 4 loop patterns. Design documents: - phase48-norm-p4-design.md: Complete P4 Normalized design (380 lines) - Key insight: continue = immediate TailCallFn(loop_step, ...) (no new instruction!) - Infrastructure reuse: 95%+ from P2/P3 (only ContinueCheck step kind new) - Target loops prioritized: - ◎ _parse_array (skip whitespace) - PRIMARY (Phase 48-A) - ○ _parse_object (skip whitespace) - Extended - △ _unescape_string, _parse_string - Later - Control flow: ContinueCheck before Updates (skip processing early) - Same EnvLayout/ConditionEnv/CarrierInfo/ExitLine as P2/P3 - Implementation strategy: dev-only → canonical (proven approach) Architecture: - Unified Normalized for P1/P2/P3/P4 (all patterns same pipeline) - P4 uses loop_step(env, k_exit) skeleton (same as P2/P3) - continue semantics: TailCallFn = skip to next iteration (CPS natural fit) Benefits: - 95% infrastructure reuse from P2/P3 - No new JpInst needed (continue = existing TailCallFn) - Incremental rollout (dev → canonical) - Clear semantic: continue = immediate recursion Implementation roadmap: - Phase 48-A: Minimal continue (dev-only) - Phase 48-B: Extended patterns (multi-carrier) - Phase 48-C: Canonical promotion Updates: - joinir-architecture-overview.md: Added Phase 48 section - CURRENT_TASK.md: Phase 48 entry (Design Complete) - phase47-norm-p3-design.md: Minor formatting Status: Design phase complete (doc-only, no implementation yet) Next: Phase 48-A implementation (when requested)
2025-12-12 06:06:39 +09:00
3. **Phase 47-NORM-P3（設計完了＋最小dev＋direct✅ 2025-12-12）**: Pattern3 Normalized 設計
docs(joinir): Phase 47 - Normalized P3 (If-Sum) design Complete design for extending Normalized JoinIR to Pattern3 (if-sum) loops, reusing 90% of existing P2 infrastructure. Key insight: P3 already uses P2's Structured JoinIR foundation (Phase 220 ConditionEnv integration), so Normalized extension is straightforward. Design documents: - phase47-norm-p3-design.md: Complete P3 Normalized design - Infrastructure reuse analysis (ConditionEnv, CarrierInfo, ExitLine) - Representative loops identified (phase212_if_sum_min primary target) - StepScheduleBox extension (IfCond, ThenUpdates, ElseUpdates) - JpInst reuse (If instruction already exists) - Implementation strategy (dev-only → canonical) - File impact estimate (~365 lines, pure additive) - phase47-test-files-inventory.md: P3 test file catalog - 3 P3 test files analyzed - phase212_if_sum_min.hako: Single carrier (PRIMARY) - phase217_if_sum_multi_min.hako: Multi-carrier (sum + count) - phase218_json_if_sum_min.hako: Variable accumulation (sum + i) Architecture: - Unified Normalized for P1/P2/P3 (same pipeline) - Conditional updates only difference vs P2 - No P2 code changes needed (pure additive) Benefits: - 90% infrastructure reuse from P2 - Proven incremental rollout (dev → canonical) - Clear path to P4 (continue pattern) Implementation roadmap: - Phase 47-A: Minimal sum_count (dev-only) - Phase 47-B: array_filter (body-local + method calls) - Phase 47-C: Canonical promotion Updates: - joinir-architecture-overview.md: Added Phase 47 section - CURRENT_TASK.md: Updated Phase 47 entry (Design Complete) Status: Design phase complete, ready for implementation
2025-12-12 04:50:26 +09:00
- 設計詳細: [phase47-norm-p3-design.md](docs/development/current/main/phase47-norm-p3-design.md)
- P3 if-sum を Normalized JoinIR に載せる設計。P2 と同じ ConditionEnv/CarrierInfo/ExitLine インフラを再利用。
docs(joinir): Phase 48 - Normalized P4 (Continue) design Complete design documentation for Pattern4 (continue) Normalized support, extending unified Normalized infrastructure to all 4 loop patterns. Design documents: - phase48-norm-p4-design.md: Complete P4 Normalized design (380 lines) - Key insight: continue = immediate TailCallFn(loop_step, ...) (no new instruction!) - Infrastructure reuse: 95%+ from P2/P3 (only ContinueCheck step kind new) - Target loops prioritized: - ◎ _parse_array (skip whitespace) - PRIMARY (Phase 48-A) - ○ _parse_object (skip whitespace) - Extended - △ _unescape_string, _parse_string - Later - Control flow: ContinueCheck before Updates (skip processing early) - Same EnvLayout/ConditionEnv/CarrierInfo/ExitLine as P2/P3 - Implementation strategy: dev-only → canonical (proven approach) Architecture: - Unified Normalized for P1/P2/P3/P4 (all patterns same pipeline) - P4 uses loop_step(env, k_exit) skeleton (same as P2/P3) - continue semantics: TailCallFn = skip to next iteration (CPS natural fit) Benefits: - 95% infrastructure reuse from P2/P3 - No new JpInst needed (continue = existing TailCallFn) - Incremental rollout (dev → canonical) - Clear semantic: continue = immediate recursion Implementation roadmap: - Phase 48-A: Minimal continue (dev-only) - Phase 48-B: Extended patterns (multi-carrier) - Phase 48-C: Canonical promotion Updates: - joinir-architecture-overview.md: Added Phase 48 section - CURRENT_TASK.md: Phase 48 entry (Design Complete) - phase47-norm-p3-design.md: Minor formatting Status: Design phase complete (doc-only, no implementation yet) Next: Phase 48-A implementation (when requested)
2025-12-12 06:06:39 +09:00
- Phase 47-A: Minimal sum_count（dev-only）として、`phase212_if_sum_min.hako` 相当の最小 if-sum ループを AST ベース lowerer + Structured→Normalized→Structured roundtrip（Runner 経路）＋ Normalized→MIR(direct) で検証済み。
- Phase 47-B 以降: array_filter など body-local/MethodCall を含む P3 ループや canonical 昇格は今後の実装フェーズで扱う。
feat(joinir): Phase 53 - SELFHOST-NORM-DEV-EXPAND implementation Expanded selfhost dev Normalized target with 2 practical P2/P3 loop variations, strengthened structural signature axis, and implemented two-stage detection. Key Changes: 1. Documentation (phase49-selfhost-joinir-depth2-design.md +128 lines): - Added Phase 53 section with candidate selection rationale - Documented two-stage detector strategy (structural primary + dev-only name guard) - Defined structural axis strengthening (carrier count/type, branch patterns) 2. Fixtures (+210 lines): - selfhost_args_parse_p2.program.json (60 lines): P2 with String carrier + conditional branching - selfhost_stmt_count_p3.program.json (150 lines): P3 with 5 carriers + multi-branch if-else 3. Structured Builders (fixtures.rs +48 lines): - build_selfhost_args_parse_p2_structured_for_normalized_dev() - build_selfhost_stmt_count_p3_structured_for_normalized_dev() 4. ShapeGuard Two-Stage Detection (shape_guard.rs +80 lines): - Added SelfhostArgsParseP2/SelfhostStmtCountP3 to NormalizedDevShape enum - Implemented is_selfhost_args_parse_p2(): P2 core family + name guard - Implemented is_selfhost_stmt_count_p3(): 2-10 carrier check + name guard - Updated capability_for_shape() mappings 5. Bridge Integration (bridge.rs +8 lines, normalized.rs +10 lines): - Added shape handlers delegating to existing normalizers - Added roundtrip reconstruction handlers 6. Entry Point Registration (ast_lowerer/mod.rs +2 lines): - Registered selfhost_args_parse_p2/selfhost_stmt_count_p3 as LoopFrontend routes 7. Dev VM Comparison Tests (normalized_joinir_min.rs +40 lines): - normalized_selfhost_args_parse_p2_vm_bridge_direct_matches_structured() - normalized_selfhost_stmt_count_p3_vm_bridge_direct_matches_structured() 8. Test Context Fix (dev_env.rs): - Added thread-local test context depth counter - Fixed deadlock in nested test_ctx() calls via reentrant with_dev_env_if_unset() Structural Axis Growth: P2 family: - Carrier count: 1-3 (unchanged) - NEW: Type diversity (Integer/String mixed) - NEW: Conditional branching patterns (Eq-heavy comparisons) P3 family: - NEW: Carrier count upper bound: 2-10 (was 2-4) - NEW: Multi-branch if-else (5+ branches with nested structure) - NEW: Complex conditional patterns Test Results: - normalized_dev: 40/40 PASS (including 2 new tests) - lib regression: 939 PASS, 56 ignored - Existing behavior unchanged (normalized_dev feature-gated) Phase 53 Achievements: ✅ P2/P3 each gained 1 practical variation (2 total) ✅ Two-stage detection: structural primary + dev-only name guard ✅ Structural axis expanded: 4 axes (carrier count/type/Compare/branch patterns) ✅ All tests PASS, no regressions ✅ Test context deadlock fixed (0.04s for 29 tests) Files Modified: 14 files Lines Added: ~516 lines (net) Implementation: Pure additive (feature-gated) Next Phase (54+): - Accumulate 6+ loops per P2/P3 family - Achieve 5+ stable structural axes - Target < 5% false positive rate - Then shrink/remove name guard scope
2025-12-12 16:40:20 +09:00
4. **Phase 48-NORM-P4（設計完了✅＋48-A/B/C canon 完了✅ 2025-12-12→2026-01-XX）**: Pattern4 (continue) Normalized 設計＋実装
docs(joinir): Phase 48 - Normalized P4 (Continue) design Complete design documentation for Pattern4 (continue) Normalized support, extending unified Normalized infrastructure to all 4 loop patterns. Design documents: - phase48-norm-p4-design.md: Complete P4 Normalized design (380 lines) - Key insight: continue = immediate TailCallFn(loop_step, ...) (no new instruction!) - Infrastructure reuse: 95%+ from P2/P3 (only ContinueCheck step kind new) - Target loops prioritized: - ◎ _parse_array (skip whitespace) - PRIMARY (Phase 48-A) - ○ _parse_object (skip whitespace) - Extended - △ _unescape_string, _parse_string - Later - Control flow: ContinueCheck before Updates (skip processing early) - Same EnvLayout/ConditionEnv/CarrierInfo/ExitLine as P2/P3 - Implementation strategy: dev-only → canonical (proven approach) Architecture: - Unified Normalized for P1/P2/P3/P4 (all patterns same pipeline) - P4 uses loop_step(env, k_exit) skeleton (same as P2/P3) - continue semantics: TailCallFn = skip to next iteration (CPS natural fit) Benefits: - 95% infrastructure reuse from P2/P3 - No new JpInst needed (continue = existing TailCallFn) - Incremental rollout (dev → canonical) - Clear semantic: continue = immediate recursion Implementation roadmap: - Phase 48-A: Minimal continue (dev-only) - Phase 48-B: Extended patterns (multi-carrier) - Phase 48-C: Canonical promotion Updates: - joinir-architecture-overview.md: Added Phase 48 section - CURRENT_TASK.md: Phase 48 entry (Design Complete) - phase47-norm-p3-design.md: Minor formatting Status: Design phase complete (doc-only, no implementation yet) Next: Phase 48-A implementation (when requested)
2025-12-12 06:06:39 +09:00
- 設計詳細: [phase48-norm-p4-design.md](docs/development/current/main/phase48-norm-p4-design.md)
- ターゲットループ決定: _parse_array skip whitespace（◎ PRIMARY）、_parse_object（○）、_unescape_string/parse_string（△）
- 設計骨格: `continue` = 即座の `TailCallFn(loop_step, ...)` (新命令不要)
- P1/P2/P3 と同じ `loop_step(env, k_exit)` 骨格に載せる
- インフラ再利用率: 95%+ (StepKind の ContinueCheck のみ追加)
feat(joinir): Phase 53 - SELFHOST-NORM-DEV-EXPAND implementation Expanded selfhost dev Normalized target with 2 practical P2/P3 loop variations, strengthened structural signature axis, and implemented two-stage detection. Key Changes: 1. Documentation (phase49-selfhost-joinir-depth2-design.md +128 lines): - Added Phase 53 section with candidate selection rationale - Documented two-stage detector strategy (structural primary + dev-only name guard) - Defined structural axis strengthening (carrier count/type, branch patterns) 2. Fixtures (+210 lines): - selfhost_args_parse_p2.program.json (60 lines): P2 with String carrier + conditional branching - selfhost_stmt_count_p3.program.json (150 lines): P3 with 5 carriers + multi-branch if-else 3. Structured Builders (fixtures.rs +48 lines): - build_selfhost_args_parse_p2_structured_for_normalized_dev() - build_selfhost_stmt_count_p3_structured_for_normalized_dev() 4. ShapeGuard Two-Stage Detection (shape_guard.rs +80 lines): - Added SelfhostArgsParseP2/SelfhostStmtCountP3 to NormalizedDevShape enum - Implemented is_selfhost_args_parse_p2(): P2 core family + name guard - Implemented is_selfhost_stmt_count_p3(): 2-10 carrier check + name guard - Updated capability_for_shape() mappings 5. Bridge Integration (bridge.rs +8 lines, normalized.rs +10 lines): - Added shape handlers delegating to existing normalizers - Added roundtrip reconstruction handlers 6. Entry Point Registration (ast_lowerer/mod.rs +2 lines): - Registered selfhost_args_parse_p2/selfhost_stmt_count_p3 as LoopFrontend routes 7. Dev VM Comparison Tests (normalized_joinir_min.rs +40 lines): - normalized_selfhost_args_parse_p2_vm_bridge_direct_matches_structured() - normalized_selfhost_stmt_count_p3_vm_bridge_direct_matches_structured() 8. Test Context Fix (dev_env.rs): - Added thread-local test context depth counter - Fixed deadlock in nested test_ctx() calls via reentrant with_dev_env_if_unset() Structural Axis Growth: P2 family: - Carrier count: 1-3 (unchanged) - NEW: Type diversity (Integer/String mixed) - NEW: Conditional branching patterns (Eq-heavy comparisons) P3 family: - NEW: Carrier count upper bound: 2-10 (was 2-4) - NEW: Multi-branch if-else (5+ branches with nested structure) - NEW: Complex conditional patterns Test Results: - normalized_dev: 40/40 PASS (including 2 new tests) - lib regression: 939 PASS, 56 ignored - Existing behavior unchanged (normalized_dev feature-gated) Phase 53 Achievements: ✅ P2/P3 each gained 1 practical variation (2 total) ✅ Two-stage detection: structural primary + dev-only name guard ✅ Structural axis expanded: 4 axes (carrier count/type/Compare/branch patterns) ✅ All tests PASS, no regressions ✅ Test context deadlock fixed (0.04s for 29 tests) Files Modified: 14 files Lines Added: ~516 lines (net) Implementation: Pure additive (feature-gated) Next Phase (54+): - Accumulate 6+ loops per P2/P3 family - Achieve 5+ stable structural axes - Target < 5% false positive rate - Then shrink/remove name guard scope
2025-12-12 16:40:20 +09:00
- **Phase 48-A実装（minimal dev-only）完了✅** / **Phase 48-B dev（JsonParser skip_ws continue）完了✅**:
- P4 minimal フィクスチャ追加（skip i==2 パターン、単一 carrier `acc`）＋ JsonParser continue skip_ws (array/object) フィクスチャを追加
- ShapeGuard: Pattern4ContinueMinimal + JsonParser continue 形状を検出
feat(joinir): Phase 48-A - P4 (continue) Normalized minimal implementation Pattern4 (continue) integration into Normalized JoinIR pipeline complete. Key changes: - P4 minimal fixture: skip i==2 pattern, single carrier (acc) - ShapeGuard: Pattern4ContinueMinimal detector (structure-based) - StepScheduleBox: ContinueCheck step (eval order: HeaderCond → ContinueCheck → Updates → Tail) - normalize_pattern4_continue_minimal(): Delegates to P2 (95% infrastructure reuse) - Tests: 4 integration tests (normalization/runner/VM Bridge comparison×2) Design validation: - P4 (continue) = reverse control flow of P2 (break) - Same loop_step(env, k_exit) skeleton - Same EnvLayout/ConditionEnv/CarrierInfo infrastructure - Only difference: evaluation order and control flow direction Architecture proof: - Normalized JoinIR successfully handles P1/P2/P3/P4 uniformly - Infrastructure reuse rate: 95%+ as designed Tests: 939/939 PASS (+1 from baseline 938, target exceeded!) Files modified: 10 files (~305 lines added, pure additive) - pattern4_continue_min.program.json (NEW +126 lines) - P4 fixture - fixtures.rs (+31 lines) - P4 fixture loader - shape_guard.rs (+60 lines) - Shape detection - step_schedule.rs (+18 lines) - Schedule + test - normalized.rs (+35 lines) - Normalization function - loop_with_break_minimal.rs (+4 lines) - ContinueCheck handler - bridge.rs (+5 lines) - VM bridge routing - ast_lowerer/mod.rs (+2 lines) - Function registration - normalized_joinir_min.rs (+84 lines) - Integration tests - CURRENT_TASK.md (+13 lines) - Phase 48-A completion Next steps: - Phase 48-B: Extended P4 (multi-carrier, complex continue) - Phase 48-C: Canonical promotion (always use Normalized for P4)
2025-12-12 06:31:13 +09:00
- StepScheduleBox: ContinueCheck step 追加（評価順序: HeaderCond → ContinueCheck → Updates → Tail）
feat(joinir): Phase 53 - SELFHOST-NORM-DEV-EXPAND implementation Expanded selfhost dev Normalized target with 2 practical P2/P3 loop variations, strengthened structural signature axis, and implemented two-stage detection. Key Changes: 1. Documentation (phase49-selfhost-joinir-depth2-design.md +128 lines): - Added Phase 53 section with candidate selection rationale - Documented two-stage detector strategy (structural primary + dev-only name guard) - Defined structural axis strengthening (carrier count/type, branch patterns) 2. Fixtures (+210 lines): - selfhost_args_parse_p2.program.json (60 lines): P2 with String carrier + conditional branching - selfhost_stmt_count_p3.program.json (150 lines): P3 with 5 carriers + multi-branch if-else 3. Structured Builders (fixtures.rs +48 lines): - build_selfhost_args_parse_p2_structured_for_normalized_dev() - build_selfhost_stmt_count_p3_structured_for_normalized_dev() 4. ShapeGuard Two-Stage Detection (shape_guard.rs +80 lines): - Added SelfhostArgsParseP2/SelfhostStmtCountP3 to NormalizedDevShape enum - Implemented is_selfhost_args_parse_p2(): P2 core family + name guard - Implemented is_selfhost_stmt_count_p3(): 2-10 carrier check + name guard - Updated capability_for_shape() mappings 5. Bridge Integration (bridge.rs +8 lines, normalized.rs +10 lines): - Added shape handlers delegating to existing normalizers - Added roundtrip reconstruction handlers 6. Entry Point Registration (ast_lowerer/mod.rs +2 lines): - Registered selfhost_args_parse_p2/selfhost_stmt_count_p3 as LoopFrontend routes 7. Dev VM Comparison Tests (normalized_joinir_min.rs +40 lines): - normalized_selfhost_args_parse_p2_vm_bridge_direct_matches_structured() - normalized_selfhost_stmt_count_p3_vm_bridge_direct_matches_structured() 8. Test Context Fix (dev_env.rs): - Added thread-local test context depth counter - Fixed deadlock in nested test_ctx() calls via reentrant with_dev_env_if_unset() Structural Axis Growth: P2 family: - Carrier count: 1-3 (unchanged) - NEW: Type diversity (Integer/String mixed) - NEW: Conditional branching patterns (Eq-heavy comparisons) P3 family: - NEW: Carrier count upper bound: 2-10 (was 2-4) - NEW: Multi-branch if-else (5+ branches with nested structure) - NEW: Complex conditional patterns Test Results: - normalized_dev: 40/40 PASS (including 2 new tests) - lib regression: 939 PASS, 56 ignored - Existing behavior unchanged (normalized_dev feature-gated) Phase 53 Achievements: ✅ P2/P3 each gained 1 practical variation (2 total) ✅ Two-stage detection: structural primary + dev-only name guard ✅ Structural axis expanded: 4 axes (carrier count/type/Compare/branch patterns) ✅ All tests PASS, no regressions ✅ Test context deadlock fixed (0.04s for 29 tests) Files Modified: 14 files Lines Added: ~516 lines (net) Implementation: Pure additive (feature-gated) Next Phase (54+): - Accumulate 6+ loops per P2/P3 family - Achieve 5+ stable structural axes - Target < 5% false positive rate - Then shrink/remove name guard scope
2025-12-12 16:40:20 +09:00
- normalize_pattern4_continue_minimal()/jsonparser_*continue* を dev 正規化に配線（P2 インフラを再利用）
- テスト完備: minimal + JsonParser continue の VM bridge 比較を normalized_dev スイートで固定
- **Phase 48-C（canonical 昇格）完了✅**:
- P4 minimal + JsonParser skip_ws array/object を canonical set に追加（env OFF でも Normalized→MIR(direct) を強制）
- Bridge/runner で Structured fallback を禁止、fail-fast 契約に統一
- canonical ルートと Structured 直経路の stdout 一致を比較するテストを追加
docs(joinir): Phase 47 - Normalized P3 (If-Sum) design Complete design for extending Normalized JoinIR to Pattern3 (if-sum) loops, reusing 90% of existing P2 infrastructure. Key insight: P3 already uses P2's Structured JoinIR foundation (Phase 220 ConditionEnv integration), so Normalized extension is straightforward. Design documents: - phase47-norm-p3-design.md: Complete P3 Normalized design - Infrastructure reuse analysis (ConditionEnv, CarrierInfo, ExitLine) - Representative loops identified (phase212_if_sum_min primary target) - StepScheduleBox extension (IfCond, ThenUpdates, ElseUpdates) - JpInst reuse (If instruction already exists) - Implementation strategy (dev-only → canonical) - File impact estimate (~365 lines, pure additive) - phase47-test-files-inventory.md: P3 test file catalog - 3 P3 test files analyzed - phase212_if_sum_min.hako: Single carrier (PRIMARY) - phase217_if_sum_multi_min.hako: Multi-carrier (sum + count) - phase218_json_if_sum_min.hako: Variable accumulation (sum + i) Architecture: - Unified Normalized for P1/P2/P3 (same pipeline) - Conditional updates only difference vs P2 - No P2 code changes needed (pure additive) Benefits: - 90% infrastructure reuse from P2 - Proven incremental rollout (dev → canonical) - Clear path to P4 (continue pattern) Implementation roadmap: - Phase 47-A: Minimal sum_count (dev-only) - Phase 47-B: array_filter (body-local + method calls) - Phase 47-C: Canonical promotion Updates: - joinir-architecture-overview.md: Added Phase 47 section - CURRENT_TASK.md: Updated Phase 47 entry (Design Complete) Status: Design phase complete, ready for implementation
2025-12-12 04:50:26 +09:00
5. JsonParser 残りループへの JoinIR 展開
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
- `_parse_array` / `_parse_object` / `_unescape_string` / 本体 `_parse_string` など。
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
- 既存の P2/P3/P4＋P5 パイプラインをどこまで延ばせるかを docs 側で設計 → コード側はその設計に沿って小さく実装。
feat(joinir): Phase 53 - SELFHOST-NORM-DEV-EXPAND implementation Expanded selfhost dev Normalized target with 2 practical P2/P3 loop variations, strengthened structural signature axis, and implemented two-stage detection. Key Changes: 1. Documentation (phase49-selfhost-joinir-depth2-design.md +128 lines): - Added Phase 53 section with candidate selection rationale - Documented two-stage detector strategy (structural primary + dev-only name guard) - Defined structural axis strengthening (carrier count/type, branch patterns) 2. Fixtures (+210 lines): - selfhost_args_parse_p2.program.json (60 lines): P2 with String carrier + conditional branching - selfhost_stmt_count_p3.program.json (150 lines): P3 with 5 carriers + multi-branch if-else 3. Structured Builders (fixtures.rs +48 lines): - build_selfhost_args_parse_p2_structured_for_normalized_dev() - build_selfhost_stmt_count_p3_structured_for_normalized_dev() 4. ShapeGuard Two-Stage Detection (shape_guard.rs +80 lines): - Added SelfhostArgsParseP2/SelfhostStmtCountP3 to NormalizedDevShape enum - Implemented is_selfhost_args_parse_p2(): P2 core family + name guard - Implemented is_selfhost_stmt_count_p3(): 2-10 carrier check + name guard - Updated capability_for_shape() mappings 5. Bridge Integration (bridge.rs +8 lines, normalized.rs +10 lines): - Added shape handlers delegating to existing normalizers - Added roundtrip reconstruction handlers 6. Entry Point Registration (ast_lowerer/mod.rs +2 lines): - Registered selfhost_args_parse_p2/selfhost_stmt_count_p3 as LoopFrontend routes 7. Dev VM Comparison Tests (normalized_joinir_min.rs +40 lines): - normalized_selfhost_args_parse_p2_vm_bridge_direct_matches_structured() - normalized_selfhost_stmt_count_p3_vm_bridge_direct_matches_structured() 8. Test Context Fix (dev_env.rs): - Added thread-local test context depth counter - Fixed deadlock in nested test_ctx() calls via reentrant with_dev_env_if_unset() Structural Axis Growth: P2 family: - Carrier count: 1-3 (unchanged) - NEW: Type diversity (Integer/String mixed) - NEW: Conditional branching patterns (Eq-heavy comparisons) P3 family: - NEW: Carrier count upper bound: 2-10 (was 2-4) - NEW: Multi-branch if-else (5+ branches with nested structure) - NEW: Complex conditional patterns Test Results: - normalized_dev: 40/40 PASS (including 2 new tests) - lib regression: 939 PASS, 56 ignored - Existing behavior unchanged (normalized_dev feature-gated) Phase 53 Achievements: ✅ P2/P3 each gained 1 practical variation (2 total) ✅ Two-stage detection: structural primary + dev-only name guard ✅ Structural axis expanded: 4 axes (carrier count/type/Compare/branch patterns) ✅ All tests PASS, no regressions ✅ Test context deadlock fixed (0.04s for 29 tests) Files Modified: 14 files Lines Added: ~516 lines (net) Implementation: Pure additive (feature-gated) Next Phase (54+): - Accumulate 6+ loops per P2/P3 family - Achieve 5+ stable structural axes - Target < 5% false positive rate - Then shrink/remove name guard scope
2025-12-12 16:40:20 +09:00
6. **Phase 49-SELFHOST-NORM-DEPTH2（設計・コードなし）**: selfhost depth2 Normalized 設計フェーズ
- 設計詳細: [phase49-selfhost-joinir-depth2-design.md](docs/development/current/main/phase49-selfhost-joinir-depth2-design.md)
7. **Phase 50-SELFHOST-NORM-DEV（dev-only）完了✅ 2025-12-12**: selfhost 軽量 P2/P3 を dev Normalized パイプラインに載せる足慣らし
- 対象: `selfhost_token_scan_p2` / `selfhost_if_sum_p3`
- fixtures / ShapeGuard(Selfhost* 系) / VM bridge 比較テストまで整備し、Structured 直経路と一致を固定。
8. **Phase 51-SELFHOST-NORM-DEV-EXTEND（dev-only）完了✅ 2025-12-12**: selfhost 実戦寄り P2/P3 を dev Normalized に追加
- 対象: `selfhost_token_scan_p2_accum` / `selfhost_if_sum_p3_ext`
- Phase 50 と同導線で fixtures / shape / 比較テストを追加し、selfhost 断面で緑を維持。
9. **Phase 52-SELFHOST-SHAPE-STRUCT-SIGNATURE（dev-only）完了✅ 2025-12-12**: selfhost shape の構造シグネチャ育成
- selfhost P2/P3 を「構造一次判定→dev-only name ガード最終確定」の二段 detector に移行。
- 構造シグネチャの安定テストを追加し、name ガード撤去の足場を SSOT に固定。
10. **Phase 53-SELFHOST-NORM-DEV-EXPAND（dev-only）完了✅ 2025-12-12**: selfhost P2/P3 の実戦寄り形状を追加
- 対象追加: P2 `args_parse_p2` / P3 `stmt_count_p3`
- 構造一次判定（carrier 数/型/Compare/branch）→ dev-only name 最終確定の二段 detector を拡張。
- P3 carrier 上限を 2–10 に拡大し、複雑 if-else 形状を selfhost 群として取り込んだ。
- `normalized_dev` selfhost 断面/回帰テストが緑、既定挙動は不変。
feat(joinir): Phase 54 SELFHOST-SHAPE-GROWTH - 構造軸育成 + 偽陽性観測 Phase 53 成果を踏まえ、構造シグネチャ軸を 5+ に育て、 偽陽性観測テストで name ガード縮小準備を整えた。 方針変更: 新ループ追加 → 構造軸育成 + 偽陽性率測定に焦点変更 - 理由: Phase 53 で selfhost P2/P3 実戦パターン追加済み - 焦点: 既存ループに対する構造軸拡張 + 精度測定 主な成果: 1. 構造軸 5+ 達成: - carrier 数 - carrier 型 - Compare パターン - branch 構造 - NEW: Compare op 分布 (count_compare_ops ヘルパー) 2. 偽陽性観測テスト追加: - test_phase54_structural_axis_discrimination_p2() - test_phase54_structural_axis_discrimination_p3() 3. 重要な発見 - 偽陽性率 ~50%: - P2: selfhost P2 が正しく検出されず (name ガード依存) - P3: selfhost P3 が Pattern4ContinueMinimal と誤検出 (構造的類似性) - 結論: 構造判定のみでは分離不十分、name ガード必須と判明 変更内容: - shape_guard.rs (+80 lines): - count_compare_ops() 構造軸ヘルパー追加 - detect_shapes() pub 化 (テストから呼び出し可能に) - SelfhostVerifySchemaP2/SelfhostDetectFormatP3 enum 追加 (将来用) - normalized_joinir_min.rs (+110 lines): - 偽陽性観測テスト 2 個追加 (P2/P3 各1) - canonical shapes vs selfhost shapes 構造判定精度測定 - phase49 doc (+200 lines): - Phase 54 節完成版 - 偽陽性分析結果記録 - name ガード縮小方針明記 - enum 拡張対応: - bridge.rs (+8 lines) - normalized.rs (+8 lines) - ast_lowerer/mod.rs (+2 lines) 偽陽性観測結果 (2025-12-12): - P2 構造判定: selfhost P2 検出失敗 → name ガード必須 - P3 構造判定: selfhost P3 が Pattern4 と誤判定 → 構造的類似性問題 - 総合: 偽陽性率 ~50% → 構造軸 5 本では不十分 次フェーズ方針 (Phase 55+): - Phase 55-A: 条件複雑度軸追加 (BinOp/UnaryOp ネスト深度) - Phase 55-B: 算術パターン軸追加 (Mul/Sub/Div 出現パターン) - Phase 56: selfhost 実戦ループ追加 (6 本以上蓄積) - Phase 57: 誤判定率 < 5% 達成後に name ガード縮小開始 name ガード撤去条件 (Phase 57): - 構造軸 8+ 本確立 - selfhost P2/P3 各 6 本以上蓄積 - 誤判定率 < 5% 達成 - 複合的特徴量ベース判定実装 回帰テスト: ✅ 939 PASS, 0 FAIL (既存挙動不変) Files Modified: 8 files Lines Added: ~408 lines (net) Implementation: Pure additive (feature-gated) Phase 54 完了！構造軸育成・偽陽性観測基盤確立！
2025-12-12 17:12:58 +09:00
11. **Phase 54-SELFHOST-SHAPE-GROWTH（dev-only）完了✅ 2025-12-12**: 構造軸の育成と偽陽性観測フェーズ
- Phase 53 で実戦ループ追加済みのため、追加投入より先に構造判定精度の測定に集中。
- 構造シグネチャ軸を 5+ に拡張（Compare op 分布など）し、P2/P3 の偽陽性観測テストを追加。
- 結果: selfhost 群の構造判定だけでは分離が不十分（偽陽性率 ~50%）。dev-only name ガードは当面必須と判断。
docs(joinir): Phase 56 - Ownership-Relay Design + interface skeleton 「読むのは自由、管理は直下 owned だけ」アーキテクチャの設計文書と型定義。 Key changes: - Design doc: phase56-ownership-relay-design.md - Core definitions: owned/carriers/captures/relay - Invariants: Ownership Uniqueness, Carrier Locality, Relay Propagation - Shadowing rules, multi-writer merge semantics - JoinIR mapping from current system to new system - Implementation phases roadmap (56-61) - New module: src/mir/join_ir/ownership/ - types.rs: ScopeId, ScopeOwnedVar, RelayVar, CapturedVar, OwnershipPlan - mod.rs: Module documentation with responsibility boundaries - README.md: Usage guide and examples - API methods: - OwnershipPlan::carriers() - owned AND written variables - OwnershipPlan::condition_only_carriers() - condition-only carriers - OwnershipPlan::verify_invariants() - invariant checking Tests: 942/942 PASS (+3 unit tests) Zero behavioral change - analysis module skeleton only. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 17:39:59 +09:00
12. **Phase 55-SELFHOST-SHAPE-AXIS-EXPAND（dev-only / 保留）**: 構造軸を可変 feature として拡張し誤判定を下げる足場
- Phase 56–61 の Ownership-Relay ライン優先のため、selfhost shape 軸拡張は一旦保留。
- OwnershipAnalyzer 導入後に、scope 署名（owned/carriers/captures/relay）を新しい構造軸として合流させる。
13. **Phase 56-OWNERSHIP-RELAY-DESIGN（完了✅ 2025-12-12）**: Ownership-Relay アーキテクチャ設計 + インターフェース skeleton
- 設計詳細: [phase56-ownership-relay-design.md](docs/development/current/main/phase56-ownership-relay-design.md)
- コア定義: owned / carriers / captures / relay の 4 分類を明確化
- 不変条件: Ownership Uniqueness / Carrier Locality / Relay Propagation / Capture Read-Only
- Module 作成: `src/mir/join_ir/ownership/` - 責務は「解析のみ」
- 型定義: `ScopeId`, `ScopeOwnedVar`, `RelayVar`, `CapturedVar`, `OwnershipPlan`
- テスト: 3 つのユニットテスト追加（empty plan / carriers filter / invariant verification）
- 次: Phase 57 で OwnershipAnalyzer 実装（dev-only）
feat(joinir): Phase 59 - Ownership P3 plumbing (dev-only) P3 (if-sum) パターン用の OwnershipPlan → lowering inputs 変換を追加。 Key changes: - plan_to_lowering.rs (+153 lines): - P3LoweringInputs struct (same structure as P2) - plan_to_p3_inputs() converter - 4 unit tests (multi-carrier, 5+, condition-only, relay-rejected) P3 specific features: - Multi-carrier support (sum, count, 5+ carriers) - Same Fail-Fast on relay_writes (Phase 59 scope) - Same CarrierRole discrimination (LoopState vs ConditionOnly) Integration tests: - test_phase59_ownership_p3_relay_failfast: Verifies relay detection - test_phase59_ownership_p3_loop_local_success: Verifies loop-local success Design: Perfect parallelism with P2 - Same struct layout (carriers, captures, condition_captures) - Same conversion logic (skip loop var, filter written vars) - Same error handling (Fail-Fast on relay) Tests: 946/946 PASS (16 ownership tests) All code under #[cfg(feature = "normalized_dev")] - zero impact on canonical. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 18:45:08 +09:00
14. **Phase 57-OWNERSHIP-ANALYZER-DEV（完了✅ 2025-12-12）**: OwnershipPlan を生成する解析箱の実装
docs(joinir): Phase 56 - Ownership-Relay Design + interface skeleton 「読むのは自由、管理は直下 owned だけ」アーキテクチャの設計文書と型定義。 Key changes: - Design doc: phase56-ownership-relay-design.md - Core definitions: owned/carriers/captures/relay - Invariants: Ownership Uniqueness, Carrier Locality, Relay Propagation - Shadowing rules, multi-writer merge semantics - JoinIR mapping from current system to new system - Implementation phases roadmap (56-61) - New module: src/mir/join_ir/ownership/ - types.rs: ScopeId, ScopeOwnedVar, RelayVar, CapturedVar, OwnershipPlan - mod.rs: Module documentation with responsibility boundaries - README.md: Usage guide and examples - API methods: - OwnershipPlan::carriers() - owned AND written variables - OwnershipPlan::condition_only_carriers() - condition-only carriers - OwnershipPlan::verify_invariants() - invariant checking Tests: 942/942 PASS (+3 unit tests) Zero behavioral change - analysis module skeleton only. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 17:39:59 +09:00
- `OwnershipAnalyzer` を追加し、ネスト含む reads/writes/owned を集計→ carriers/relay/captures を plan 化。
- 既存 fixtures（pattern2/3, jsonparser, selfhost）で plan の回帰テストを追加。
Phase 61: structural if-sum+break lowering (dev-only)
2025-12-12 22:15:41 +09:00
- 設計詳細: [PHASE_57_SUMMARY.md](docs/development/current/main/PHASE_57_SUMMARY.md)
feat(joinir): Phase 59 - Ownership P3 plumbing (dev-only) P3 (if-sum) パターン用の OwnershipPlan → lowering inputs 変換を追加。 Key changes: - plan_to_lowering.rs (+153 lines): - P3LoweringInputs struct (same structure as P2) - plan_to_p3_inputs() converter - 4 unit tests (multi-carrier, 5+, condition-only, relay-rejected) P3 specific features: - Multi-carrier support (sum, count, 5+ carriers) - Same Fail-Fast on relay_writes (Phase 59 scope) - Same CarrierRole discrimination (LoopState vs ConditionOnly) Integration tests: - test_phase59_ownership_p3_relay_failfast: Verifies relay detection - test_phase59_ownership_p3_loop_local_success: Verifies loop-local success Design: Perfect parallelism with P2 - Same struct layout (carriers, captures, condition_captures) - Same conversion logic (skip loop var, filter written vars) - Same error handling (Fail-Fast on relay) Tests: 946/946 PASS (16 ownership tests) All code under #[cfg(feature = "normalized_dev")] - zero impact on canonical. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 18:45:08 +09:00
15. **Phase 58-OWNERSHIP-PLUMB-P2-DEV（完了✅ 2025-12-12）**: P2 conversion helper (dev-only)
- `plan_to_p2_inputs()` でOwnershipPlan→P2LoweringInputs変換
- Fail-Fast: relay_writes 未対応（Phase 60で対応予定）
- 5つのユニットテスト + 1つのintegrationテスト
- 設計詳細: [PHASE_58_SUMMARY.md](docs/development/current/main/PHASE_58_SUMMARY.md)
16. **Phase 59-OWNERSHIP-PLUMB-P3-DEV（完了✅ 2025-12-12）**: P3 conversion helper (dev-only)
- `plan_to_p3_inputs()` でOwnershipPlan→P3LoweringInputs変換（P2と同構造）
- Multi-carrier対応（sum, count, 5+ carriers）
- Fail-Fast: relay_writes 未対応（Phase 60で対応予定）
- 4つのユニットテスト + 2つのintegrationテスト
- 設計詳細: [PHASE_59_SUMMARY.md](docs/development/current/main/PHASE_59_SUMMARY.md)
Phase 61: structural if-sum+break lowering (dev-only)
2025-12-12 22:15:41 +09:00
17. **Phase 60-OWNERSHIP-RELAY-IMPL（完了✅ 2025-12-12）**: Relay support for P2/P3 (dev-only)
- `plan_to_p2_inputs_with_relay()` / `plan_to_p3_inputs_with_relay()` を追加（単一hopのみ許可、multi-hopはFail-Fast）
- P2 Break lowering を dev-only で ownership-with-relay に接続し、legacy 経路との VM 出力一致を比較テストで固定。
- shape_guard の selfhost family 分離を最小更新（selfhost shapes 優先時の混線を遮断）。
18. **Phase 61-IFSUM-BREAK-STRUCTURAL（完了✅ 2025-12-12）**: if-sum + break を別箱で構造的に導入（dev-only）
- Break(P2) から P3 固有ロジック（by-name）を撤去し、責務混線を解消。
- 新箱 `if_sum_break_pattern` を追加し、`return Var+Var` を含む if-sum+break を構造判定→Fail-Fast で lowering。
- OwnershipPlan を param order/carriers の SSOT に使い、carriers!=return vars の混線を遮断。
- 詳細: [PHASE_61_SUMMARY.md](docs/development/current/main/PHASE_61_SUMMARY.md)
feat(joinir): Phase 64 - Ownership P3 production integration (dev-only) P3(if-sum) 本番ルートに OwnershipPlan 解析を接続（analysis-only）。 Key changes: - ast_analyzer.rs: Added analyze_loop() helper - Loop-specific analysis API for production integration - build_plan_for_scope() helper for single-scope extraction - pattern3_with_if_phi.rs: P3 production integration - OwnershipPlan analysis after ConditionEnv building - check_ownership_plan_consistency() for validation - Feature-gated #[cfg(feature = "normalized_dev")] Consistency checks: - Fail-Fast: Multi-hop relay (relay_path.len() > 1) - Warn-only: Carrier set mismatch (order SSOT deferred) - Warn-only: Condition captures (some patterns have extras) Tests: 49/49 PASS (2 new Phase 64 tests) - test_phase64_p3_ownership_prod_integration - test_phase64_p3_multihop_relay_detection - Zero regressions Design: Analysis-only, no behavior change - Integration point: After ConditionEnv, before JoinIR lowering - Dev-only validation for future SSOT migration Next: Phase 65+ - Carrier order SSOT, owner-based init 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-12 23:02:40 +09:00
19. **Phase 62-OWNERSHIP-P3-ROUTE-DESIGN（完了✅ 2025-12-12）**: P3 本番ルートへ OwnershipPlan を渡す設計
Phase 61: structural if-sum+break lowering (dev-only)
2025-12-12 22:15:41 +09:00
- MIR→JoinIR の `pattern3_with_if_phi.rs` は OwnershipPlan を受け取らないため、AST-based ownership 解析の接続点を設計する。
- dev-only で段階接続し、legacy と stdout/exit 一致の比較で回帰を固定（既定挙動は不変）。
docs(joinir): Phase 63 - AST ownership analyzer (dev-only) ASTNode → OwnershipPlan の解析器を追加（analysis-only, normalized_dev）。 Key changes: - New ast_analyzer.rs (~370 lines): - AstOwnershipAnalyzer: AST → Vec<OwnershipPlan> - ScopeKind: Function/Loop/If/Block - Invariants: owned_vars/relay_writes/captures/condition_captures Design: - JSON v0 "Local=rebind" を使わず、AST の Statement::Local を正しく扱う - "読むのは自由、管理は直下だけ" アーキテクチャ維持 Tests: 3 unit tests + 47/47 normalized_dev PASS - loop_local_carrier_is_owned_and_written - condition_capture_is_reported_for_loop - relay_write_detected_for_outer_owned_var Next: Phase 64 - P3(if-sum) 本番ルートへ dev-only で接続 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-12 22:51:21 +09:00
- 設計詳細: [phase62-ownership-p3-route-design.md](docs/development/current/main/phase62-ownership-p3-route-design.md)
20. **Phase 63-OWNERSHIP-AST-ANALYZER（完了✅ 2025-12-12）**: 本番 AST から OwnershipPlan を生成（dev-only）
- `AstOwnershipAnalyzer` を追加し、ASTNode から owned/relay/capture を plan 化（analysis-only）。
feat(joinir): Phase 64 - Ownership P3 production integration (dev-only) P3(if-sum) 本番ルートに OwnershipPlan 解析を接続（analysis-only）。 Key changes: - ast_analyzer.rs: Added analyze_loop() helper - Loop-specific analysis API for production integration - build_plan_for_scope() helper for single-scope extraction - pattern3_with_if_phi.rs: P3 production integration - OwnershipPlan analysis after ConditionEnv building - check_ownership_plan_consistency() for validation - Feature-gated #[cfg(feature = "normalized_dev")] Consistency checks: - Fail-Fast: Multi-hop relay (relay_path.len() > 1) - Warn-only: Carrier set mismatch (order SSOT deferred) - Warn-only: Condition captures (some patterns have extras) Tests: 49/49 PASS (2 new Phase 64 tests) - test_phase64_p3_ownership_prod_integration - test_phase64_p3_multihop_relay_detection - Zero regressions Design: Analysis-only, no behavior change - Integration point: After ConditionEnv, before JoinIR lowering - Dev-only validation for future SSOT migration Next: Phase 65+ - Carrier order SSOT, owner-based init 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-12 23:02:40 +09:00
- JSON v0 の "Local=rebind" ハックを排除（fixture 専用のまま）。
docs(joinir): Phase 63 - AST ownership analyzer (dev-only) ASTNode → OwnershipPlan の解析器を追加（analysis-only, normalized_dev）。 Key changes: - New ast_analyzer.rs (~370 lines): - AstOwnershipAnalyzer: AST → Vec<OwnershipPlan> - ScopeKind: Function/Loop/If/Block - Invariants: owned_vars/relay_writes/captures/condition_captures Design: - JSON v0 "Local=rebind" を使わず、AST の Statement::Local を正しく扱う - "読むのは自由、管理は直下だけ" アーキテクチャ維持 Tests: 3 unit tests + 47/47 normalized_dev PASS - loop_local_carrier_is_owned_and_written - condition_capture_is_reported_for_loop - relay_write_detected_for_outer_owned_var Next: Phase 64 - P3(if-sum) 本番ルートへ dev-only で接続 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-12 22:51:21 +09:00
- 詳細: [PHASE_63_SUMMARY.md](docs/development/current/main/PHASE_63_SUMMARY.md)
feat(joinir): Phase 64 - Ownership P3 production integration (dev-only) P3(if-sum) 本番ルートに OwnershipPlan 解析を接続（analysis-only）。 Key changes: - ast_analyzer.rs: Added analyze_loop() helper - Loop-specific analysis API for production integration - build_plan_for_scope() helper for single-scope extraction - pattern3_with_if_phi.rs: P3 production integration - OwnershipPlan analysis after ConditionEnv building - check_ownership_plan_consistency() for validation - Feature-gated #[cfg(feature = "normalized_dev")] Consistency checks: - Fail-Fast: Multi-hop relay (relay_path.len() > 1) - Warn-only: Carrier set mismatch (order SSOT deferred) - Warn-only: Condition captures (some patterns have extras) Tests: 49/49 PASS (2 new Phase 64 tests) - test_phase64_p3_ownership_prod_integration - test_phase64_p3_multihop_relay_detection - Zero regressions Design: Analysis-only, no behavior change - Integration point: After ConditionEnv, before JoinIR lowering - Dev-only validation for future SSOT migration Next: Phase 65+ - Carrier order SSOT, owner-based init 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-12 23:02:40 +09:00
21. **Phase 64-OWNERSHIP-P3-PROD-PLUMB（完了✅ 2025-12-12）**: 本番 P3(if-sum) ルートへ段階接続（dev-only）
- ✅ `analyze_loop()` helper API を追加（`ast_analyzer.rs`）
- ✅ `pattern3_with_if_phi.rs` で OwnershipPlan を導入し、整合チェック実行
- ✅ Fail-Fast: multi-hop relay (`relay_path.len() > 1`)
- ✅ Warn-only: carrier set mismatch（order SSOT は Phase 65+）
- ✅ 回帰テスト追加（`test_phase64_p3_ownership_prod_integration`, `test_phase64_p3_multihop_relay_detection`）
- ✅ テスト結果: 49/49 tests passing, 0 regressions
- 詳細: [PHASE_64_SUMMARY.md](docs/development/current/main/PHASE_64_SUMMARY.md), [phase64-implementation-report.md](docs/development/current/main/phase64-implementation-report.md)
docs(current): Phase 65 - Refactoring audit completed
2025-12-12 23:12:11 +09:00
22. **Phase 65-REFACTORING-AUDIT（完了✅ 2025-12-12）**: コード品質監査 + スタブドキュメント化
- ✅ Explore agent による包括的リファクタリング監査（10 opportunities identified）
- ✅ [REFACTORING_OPPORTUNITIES.md](docs/development/current/main/REFACTORING_OPPORTUNITIES.md) ドキュメント作成
- ✅ BID-codegen stubs へ deprecation notice + 代替パス文書化
- ✅ quick wins (< 2時間) 実装可能な内容をドキュメント化
- 詳細: [REFACTORING_OPPORTUNITIES.md](docs/development/current/main/REFACTORING_OPPORTUNITIES.md)
docs(joinir): Phase 65 - Ownership-Relay Multihop Design (設計のみ) Multihop relay（複数階層を跨ぐrelay）の完全な設計文書を作成。 Phase 66実装の土台となる意味論と不変条件を確立。 Key design decisions: - Multihop relay 意味論: relay_path（内→外の順）、段階的carrier化 - Merge relay 意味論: PERMIT with owner merge（複数inner loopが同一祖先owned変数を更新） - Fail-Fast 解除条件: Phase 66実装時の受け入れ基準を明文化 - 実装箇所の特定: Analyzer変更不要、plan_to_lowering/Pattern lowering変更点を箇条書き - 禁止事項: by-name分岐排除、dev-only name guard対象外 Design principles: - 「読むのは自由、管理は直下だけ」を維持 - 各中間ループは「素通し」のみ（merge責務はownerのみ） - Owner scopeのexit PHIで全分岐をmerge - 構造ベース設計（変数名による特別扱いなし） Representative cases: - 3階層multihop（AST例 + OwnershipPlan例） - Merge relay（JSON fixture例 + 期待されるOwnershipPlan） Phase 66への引き継ぎ: - この文書の「5. 実装箇所の特定」をガイドとして使用 - Fail-Fast段階解除の流れに従って実装 - 回帰テスト（既存Phase 64テスト全PASS）を確認しながら進める Status: 設計完了、実装はPhase 66以降 Tests: N/A (設計文書のみ) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-12 23:16:32 +09:00
23. **Phase 65-OWNERSHIP-RELAY-MULTIHOP-DESIGN（完了✅ 2025-12-12）**: Multihop relay 設計（実装はPhase 66以降）
- ✅ Multihop relay 意味論の定義（relay_path: 内→外の順、段階的carrier化）
- ✅ Merge relay 意味論の定義（PERMIT with owner merge、複数inner loopが同一祖先owned変数を更新）
- ✅ Fail-Fast 解除条件の明文化（Phase 66実装時の受け入れ基準）
- ✅ 実装箇所の特定（Analyzer変更不要、plan_to_lowering/Pattern lowering変更点）
- ✅ 禁止事項の明文化（by-name分岐排除、dev-only name guard対象外）
- ✅ 代表ケース（3階層multihop AST例、Merge relay JSON fixture例）
- 詳細: [phase65-ownership-relay-multihop-design.md](docs/development/current/main/phase65-ownership-relay-multihop-design.md)
feat(joinir): Phase 66 - Ownership-Relay Multihop Implementation (dev-only) Phase 65設計に基づき、relay_path.len() > 1 を analysis/plan 層で受理するよう実装。 Key changes: - plan_to_lowering.rs: relay_path.len() > 1 制限撤去 + 構造的 Fail-Fast 維持 - relay_path.is_empty() → Err（loop relay は最低 1 hop） - relay_path[0] != plan.scope_id → Err（この scope が最初の hop） - relay.owner_scope == plan.scope_id → Err（relay と owned は排他） - owned_vars ∩ relay_writes ≠ ∅ → Err（同名は不変条件違反） - ast_analyzer.rs: 3階層 multihop テスト追加 - multihop_relay_detected_for_3_layer_nested_loops Unit tests (plan_to_lowering): - test_relay_multi_hop_accepted_in_with_relay - test_relay_path_empty_rejected_in_with_relay - test_relay_path_not_starting_at_plan_scope_rejected - test_relay_owner_same_as_plan_scope_rejected - test_owned_and_relay_same_name_rejected Tests: normalized_dev 49/49 PASS, lib 947/947 PASS Design: Analysis-only, no behavior change in production lowering 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 23:33:16 +09:00
24. **Phase 66-OWNERSHIP-RELAY-MULTIHOP-IMPL（完了✅ 2025-12-12）**: Multihop relay 実装（analysis/plan層）
- ✅ `plan_to_lowering.rs` の relay_path.len() > 1 制限撤去
- ✅ 構造的 Fail-Fast ガード実装（empty path, scope mismatch, owner=scope, name conflict）
- ✅ ユニットテスト追加（5件: multihop accepted, empty rejected, path mismatch, owner same, name conflict）
- ✅ `ast_analyzer.rs` に 3階層 multihop テスト追加
- ✅ テスト結果: normalized_dev 49/49, lib 947/947 PASS
obs(joinir): Phase 72 - PHI Reserved Region Observation Complete ## Summary Observed PHI dst ValueId distribution to determine if verifier can enforce reserved region (0-99). **Conclusion: Verifier strengthening NOT recommended.** ## Key Finding PHI dst allocation does NOT architecturally respect reserved region: - PHI dst comes from `builder.next_value_id()` (host MirBuilder) - Reserved region (0-99) is a JoinValueSpace contract for JoinIR lowering - These are separate allocation pools with no enforcement mechanism - Current stability is accidental (ValueId allocation ordering) ## Evidence Manual verification (`apps/tests/loop_min_while.hako`): - PHI dst = %3 (ValueId(3)) ✅ in reserved region - Works because PHI allocated early in function (0-20 typical) - JoinValueSpace allocates high (100+, 1000+) - Accidental separation, not enforced ## Implementation Added observation infrastructure (debug-only): - `src/mir/join_ir/verify_phi_reserved.rs` (266 lines) - PHI dst observer with distribution analyzer - Region classifier (Reserved/Param/Local) - Human-readable report generator - Instrumentation at PHI allocation points: - loop_header_phi_builder.rs:94, 151 - Debug-only `observe_phi_dst()` calls ## Test Results - Unit tests: ✅ 4/4 PASS (verify_phi_reserved module) - Lib tests: ✅ 950/950 PASS, 56 ignored - Normalized tests: ✅ 54/54 PASS - Manual verification: ✅ PHI dst in 0-99 observed ## Decision: Document, Don't Enforce **Rationale**: 1. No architectural mechanism to enforce PHI dst ∈ [0, 99] 2. Adding verifier creates false assumptions about allocation order 3. Current system stable through separate pools (950/950 tests) 4. Future architectural fix possible (Phase 73+) but not urgent ## Documentation - PHASE_72_SUMMARY.md: Executive summary and implementation record - phase72-phi-reserved-observation.md: Detailed findings and analysis - CURRENT_TASK.md: Phase 72 completion entry ## Next Steps - Phase 73: Update architecture overview with Phase 72 findings - Optional: Explicit PHI reserved pool (future enhancement) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-13 03:23:02 +09:00
- 次フェーズ: Phase 70-B+（merge relay / 本番multihop 実行対応）
feat(joinir): Phase 66 - Ownership-Relay Multihop Implementation (dev-only) Phase 65設計に基づき、relay_path.len() > 1 を analysis/plan 層で受理するよう実装。 Key changes: - plan_to_lowering.rs: relay_path.len() > 1 制限撤去 + 構造的 Fail-Fast 維持 - relay_path.is_empty() → Err（loop relay は最低 1 hop） - relay_path[0] != plan.scope_id → Err（この scope が最初の hop） - relay.owner_scope == plan.scope_id → Err（relay と owned は排他） - owned_vars ∩ relay_writes ≠ ∅ → Err（同名は不変条件違反） - ast_analyzer.rs: 3階層 multihop テスト追加 - multihop_relay_detected_for_3_layer_nested_loops Unit tests (plan_to_lowering): - test_relay_multi_hop_accepted_in_with_relay - test_relay_path_empty_rejected_in_with_relay - test_relay_path_not_starting_at_plan_scope_rejected - test_relay_owner_same_as_plan_scope_rejected - test_owned_and_relay_same_name_rejected Tests: normalized_dev 49/49 PASS, lib 947/947 PASS Design: Analysis-only, no behavior change in production lowering 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 23:33:16 +09:00
- 詳細: [phase65-ownership-relay-multihop-design.md](docs/development/current/main/phase65-ownership-relay-multihop-design.md)
docs(joinir): Phase 70-A - Relay Runtime Guard (dev-only) Phase 66で analysis/plan層はmultihop受理可能になったが、runtime lowering (実行導線)はまだ未対応。このPhaseでは「未対応は同じタグで必ず落ちる」を docs + テストで固定する。 Key changes: - phase70-relay-runtime-guard.md: Runtime guard設計doc新規追加 - 現状(plan OK / runtime NG)の明確化 - Fail-Fastタグ [ownership/relay:runtime_unsupported] の標準化 - Phase 70-B以降の解除条件 - pattern3_with_if_phi.rs: エラーメッセージのタグ統一 - [ownership/relay:runtime_unsupported] 形式に変更 - var/owner_scope/relay_path の診断情報追加 - normalized_joinir_min.rs: 固定テスト追加 - test_phase70a_multihop_relay_runtime_unsupported_tag - Plan層のmultihop受理確認 + runtime拒否の文書化 Tests: normalized_dev 50/50 PASS (+1), lib 950/950 PASS 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-13 02:22:29 +09:00
25. **Phase 67-MIR-VAR-IDENTITY-SURVEY（完了✅ 2025-12-13）**: MIR の束縛モデルを観測して SSOT 化
- 現状: `variable_map(name→ValueId)` 1枚でブロックスコープ/シャドウイング無し、未宣言代入の挙動が doc と不一致。
- プローブ（vm smokes）を追加して観測可能化し、Phase 68 の修正方針（MIR 側で lexical scope を実装）を決定。
- 詳細: [phase67-mir-var-identity-survey.md](docs/development/current/main/phase67-mir-var-identity-survey.md)
26. **Phase 68-MIR-LEXICAL-SCOPE（完了✅ 2025-12-13）**: MIR ビルダーに lexical scope を導入し、仕様に整合
- `{...}`（Program）/ `ScopeBox` を lexical scope として扱い、`local` の shadowing を正しく復元。
- “未宣言名への代入はエラー” を SSOT（quick-reference/LANGUAGE_REFERENCE）に揃えて Fail-Fast 化。
- free-vars 解析も lexical scope に追随（AST walker 重複の整理を含む）。
- 実装コミット: `1fae4f16`, `0913ee8b`
27. **Phase 69-OWNERSHIP-AST-SHADOWING（完了✅ 2025-12-13）**: AST ownership 解析を shadowing-aware にする（dev-only）
- `AstOwnershipAnalyzer` を内部 `BindingId` で分離し、ネスト block の local が loop carriers/relay に混ざらないように修正。
- 代表テストで固定（shadowing あり/なし、outer update の relay_write、ネスト block local の非混入）。
- 実装コミット: `795d68ec`
obs(joinir): Phase 72 - PHI Reserved Region Observation Complete ## Summary Observed PHI dst ValueId distribution to determine if verifier can enforce reserved region (0-99). **Conclusion: Verifier strengthening NOT recommended.** ## Key Finding PHI dst allocation does NOT architecturally respect reserved region: - PHI dst comes from `builder.next_value_id()` (host MirBuilder) - Reserved region (0-99) is a JoinValueSpace contract for JoinIR lowering - These are separate allocation pools with no enforcement mechanism - Current stability is accidental (ValueId allocation ordering) ## Evidence Manual verification (`apps/tests/loop_min_while.hako`): - PHI dst = %3 (ValueId(3)) ✅ in reserved region - Works because PHI allocated early in function (0-20 typical) - JoinValueSpace allocates high (100+, 1000+) - Accidental separation, not enforced ## Implementation Added observation infrastructure (debug-only): - `src/mir/join_ir/verify_phi_reserved.rs` (266 lines) - PHI dst observer with distribution analyzer - Region classifier (Reserved/Param/Local) - Human-readable report generator - Instrumentation at PHI allocation points: - loop_header_phi_builder.rs:94, 151 - Debug-only `observe_phi_dst()` calls ## Test Results - Unit tests: ✅ 4/4 PASS (verify_phi_reserved module) - Lib tests: ✅ 950/950 PASS, 56 ignored - Normalized tests: ✅ 54/54 PASS - Manual verification: ✅ PHI dst in 0-99 observed ## Decision: Document, Don't Enforce **Rationale**: 1. No architectural mechanism to enforce PHI dst ∈ [0, 99] 2. Adding verifier creates false assumptions about allocation order 3. Current system stable through separate pools (950/950 tests) 4. Future architectural fix possible (Phase 73+) but not urgent ## Documentation - PHASE_72_SUMMARY.md: Executive summary and implementation record - phase72-phi-reserved-observation.md: Detailed findings and analysis - CURRENT_TASK.md: Phase 72 completion entry ## Next Steps - Phase 73: Update architecture overview with Phase 72 findings - Optional: Explicit PHI reserved pool (future enhancement) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-13 03:23:02 +09:00
28. **Phase 70-A-RELAY-RUNTIME-GUARD（完了✅ 2025-12-13）**: “plan OK / runtime NG” をタグで固定（dev-only）
- `[ownership/relay:runtime_unsupported]` を標準タグとして文書化し、P3 runtime 経路のエラーを統一。
- 回帰テストで “タグを含む Err” を固定し、段階解除（Phase 70-B+）の足場にする。
- 詳細: [phase70-relay-runtime-guard.md](docs/development/current/main/phase70-relay-runtime-guard.md)
- 実装コミット: `7b56a7c0`
29. **Phase 71-Pre-OWNERSHIP-PLAN-VALIDATOR（完了✅ 2025-12-13）**: OwnershipPlanValidator 箱を導入（dev-only）
- OwnershipPlan の整合チェックを箱に隔離し、P3 本番導線のガードを再利用可能にする。
- 実装コミット: `1424aac9`
docs(roadmap): Update CURRENT_TASK.md with Phase 70-B/C/72/73 Add entries for completed phases: - Phase 70-B: Multihop passthrough support (c2df1cac) - Phase 70-C: Merge relay detection (24cc948f) - Phase 72: PHI reserved observation (253eb59b) - Phase 73: ScopeManager BindingId design + PoC (851bf4f8) Add next roadmap: - Phase 74-77: BindingId Migration (8-12 hours, 4 phases) - All phases with links to SSOT docs - Estimated effort per phase 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-13 03:48:25 +09:00
30. **Phase 70-B-MULTIHOP-PASSTHROUGH（完了✅ 2025-12-13）**: Multihop relay passthrough 対応（dev-only）
- Runtime guard を「常時エラー」から「未対応ケースのみエラー」に縮め、passthrough パターン受理。
- 構造判定: `is_supported_multihop_pattern()` で self-conflict 検出。
- 実装コミット: `c2df1cac`
- テスト: normalized_dev 52/52, lib 950/950 PASS
31. **Phase 70-C-MERGE-RELAY（完了✅ 2025-12-13）**: Merge relay 検出（dev-only）
- 複数の inner loop が同一 owner の変数を更新するパターンを検出・受理。
- Validator は個別の relay をチェック（cross-plan consistency は Phase 70-D+ へ先送り）。
- 実装コミット: `24cc948f`
- テスト: normalized_dev 54/54, lib 950/950 PASS
32. **Phase 72-PHI-RESERVED-OBSERVATION（完了✅ 2025-12-13）**: PHI Reserved Region 検証観測
obs(joinir): Phase 72 - PHI Reserved Region Observation Complete ## Summary Observed PHI dst ValueId distribution to determine if verifier can enforce reserved region (0-99). **Conclusion: Verifier strengthening NOT recommended.** ## Key Finding PHI dst allocation does NOT architecturally respect reserved region: - PHI dst comes from `builder.next_value_id()` (host MirBuilder) - Reserved region (0-99) is a JoinValueSpace contract for JoinIR lowering - These are separate allocation pools with no enforcement mechanism - Current stability is accidental (ValueId allocation ordering) ## Evidence Manual verification (`apps/tests/loop_min_while.hako`): - PHI dst = %3 (ValueId(3)) ✅ in reserved region - Works because PHI allocated early in function (0-20 typical) - JoinValueSpace allocates high (100+, 1000+) - Accidental separation, not enforced ## Implementation Added observation infrastructure (debug-only): - `src/mir/join_ir/verify_phi_reserved.rs` (266 lines) - PHI dst observer with distribution analyzer - Region classifier (Reserved/Param/Local) - Human-readable report generator - Instrumentation at PHI allocation points: - loop_header_phi_builder.rs:94, 151 - Debug-only `observe_phi_dst()` calls ## Test Results - Unit tests: ✅ 4/4 PASS (verify_phi_reserved module) - Lib tests: ✅ 950/950 PASS, 56 ignored - Normalized tests: ✅ 54/54 PASS - Manual verification: ✅ PHI dst in 0-99 observed ## Decision: Document, Don't Enforce **Rationale**: 1. No architectural mechanism to enforce PHI dst ∈ [0, 99] 2. Adding verifier creates false assumptions about allocation order 3. Current system stable through separate pools (950/950 tests) 4. Future architectural fix possible (Phase 73+) but not urgent ## Documentation - PHASE_72_SUMMARY.md: Executive summary and implementation record - phase72-phi-reserved-observation.md: Detailed findings and analysis - CURRENT_TASK.md: Phase 72 completion entry ## Next Steps - Phase 73: Update architecture overview with Phase 72 findings - Optional: Explicit PHI reserved pool (future enhancement) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-13 03:23:02 +09:00
- PHI dst ValueId の分布を観測し、reserved region (0-99) への適合性を確認。
- 結論: PHI dst は builder.next_value_id() から割り当てられ、JoinValueSpace の reserved region とは独立。
- 決定: verifier 強化は **非推奨**（アーキテクチャ的根拠なし）。
- 現状: 偶発的な非衝突（MirBuilder=0-50, JoinValueSpace=100+）で安定動作中。
docs(roadmap): Update CURRENT_TASK.md with Phase 70-B/C/72/73 Add entries for completed phases: - Phase 70-B: Multihop passthrough support (c2df1cac) - Phase 70-C: Merge relay detection (24cc948f) - Phase 72: PHI reserved observation (253eb59b) - Phase 73: ScopeManager BindingId design + PoC (851bf4f8) Add next roadmap: - Phase 74-77: BindingId Migration (8-12 hours, 4 phases) - All phases with links to SSOT docs - Estimated effort per phase 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-13 03:48:25 +09:00
- 実装コミット: `253eb59b`
obs(joinir): Phase 72 - PHI Reserved Region Observation Complete ## Summary Observed PHI dst ValueId distribution to determine if verifier can enforce reserved region (0-99). **Conclusion: Verifier strengthening NOT recommended.** ## Key Finding PHI dst allocation does NOT architecturally respect reserved region: - PHI dst comes from `builder.next_value_id()` (host MirBuilder) - Reserved region (0-99) is a JoinValueSpace contract for JoinIR lowering - These are separate allocation pools with no enforcement mechanism - Current stability is accidental (ValueId allocation ordering) ## Evidence Manual verification (`apps/tests/loop_min_while.hako`): - PHI dst = %3 (ValueId(3)) ✅ in reserved region - Works because PHI allocated early in function (0-20 typical) - JoinValueSpace allocates high (100+, 1000+) - Accidental separation, not enforced ## Implementation Added observation infrastructure (debug-only): - `src/mir/join_ir/verify_phi_reserved.rs` (266 lines) - PHI dst observer with distribution analyzer - Region classifier (Reserved/Param/Local) - Human-readable report generator - Instrumentation at PHI allocation points: - loop_header_phi_builder.rs:94, 151 - Debug-only `observe_phi_dst()` calls ## Test Results - Unit tests: ✅ 4/4 PASS (verify_phi_reserved module) - Lib tests: ✅ 950/950 PASS, 56 ignored - Normalized tests: ✅ 54/54 PASS - Manual verification: ✅ PHI dst in 0-99 observed ## Decision: Document, Don't Enforce **Rationale**: 1. No architectural mechanism to enforce PHI dst ∈ [0, 99] 2. Adding verifier creates false assumptions about allocation order 3. Current system stable through separate pools (950/950 tests) 4. Future architectural fix possible (Phase 73+) but not urgent ## Documentation - PHASE_72_SUMMARY.md: Executive summary and implementation record - phase72-phi-reserved-observation.md: Detailed findings and analysis - CURRENT_TASK.md: Phase 72 completion entry ## Next Steps - Phase 73: Update architecture overview with Phase 72 findings - Optional: Explicit PHI reserved pool (future enhancement) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-13 03:23:02 +09:00
- 詳細: [PHASE_72_SUMMARY.md](docs/development/current/main/PHASE_72_SUMMARY.md), [phase72-phi-reserved-observation.md](docs/development/current/main/phase72-phi-reserved-observation.md)
docs(roadmap): Update CURRENT_TASK.md with Phase 70-B/C/72/73 Add entries for completed phases: - Phase 70-B: Multihop passthrough support (c2df1cac) - Phase 70-C: Merge relay detection (24cc948f) - Phase 72: PHI reserved observation (253eb59b) - Phase 73: ScopeManager BindingId design + PoC (851bf4f8) Add next roadmap: - Phase 74-77: BindingId Migration (8-12 hours, 4 phases) - All phases with links to SSOT docs - Estimated effort per phase 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-13 03:48:25 +09:00
33. **Phase 73-SCOPE-MANAGER-DESIGN（完了✅ 2025-12-13）**: ScopeManager BindingId 設計 + PoC（dev-only）
- JoinIR 側の name-based lookup を BindingId-based に段階移行する設計を確定。
- Option A (Parallel BindingId Layer) で段階移行可能性を実証（PoC 6/6 PASS）。
- 移行ロードマップ: Phase 74-77（合計 8-12時間、本番影響ゼロ）。
- 実装コミット: `851bf4f8`
- SSOT: [phase73-scope-manager-design.md](docs/development/current/main/phase73-scope-manager-design.md), [phase73-completion-summary.md](docs/development/current/main/phase73-completion-summary.md)
docs(task): Phase 74-77 status update + Phase 77 implementation readiness
2025-12-13 05:36:39 +09:00
34. **Phase 74-INFRASTRUCTURE（完了✅ 2025-12-13）**: binding_map + allocate_binding_id を MirBuilder に追加（dev-only）
- `BindingId` type と `allocate_binding_id()` メソッド実装
- `MirBuilder.binding_map: BTreeMap<String, BindingId>` 追加
- Shadowing test evidence 完備（4 tests PASS）
- 詳細: CURRENT_TASK.md Phase 74 section
35. **Phase 75-PILOT（完了✅ 2025-12-13）**: BindingId 優先 lookup を ConditionEnv に pilot 実装（dev-only）
- `ConditionEnv.resolve_var_with_binding()` メソッド追加（3-tier fallback: BindingId → name → None）
- `ScopeManager.lookup_with_binding()` trait method 追加（default impl）
- 3つのunit test PASS（priority/fallback/legacy）
- 958/958 lib tests PASS（退行なし）
- 詳細: [phase75-bindingid-pilot.md](docs/development/current/main/phase75-bindingid-pilot.md)
36. **Phase 76-PROMOTION（完了✅ 2025-12-13）**: promoted_bindings データ構造導入（dev-only）
- `CarrierInfo.promoted_bindings: BTreeMap<BindingId, BindingId>` 追加（Original → Promoted mapping）
- `resolve_promoted_with_binding()` / `record_promoted_binding()` メソッド実装
- Pattern2ScopeManager に promoted BindingId lookup を統合（3-tier: direct → promoted → name fallback）
- 5つのunit test PASS（record/resolve/merge/default/overwrite）
- 958/958 lib tests PASS（退行なし）
- 詳細: [phase76-promotion-binding-migration.md](docs/development/current/main/phase76-promotion-binding-migration.md)
37. **Phase 74-INFRASTRUCTURE（コミット済み✅ `e1574af7` 2025-12-13）**: BindingId infrastructure (dev-only)
- `binding_id.rs`: BindingId type + 5 unit tests
- `builder.rs`: binding_map + allocate_binding_id() + 4 integration tests
- `lexical_scope.rs`: Parallel binding_map restoration
- 9/9 new tests PASS, lib 958/958 PASS
38. **Phase 75-PILOT（コミット済み✅ `c18dde23` 2025-12-13）**: BindingId pilot lookup (dev-only)
- `scope_manager.rs`: lookup_with_binding() trait method
- `condition_env.rs`: resolve_var_with_binding() 3-tier fallback
- 3/3 pilot tests PASS, lib 958/958 PASS
39. **Phase 76-PROMOTION（コミット済み✅ `11e68203` 2025-12-13）**: promoted_bindings map (dev-only)
- `carrier_info.rs`: promoted_bindings field + resolve/record methods
- `pattern_pipeline.rs`: Carrier resolution via promoted_bindings
- 5/5 promotion tests PASS, lib 958/958 PASS
40. **Phase 77-EXPANSION（設計コミット済み✅ `4ab6c4e6` 2025-12-13）**: Pattern2→3→4 面拡大 + legacy 依存削減（実装待ち）
- **設計完了**: 3つの実装ガイド文書作成済み
- **実装スコープ** (2-3時間):
1. DigitPosPromoter/TrimLoopHelper で promoted_bindings を populate
2. Pattern3/4 へ BindingId lookup を拡張（dev-only variant）
3. Legacy name-based コード (~40行) を deprecate（削除は Phase 78+）
4. E2E verification tests 4件追加
- **詳細**:
- 設計: [phase77-expansion-completion.md](docs/development/current/main/phase77-expansion-completion.md)
- 実装ガイド: [PHASE_77_IMPLEMENTATION_GUIDE.md](docs/development/current/main/PHASE_77_IMPLEMENTATION_GUIDE.md)
- サマリ: [PHASE_77_EXECUTIVE_SUMMARY.md](docs/development/current/main/PHASE_77_EXECUTIVE_SUMMARY.md)
- **次のステップ**: 実装作業開始（PHASE_77_IMPLEMENTATION_GUIDE.md に従う）
docs(roadmap): Update CURRENT_TASK.md with Phase 70-B/C/72/73 Add entries for completed phases: - Phase 70-B: Multihop passthrough support (c2df1cac) - Phase 70-C: Merge relay detection (24cc948f) - Phase 72: PHI reserved observation (253eb59b) - Phase 73: ScopeManager BindingId design + PoC (851bf4f8) Add next roadmap: - Phase 74-77: BindingId Migration (8-12 hours, 4 phases) - All phases with links to SSOT docs - Estimated effort per phase 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-13 03:48:25 +09:00
---
docs(task): Phase 74-77 status update + Phase 77 implementation readiness
2025-12-13 05:36:39 +09:00
## 🚀 次フェーズ（Phase 77 実装 + Phase 78+ BindingId Migration 完結）
docs(roadmap): Update CURRENT_TASK.md with Phase 70-B/C/72/73 Add entries for completed phases: - Phase 70-B: Multihop passthrough support (c2df1cac) - Phase 70-C: Merge relay detection (24cc948f) - Phase 72: PHI reserved observation (253eb59b) - Phase 73: ScopeManager BindingId design + PoC (851bf4f8) Add next roadmap: - Phase 74-77: BindingId Migration (8-12 hours, 4 phases) - All phases with links to SSOT docs - Estimated effort per phase 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-13 03:48:25 +09:00
docs(task): Phase 74-77 status update + Phase 77 implementation readiness
2025-12-13 05:36:39 +09:00
### 【今すぐ着手】Phase 77-EXPANSION（実装フェーズ）
- **設計書**: [PHASE_77_IMPLEMENTATION_GUIDE.md](docs/development/current/main/PHASE_77_IMPLEMENTATION_GUIDE.md) に従う（Step-by-step code changes）
- **スコープ** (2-3時間):
1. DigitPosPromoter: `loop_body_digitpos_promoter.rs` で promoted_bindings を populate
2. TrimLoopHelper: `loop_body_carrier_promoter.rs` (Trim) で promoted_bindings を populate
3. Pattern3/4: Pattern lowerer で BindingId priority lookup を追加
4. Legacy deprecate: ~40行を Phase 78+ 削除予定に注釈
5. テスト追加: 4件の E2E verification tests
docs(roadmap): Update CURRENT_TASK.md with Phase 70-B/C/72/73 Add entries for completed phases: - Phase 70-B: Multihop passthrough support (c2df1cac) - Phase 70-C: Merge relay detection (24cc948f) - Phase 72: PHI reserved observation (253eb59b) - Phase 73: ScopeManager BindingId design + PoC (851bf4f8) Add next roadmap: - Phase 74-77: BindingId Migration (8-12 hours, 4 phases) - All phases with links to SSOT docs - Estimated effort per phase 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-13 03:48:25 +09:00
docs(task): Phase 74-77 status update + Phase 77 implementation readiness
2025-12-13 05:36:39 +09:00
### 【後続】Phase 78-LEGACY-DELETION（計画のみ）
- Deprecated code 完全削除 (~40行)、BindingId 必須化（1-2時間）
- 詳細: [phase73-scope-manager-design.md](docs/development/current/main/phase73-scope-manager-design.md) **Migration Roadmap** セクション参照
docs: Update CURRENT_TASK.md with Phase 188 completion summary
2025-12-05 16:00:31 +09:00
---
docs(phase170-d): Phase 170-D-impl-4 Completion - Tests and Documentation ## Summary Completed Phase 170-D-impl-4: Comprehensive documentation and test verification for LoopConditionScopeBox infrastructure. All four implementation phases (1-4) now complete with full modular Box-based architecture and thorough test coverage. ## Changes ### New Documentation - **phase170-d-impl-design.md** (1,356 lines): Comprehensive design document - Architecture overview and modular components - Detailed implementation summary for all 4 phases - Test results and verification procedures - Architecture decisions (Box Theory, Fail-Fast, Conservative Classification) - Future work for Phase 170-D-E and Phase 171+ ### Updated Documentation - **CURRENT_TASK.md**: Added Phase 170-D completion section - Full status overview - Completed work breakdown - Test verification results - Commit history - Architecture summary ## Implementation Status ### Phase 170-D-impl Complete Summary **Phase 170-D-impl-1** ✅ - LoopConditionScopeBox skeleton (220 lines) - CondVarScope enum and data structures - Public API design **Phase 170-D-impl-2** ✅ - Minimal analysis logic (317 lines) - Pure functions: extract_all_variables, is_outer_scope_variable - 12 comprehensive unit tests **Phase 170-D-impl-3** ✅ - Pattern 2/4 integration - Fail-Fast validation checks - 4 integration tests in loop_with_break_minimal.rs **Phase 170-D-impl-4** ✅ - Design documentation - Test verification and results - Architecture guide ### Module Structure ``` src/mir/loop_pattern_detection/ ├── mod.rs (201 lines) ├── loop_condition_scope.rs (220 lines) └── condition_var_analyzer.rs (317 lines) Total: 738 lines ``` ### Test Results ✅ Unit Tests: 16 total (12 in condition_var_analyzer + 4 in loop_with_break_minimal) ✅ Integration Tests: 2 verified (Pattern 2 accept/reject cases) ✅ Build: cargo build --release (0 errors, 50 warnings) ✅ Verification: NYASH_JOINIR_STRUCTURE_ONLY=1 tests pass ## Architecture Highlights - **Box Theory**: Clear separation of LoopConditionScopeBox (orchestration) and condition_var_analyzer (pure functions) - **Fail-Fast**: Early error detection before JoinIR generation - **Conservative Classification**: Defaults to LoopBodyLocal for unknown variables - **Reusable**: Pure functions independent and composition-friendly ## Future Work Phase 170-D-E: Advanced Patterns (Pattern 5+) - Support loop-body-local variables in conditions - Expanded scope heuristics - Selective pattern detection Phase 171: Condition Environment Integration - Tighter coupling with condition_to_joinir - Enhanced variable mapping 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-07 21:43:08 +09:00
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
## 📎 このファイルの運用ルール（自分向けメモ）
- 過去フェーズの詳細な ToDo/Done リストは **CURRENT_TASK には書かない**。
feat(joinir): Phase 245C - Function parameter capture + test fix Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
代わりに `docs/development/current/main/phase-*.md` と `joinir-architecture-overview.md` を SSOT として維持する。
feat(joinir): Phase 215-2 ExprResult exit contract for Pattern 3 Implements Phase 215 Task 215-2: Wire expr_result exit line through ExitMeta → JoinInlineBoundary → ExitLine → MIR return for Pattern 3. ## Changes ### Fix 1: JoinIR Lowerer (loop_with_if_phi_if_sum.rs:312) - Changed `carrier_only()` → `with_expr_result(sum_final, exit_meta)` - Marks sum final value as expr_result for propagation ### Fix 2: Boundary Builder (pattern3_with_if_phi.rs:176-191) - Added `.with_expr_result(Some(expr_id))` to JoinInlineBoundaryBuilder - Passes expr_result to boundary for ExitLineReconnector ### Fix 3: Final Return (pattern3_with_if_phi.rs:195-219) - Changed from always returning Void to conditional return: - Expr-position loops: Return merge_result ValueId - Statement-position loops: Return Void - Matches Pattern 2 behavior ## Test Results Primary target: - phase212_if_sum_min.hako: RC=2 achieved ✅ Regression tests: - loop_if_phi.hako: RC=2 (existing behavior maintained) ✅ - Pattern 1/2/3 tests: All PASS ✅ ## Architecture Pattern 3 now follows the same ExprResult Exit Contract as Pattern 2: 1. JoinIR lowerer creates expr_result with `with_expr_result()` 2. Boundary builder passes expr_result with `.with_expr_result()` 3. Conversion pipeline returns merge result containing exit PHI ValueId 4. Pattern dispatcher conditionally returns expr_result or Void This enables: - Expr-position loops: Loop result propagates to caller - Statement-position loops: Loop updates variable_map only (returns Void) - Unified contract: Patterns 2 and 3 follow same expr_result flow 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-10 01:40:18 +09:00
- CURRENT_TASK は「あくまで最新のフォーカスと次の候補だけ」に絞る。
目安として **このファイル自体は 2〜3画面程度（〜300行以内）** に収める。
- 新しい大フェーズを始めたら：
1. まず docs 配下に `phase-XXX-*.md` を書く。
2. CURRENT_TASK には「そのフェーズの一行要約」と「今のフォーカスかどうか」だけを書く。
Reference in New Issue Copy Permalink