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

68 lines
2.9 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
このファイルは「いま何に集中しているか」と「次にやり得る候補」だけを書く軽量ビューだよ。
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
詳細は `docs/development/current/main/` 以下の各 Phase 文書と、JoinIR の SSOT である
`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: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
最終更新: 2025-12-13
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: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
過去ログ（肥大化した旧 CURRENT_TASK）はここに退避したよ:
- `docs/development/current/main/CURRENT_TASK_ARCHIVE_2025-12-13.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: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
## 今の状態（Phase 74–86 まで到達）
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: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
- Scope/BindingId の段階移行（dev-only）は Pattern2/3/4 まで配線済み（dual-path 維持）。
- Pattern2 の promoted carriers（DigitPos/Trim）について ExitLine 契約（ConditionOnly を exit PHI から除外）を E2E で固定済み。
- debug flag SSOT / DebugOutputBox 移行 / error tags 集約 / carrier init builder まで整備済み。
- `cargo test --release --lib` は PASS を維持（退行なし）。
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: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
参照:
- `docs/development/current/main/10-Now.md`
- `docs/development/current/main/phase73-scope-manager-design.md`
- `docs/development/current/main/phase80-bindingid-p3p4-plan.md`
- `docs/development/current/main/phase81-pattern2-exitline-contract.md`
- `docs/development/current/main/phase78-85-boxification-feedback.md`
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(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
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
## 次の指示書（優先順位）
docs: Update CURRENT_TASK.md with Phase 188 completion summary
2025-12-05 16:00:31 +09:00
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
### P0: SSOT の軽い追記（docs-only）
docs: Update CURRENT_TASK.md with Phase 188 completion summary
2025-12-05 16:00:31 +09:00
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
- `docs/development/current/main/10-Now.md` の「Scope / BindingId」節に Phase 86 の到達点（carrier init / error tags）を 2〜3 行で追記。
- `docs/development/current/main/joinir-architecture-overview.md` の関連ドキュメントに Phase 86 の成果物（該当モジュール）を追記。
docs(current): mark Phase 77 done, queue Phase 78
2025-12-13 06:14:00 +09:00
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
受け入れ基準:
- docs-only でコミットできる粒度（コード差分ゼロ）。
docs(current): mark Phase 77 done, queue Phase 78
2025-12-13 06:14:00 +09:00
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
### P1: Selfhost / LLVM exe ラインの前進（Phase 87 候補）
docs(current): mark Phase 77 done, queue Phase 78
2025-12-13 06:14:00 +09:00
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
目的:
- LLVM で「実アプリを exe まで持っていく」導線を SSOT 化し、代表スモークを 1 本固定する。
docs(current): mark Phase 77 done, queue Phase 78
2025-12-13 06:14:00 +09:00
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
やること（設計→実装の順）:
1. SSOT 追加: `docs/development/current/main/phase87-selfhost-llvm-exe-line.md`
2. 既存スクリプト/コマンドの棚卸し（何が “標準手順” かを決める）
3. 代表ケース（最小の .hako アプリ）で build→run→stdout/exit を固定
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: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
受け入れ基準:
- 代表ケースが 1 コマンドで再現可能（CI は増やさない、quick を重くしない）。
feat(joinir): Phase 78 - BindingId infrastructure for promoted carriers (dev-only) Phase 78 adds infrastructure to assign BindingIds to synthetic promoted carriers (e.g., is_digit_pos, is_ch_match), enabling type-safe promoted variable lookup without string-based naming conventions. Key Changes: 1. CarrierVar.binding_id field (dev-only): - Added Option<BindingId> to track BindingId for each carrier - Updated all constructors and struct instantiations 2. CarrierBindingAssigner Box (new file, 273 lines): - Allocates BindingIds for promoted carriers via builder.allocate_binding_id() - Records original → promoted mapping in promoted_bindings - Sets binding_id field on promoted CarrierVar - Includes 3 comprehensive unit tests 3. ConditionEnv.register_carrier_binding() (new method): - Registers carrier BindingId → ValueId mappings - Enables type-safe lookup via binding_id_map 4. Logging cleanup: - Gated 6 eprintln! statements with NYASH_JOINIR_DEBUG - Unified logging tags to [binding_pilot/*] Design Decisions: - Promoters create CarrierInfo, lowering code assigns BindingIds - CarrierBindingAssigner called from Pattern2/4 lowering (has builder access) - Clear documentation prevents misuse (promoters lack builder access) Files modified (18): - carrier_info.rs: binding_id field added to CarrierVar - carrier_binding_assigner.rs: New Box for BindingId allocation - condition_env.rs: register_carrier_binding() method - mod.rs: Module exports - pattern2_with_break.rs, pattern4_with_continue.rs: Updated for binding_id - loop_body_*_promoter.rs: Logging cleanup + binding_id in structs - phase78-bindingid-promoted-carriers.md: Architecture documentation Tests: 970/970 PASS (zero regressions) Status: Infrastructure complete, integration deferred to Phase 79 Next Phase: Wire CarrierBindingAssigner in Pattern2/4 lowering + E2E tests 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-13 16:20:33 +09:00
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
### P2: Ownership/Relay runtime 対応の再開（Phase 88 候補）
feat(joinir): Phase 78 - BindingId infrastructure for promoted carriers (dev-only) Phase 78 adds infrastructure to assign BindingIds to synthetic promoted carriers (e.g., is_digit_pos, is_ch_match), enabling type-safe promoted variable lookup without string-based naming conventions. Key Changes: 1. CarrierVar.binding_id field (dev-only): - Added Option<BindingId> to track BindingId for each carrier - Updated all constructors and struct instantiations 2. CarrierBindingAssigner Box (new file, 273 lines): - Allocates BindingIds for promoted carriers via builder.allocate_binding_id() - Records original → promoted mapping in promoted_bindings - Sets binding_id field on promoted CarrierVar - Includes 3 comprehensive unit tests 3. ConditionEnv.register_carrier_binding() (new method): - Registers carrier BindingId → ValueId mappings - Enables type-safe lookup via binding_id_map 4. Logging cleanup: - Gated 6 eprintln! statements with NYASH_JOINIR_DEBUG - Unified logging tags to [binding_pilot/*] Design Decisions: - Promoters create CarrierInfo, lowering code assigns BindingIds - CarrierBindingAssigner called from Pattern2/4 lowering (has builder access) - Clear documentation prevents misuse (promoters lack builder access) Files modified (18): - carrier_info.rs: binding_id field added to CarrierVar - carrier_binding_assigner.rs: New Box for BindingId allocation - condition_env.rs: register_carrier_binding() method - mod.rs: Module exports - pattern2_with_break.rs, pattern4_with_continue.rs: Updated for binding_id - loop_body_*_promoter.rs: Logging cleanup + binding_id in structs - phase78-bindingid-promoted-carriers.md: Architecture documentation Tests: 970/970 PASS (zero regressions) Status: Infrastructure complete, integration deferred to Phase 79 Next Phase: Wire CarrierBindingAssigner in Pattern2/4 lowering + E2E tests 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-13 16:20:33 +09:00
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
目的:
- multihop/merge relay を “runtime でも” 受理できるところまで契約を伸ばす（Fail-Fast の段階解除）。
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: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
受け入れ基準:
- dev-only 既定OFF のまま、既存ラインを壊さない。
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
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
## すぐ走らせる確認コマンド
- `cargo test --release --lib`
- `NYASH_JOINIR_NORMALIZED_DEV_RUN=1 cargo test --features normalized_dev --test normalized_joinir_min -- --nocapture`
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
Reference in New Issue Copy Permalink