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

140 lines
7.1 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: mark loop canonicalizer Phase 137-141 complete
2025-12-16 07:54:33 +09:00
最終更新: 2025-12-16
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(phase131): LLVM SSOT強化 + ConsoleBox調査完了 + Phase86-90要約 Phase 131-1 完了: LLVM exe line SSOT 強化 - phase87-selfhost-llvm-exe-line.md に 4セクション追加（+300行） - 環境変数リファレンス（14変数） - 成功/失敗基準（exit code 0/1/2/3） - コンパイラモード説明（harness vs crate） - デバッグセクション拡張 - "1コマンドで再現" 可能な状態を確立 Phase 131-2 完了: ConsoleBox 問題調査 - VM の 3重登録経路を特定（BoxFactoryRegistry/UnifiedRegistry/Builtin） - LLVM backend は Phase 133 で解決済み - 3つのドキュメント作成: - phase131-2-consolebox-investigation.md（詳細調査） - phase131-2-summary.md（エグゼクティブサマリ） - phase131-2-box-resolution-map.md（Box 解決マップ） Phase 86-90 完了: Loop frontends 要約 - phase86-90-loop-frontends-summary.md 追加 - Pattern4/ContinueReturn/ParseStringComposite の経緯を1枚に集約 - INDEX から導線追加 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:24:31 +09:00
## 今の状態（Phase 74–90 まで到達）
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 まで整備済み。
feat(llvm): Phase 87 - LLVM exe line SSOT + integration smoke Established single pipeline for .hako → executable generation. SSOT: tools/build_llvm.sh - Standard procedure: build_llvm.sh input.hako -o output_exe - Prerequisites: llvm-config-18, llvmlite, LLVM features enabled - Pipeline: .hako → MIR → LLVM IR → .o → executable New files: - docs: phase87-selfhost-llvm-exe-line.md (SSOT procedure doc) * Full troubleshooting guide (llvm-config, llvmlite, linking) * Advanced usage (custom output, debugging, performance notes) * Anti-patterns documentation (no duplication/fragmentation) - fixture: apps/tests/phase87_llvm_exe_min.hako (5 lines, return 42) - smoke: integration/apps/phase87_llvm_exe_min.sh * Exit code verification (stdout-independent testing) * SKIP if LLVM unavailable (graceful degradation) * Integration profile only (not in quick) - index: 10-Now.md, 01-JoinIR-Selfhost-INDEX.md (Phase 87 entries) - task: CURRENT_TASK.md (Phase 74-87 status update) Integration smoke: demonstrates full pipeline - Build: .hako → .o → exe (successful ✅) - Runtime: Ring0 initialization issue (known limitation, out of scope) Quick profile: unchanged (integration only, per policy) Policy: No duplicate build paths, SSOT maintained 987/987 tests PASS (production stable)
2025-12-13 22:51:13 +09:00
- **LLVM exe line SSOT 確立**: `tools/build_llvm.sh` を使用した .hako → executable パイプライン標準化完了。
fix(llvm): Phase 131-10 - Smart console.log routing（Segfault修正） ## 問題 - Integer値をi8*ポインタに変換 → Segfault（Exit 139） ## 解決策 - String literal → nyash.console.log(i8*) - Integer/Handle → nyash.console.log_handle(i64) ## 結果 - Case B (loop_min_while): LLVM outputs `0,1,2` ✅ - VM/LLVM完全パリティ達成 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-14 09:19:00 +09:00
- **LLVM AOT（Python llvmlite）ループ復旧**: `apps/tests/loop_min_while.hako` が EMIT/LINK/RUN まで到達（Phase 131-3..10）。
feat(joinir): Phase 132-P3 - Exit PHI collision early detection Added verify_exit_phi_no_collision() to contract_checks.rs for early detection of ValueId collisions between exit PHIs and other instructions. Problem detected: - If exit_phi_builder uses builder.value_gen.next() (module-level) instead of func.next_value_id() (function-level), ValueIds can collide: Example: - bb0: %1 = const 0 (counter init) - bb3: %1 = phi ... (exit PHI - collision!) Previous behavior: - Error only detected at LLVM backend runtime - Cryptic error: "Cannot overwrite PHI dst=1" New behavior: - Panic at Rust compile time (debug build) - Clear error message with fix suggestion: "Exit PHI dst %1 collides with instruction in block 0 Fix: Use func.next_value_id() in exit_phi_builder.rs" Benefits: - 🔥 Fail-Fast: Catch errors during Rust compilation, not LLVM execution - 📋 Clear messages: Exact collision point + fix suggestion - 🧪 Testable: verify_exit_phi_no_collision() can be unit tested 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-15 06:00:48 +09:00
- Case C（`loop(true)` + break/continue）は Phase 131-11 で Pattern/shape guard を整備し、Phase 132-P2 で LLVM EXE まで parity（`Result: 3`）を確認。
- **Phase 132 完了**: ループ exit 値（exit PHI / boundary）の VM/LLVM parity を根治。
feat(llvm): Phase 132 - Pattern 1 exit value parity fix + Box-First refactoring ## Phase 132: Exit PHI Value Parity Fix ### Problem Pattern 1 (Simple While) returned 0 instead of final loop variable value (3) - VM: RC: 3 ✅ (correct) - LLVM: Result: 0 ❌ (wrong) ### Root Cause (Two Layers) 1. **JoinIR/Boundary**: Missing exit_bindings → ExitLineReconnector not firing 2. **LLVM Python**: block_end_values snapshot dropping PHI values ### Fix **JoinIR** (simple_while_minimal.rs): - Jump(k_exit, [i_param]) passes exit value **Boundary** (pattern1_minimal.rs): - Added LoopExitBinding with carrier_name="i", role=LoopState - Enables ExitLineReconnector to update variable_map **LLVM** (block_lower.py): - Use predeclared_ret_phis for reliable PHI filtering - Protect builder.vmap PHIs from overwrites (SSOT principle) ### Result - ✅ VM: RC: 3 - ✅ LLVM: Result: 3 - ✅ VM/LLVM parity achieved ## Phase 132-Post: Box-First Refactoring ### Rust Side **JoinModule::require_function()** (mod.rs): - Encapsulate function search logic - 10 lines → 1 line (90% reduction) - Reusable for Pattern 2-5 ### Python Side **PhiManager Box** (phi_manager.py - new): - Centralized PHI lifecycle management - 47 lines → 8 lines (83% reduction) - SSOT: builder.vmap owns PHIs - Fail-Fast: No silent overwrites **Integration**: - LLVMBuilder: Added phi_manager - block_lower.py: Delegated to PhiManager - tagging.py: Register PHIs with manager ### Documentation **New Files**: - docs/development/architecture/exit-phi-design.md - docs/development/current/main/investigations/phase132-llvm-exit-phi-wrong-result.md - docs/development/current/main/phases/phase-132/ **Updated**: - docs/development/current/main/10-Now.md - docs/development/current/main/phase131-3-llvm-lowering-inventory.md ### Design Principles - Box-First: Logic encapsulated in classes/methods - SSOT: Single Source of Truth (builder.vmap for PHIs) - Fail-Fast: Early explicit failures, no fallbacks - Separation of Concerns: 3-layer architecture 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-15 03:17:31 +09:00
- JoinIR/Boundary: exit 値を境界に明示的に渡す
- LLVM Python: PHI を落とす/上書きする経路を除去（PHI SSOT を保護）
feat(joinir): Phase 132-P3 - Exit PHI collision early detection Added verify_exit_phi_no_collision() to contract_checks.rs for early detection of ValueId collisions between exit PHIs and other instructions. Problem detected: - If exit_phi_builder uses builder.value_gen.next() (module-level) instead of func.next_value_id() (function-level), ValueIds can collide: Example: - bb0: %1 = const 0 (counter init) - bb3: %1 = phi ... (exit PHI - collision!) Previous behavior: - Error only detected at LLVM backend runtime - Cryptic error: "Cannot overwrite PHI dst=1" New behavior: - Panic at Rust compile time (debug build) - Clear error message with fix suggestion: "Exit PHI dst %1 collides with instruction in block 0 Fix: Use func.next_value_id() in exit_phi_builder.rs" Benefits: - 🔥 Fail-Fast: Catch errors during Rust compilation, not LLVM execution - 📋 Clear messages: Exact collision point + fix suggestion - 🧪 Testable: verify_exit_phi_no_collision() can be unit tested 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-15 06:00:48 +09:00
- JoinIR merge: exit PHI dst の allocator を function-level に統一（ValueId 衝突を排除）
docs: Phase 132-P3 verifier note
2025-12-15 06:08:19 +09:00
- debug-only: Exit PHI collision を早期検出する verifier を追加（LLVM 実行時に壊れる前に Fail-Fast）
feat(joinir): Phase 135 P0 - ConditionLoweringBox allocator SSOT (ValueId collision fix) ## Summary Root cause: ConditionLoweringBox was bypassing ConditionContext.alloc_value (SSOT allocator), causing ValueId collisions between JoinIR condition params and lowered instructions. ## Changes 1. **ConditionLoweringBox (expr_lowerer.rs)**: Must use ConditionContext.alloc_value - Pass &mut ConditionContext to lower_condition (SSOT allocator) - Eliminates internal counter usage 2. **Allocator unification (condition_lowerer.rs, method_call_lowerer.rs)**: - Accept &mut dyn FnMut() -> ValueId as allocator parameter - Ensures all lowering paths use same SSOT allocator 3. **Boundary Copy deduplication (joinir_inline_boundary_injector.rs)**: - Deduplicate condition_bindings by dst - Fail-Fast if different sources target same dst (MIR SSA violation) 4. **Trim pattern fixes (trim_loop_lowering.rs, trim_pattern_validator.rs, stmts.rs)**: - Use builder.next_value_id() instead of value_gen.next() in function context - Ensures function-level ValueId allocation respects reserved PHI dsts ## Acceptance ✅ ./target/release/hakorune --verify apps/tests/phase133_json_skip_whitespace_min.hako ✅ Smoke: phase135_trim_mir_verify.sh - MIR SSA validation PASS ✅ Regression: phase132_exit_phi_parity.sh - 3/3 PASS ✅ Regression: phase133_json_skip_whitespace_llvm_exe.sh - compile-only PASS 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-15 18:49:08 +09:00
- **Phase 133 完了**: Promoted carrier の `join_id` 解決（Trim）を SSOT に寄せて根治（smoke は compile-only）。
- **Phase 134 完了**: Plugin loader best-effort loading（決定的順序 + failure 集約 + 継続）を導入。
feat(mir): Phase 136 P0 - ValueId allocator SSOT 徹底（関数内経路から value_gen.next() 掃討） ## Summary Eliminates remaining `value_gen.next()` calls from function-context code paths, unifying all ValueId allocation through `MirBuilder::next_value_id()` SSOT allocator. ## Changes ### 1. Fixed `new_typed_value()` (src/mir/builder.rs:1068) **Before**: `let id = self.value_gen.next();` (bypasses function context) **After**: `let id = self.next_value_id();` (respects function context) This is a public API used in function context, so must use SSOT allocator to avoid collisions with reserved PHI dsts and function params. ### 2. Fixed test code (src/mir/builder.rs) **test_shadowing_binding_restore** (lines 1161, 1171): - Simulates function scope with `push_lexical_scope()` - Changed to `builder.next_value_id()` for function scope simulation **test_valueid_binding_parallel_allocation** (lines 1196-1216): - Tests ValueId/BindingId independence - Changed to `builder.next_value_id()` with note that Module context fallback preserves test intent ### 3. Verified Module context fallbacks (OK, no change needed) These already check `current_function.is_some()` and use `value_gen.next()` only as Module context fallback: - `src/mir/builder/utils.rs:43` - next_value_id() SSOT implementation - `src/mir/builder/utils.rs:436` - pin_to_slot() - `src/mir/builder/utils.rs:467` - materialize_local() - `src/mir/utils/phi_helpers.rs:69` - insert_phi_unified() ## Verification ```bash rg -n "value_gen\.next\(" src/mir --type rust | grep -v "Module context" | grep -v "//" # Result: Only comments/docs remain ``` ## Acceptance ✅ cargo test --release --lib - 997 passed ✅ phase135_trim_mir_verify.sh - PASS ✅ phase132_exit_phi_parity.sh - 3/3 PASS ✅ All function-context `value_gen.next()` eliminated ## Effect - **Collision prevention**: No more ValueId collisions between function-level allocations and reserved PHI dsts - **SSOT compliance**: All ValueId allocation flows through single allocator - **Contract enforcement**: Phase 135 P1 contract_checks will catch violations immediately 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-15 19:37:30 +09:00
- **Phase 135 完了**: ConditionLoweringBox allocator SSOT（P0: 根治修正 + P1: contract_checks Fail-Fast 強化）。
docs: add loop canonicalizer SSOT + MirBuilder entrypoint
2025-12-16 04:37:47 +09:00
- **Phase 136 完了**: MirBuilder Context SSOT 化（+ ValueId allocator 掃討）。
docs: mark loop canonicalizer Phase 137-141 complete
2025-12-16 07:54:33 +09:00
- **Phase 137-141 完了**: Loop Canonicalizer（前処理 SSOT）を実装・箱化・型安全化・統合・ドキュメントまで完了（既定挙動は不変）。
docs: Phase 88-89 完了 + Phase 90 P0 追加 ## CURRENT_TASK.md - Phase 88-89 完了を反映 - Phase 90 P0 追加（_parse_string 合成 fixture） - P1/P2 候補を Phase 91/92 に繰り上げ - 最終更新: 2025-12-14 ## 10-Now.md - Phase 88 到達点を追記（continue + 可変ステップ） - Phase 89 P0/P1 到達点を追記（ContinueReturn detector + lowering） - 未検証の断定は書かない（dev-only fixture で固定、と明記） Impact: - 正確な進捗記録 - Phase 90 の明確な方針（fixture → detector → lowering） 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 02:31:39 +09:00
- **Phase 88 完了**: continue + 可変ステップ（i=i+const 差分）を dev-only fixture で固定、StepCalculator Box 抽出。
- **Phase 89 完了**: P0（ContinueReturn detector）+ P1（lowering 実装）完了。
docs(phase131): LLVM SSOT強化 + ConsoleBox調査完了 + Phase86-90要約 Phase 131-1 完了: LLVM exe line SSOT 強化 - phase87-selfhost-llvm-exe-line.md に 4セクション追加（+300行） - 環境変数リファレンス（14変数） - 成功/失敗基準（exit code 0/1/2/3） - コンパイラモード説明（harness vs crate） - デバッグセクション拡張 - "1コマンドで再現" 可能な状態を確立 Phase 131-2 完了: ConsoleBox 問題調査 - VM の 3重登録経路を特定（BoxFactoryRegistry/UnifiedRegistry/Builtin） - LLVM backend は Phase 133 で解決済み - 3つのドキュメント作成: - phase131-2-consolebox-investigation.md（詳細調査） - phase131-2-summary.md（エグゼクティブサマリ） - phase131-2-box-resolution-map.md（Box 解決マップ） Phase 86-90 完了: Loop frontends 要約 - phase86-90-loop-frontends-summary.md 追加 - Pattern4/ContinueReturn/ParseStringComposite の経緯を1枚に集約 - INDEX から導線追加 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:24:31 +09:00
- **Phase 90 完了**: ParseStringComposite + `Null` literal + ContinueReturn（同一値の複数 return-if）を dev-only fixture で固定。
docs: Phase 88-89 完了 + Phase 90 P0 追加 ## CURRENT_TASK.md - Phase 88-89 完了を反映 - Phase 90 P0 追加（_parse_string 合成 fixture） - P1/P2 候補を Phase 91/92 に繰り上げ - 最終更新: 2025-12-14 ## 10-Now.md - Phase 88 到達点を追記（continue + 可変ステップ） - Phase 89 P0/P1 到達点を追記（ContinueReturn detector + lowering） - 未検証の断定は書かない（dev-only fixture で固定、と明記） Impact: - 正確な進捗記録 - Phase 90 の明確な方針（fixture → detector → lowering） 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 02:31:39 +09:00
- `cargo test --release --lib` は PASS を維持（993 passed、退行なし）。
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(phase131): LLVM SSOT強化 + ConsoleBox調査完了 + Phase86-90要約 Phase 131-1 完了: LLVM exe line SSOT 強化 - phase87-selfhost-llvm-exe-line.md に 4セクション追加（+300行） - 環境変数リファレンス（14変数） - 成功/失敗基準（exit code 0/1/2/3） - コンパイラモード説明（harness vs crate） - デバッグセクション拡張 - "1コマンドで再現" 可能な状態を確立 Phase 131-2 完了: ConsoleBox 問題調査 - VM の 3重登録経路を特定（BoxFactoryRegistry/UnifiedRegistry/Builtin） - LLVM backend は Phase 133 で解決済み - 3つのドキュメント作成: - phase131-2-consolebox-investigation.md（詳細調査） - phase131-2-summary.md（エグゼクティブサマリ） - phase131-2-box-resolution-map.md（Box 解決マップ） Phase 86-90 完了: Loop frontends 要約 - phase86-90-loop-frontends-summary.md 追加 - Pattern4/ContinueReturn/ParseStringComposite の経緯を1枚に集約 - INDEX から導線追加 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:24:31 +09:00
- `docs/development/current/main/phase86-90-loop-frontends-summary.md`
docs: archive CURRENT_TASK and add lightweight view
2025-12-13 22:21:04 +09:00
- `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`
feat(llvm): Phase 87 - LLVM exe line SSOT + integration smoke Established single pipeline for .hako → executable generation. SSOT: tools/build_llvm.sh - Standard procedure: build_llvm.sh input.hako -o output_exe - Prerequisites: llvm-config-18, llvmlite, LLVM features enabled - Pipeline: .hako → MIR → LLVM IR → .o → executable New files: - docs: phase87-selfhost-llvm-exe-line.md (SSOT procedure doc) * Full troubleshooting guide (llvm-config, llvmlite, linking) * Advanced usage (custom output, debugging, performance notes) * Anti-patterns documentation (no duplication/fragmentation) - fixture: apps/tests/phase87_llvm_exe_min.hako (5 lines, return 42) - smoke: integration/apps/phase87_llvm_exe_min.sh * Exit code verification (stdout-independent testing) * SKIP if LLVM unavailable (graceful degradation) * Integration profile only (not in quick) - index: 10-Now.md, 01-JoinIR-Selfhost-INDEX.md (Phase 87 entries) - task: CURRENT_TASK.md (Phase 74-87 status update) Integration smoke: demonstrates full pipeline - Build: .hako → .o → exe (successful ✅) - Runtime: Ring0 initialization issue (known limitation, out of scope) Quick profile: unchanged (integration only, per policy) Policy: No duplicate build paths, SSOT maintained 987/987 tests PASS (production stable)
2025-12-13 22:51:13 +09:00
- `docs/development/current/main/phase87-selfhost-llvm-exe-line.md`
docs(phase131): Phase 131-3 完了 - LLVM lowering 棚卸し（3ケース） Phase 131-3 完了: MIR→LLVM lowering 棚卸し テスト結果マトリックス: - Case A (phase87_llvm_exe_min.hako): ✅ PASS (baseline) - Case B (loop_min_while.hako): ❌ TAG-EMIT (PHI after terminator) - Case B2 (print(42) simple): ✅ PASS (BoxCall works) - Case C (llvm_stage3_loop_only.hako): ❌ TAG-EMIT (JoinIR pattern gap) Critical Bugs: 1. Bug #1: PHI After Terminator (Case B) - 原因: function_lower.py が terminator を PHI より先に emit - 修正: 4-pass block emission (2-3h) 2. Bug #2: JoinIR Pattern Gap (Case C) - 原因: loop(true) { break } パターンが JoinIR 未対応 - 修正: Pattern 5 設計・実装 (3-4h) Next Actions: - P1 (推奨): PHI ordering 修正 → 80% のループを有効化 - P2: JoinIR Pattern 5 → infinite loop 対応 ドキュメント: - phase131-3-llvm-lowering-inventory.md: 詳細棚卸し結果 - phase87-selfhost-llvm-exe-line.md: LLVM IR parsing error 追記 - CURRENT_TASK.md: phase131-3 参照追加 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:55:21 +09:00
- `docs/development/current/main/phase131-2-box-resolution-map.md`
- `docs/development/current/main/phase131-3-llvm-lowering-inventory.md`
fix(llvm): Phase 131-10 - Smart console.log routing（Segfault修正） ## 問題 - Integer値をi8*ポインタに変換 → Segfault（Exit 139） ## 解決策 - String literal → nyash.console.log(i8*) - Integer/Handle → nyash.console.log_handle(i64) ## 結果 - Case B (loop_min_while): LLVM outputs `0,1,2` ✅ - VM/LLVM完全パリティ達成 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-14 09:19:00 +09:00
- `docs/development/current/main/phase131-5-taglink-fix-summary.md`
feat(llvm): Phase 132 - Pattern 1 exit value parity fix + Box-First refactoring ## Phase 132: Exit PHI Value Parity Fix ### Problem Pattern 1 (Simple While) returned 0 instead of final loop variable value (3) - VM: RC: 3 ✅ (correct) - LLVM: Result: 0 ❌ (wrong) ### Root Cause (Two Layers) 1. **JoinIR/Boundary**: Missing exit_bindings → ExitLineReconnector not firing 2. **LLVM Python**: block_end_values snapshot dropping PHI values ### Fix **JoinIR** (simple_while_minimal.rs): - Jump(k_exit, [i_param]) passes exit value **Boundary** (pattern1_minimal.rs): - Added LoopExitBinding with carrier_name="i", role=LoopState - Enables ExitLineReconnector to update variable_map **LLVM** (block_lower.py): - Use predeclared_ret_phis for reliable PHI filtering - Protect builder.vmap PHIs from overwrites (SSOT principle) ### Result - ✅ VM: RC: 3 - ✅ LLVM: Result: 3 - ✅ VM/LLVM parity achieved ## Phase 132-Post: Box-First Refactoring ### Rust Side **JoinModule::require_function()** (mod.rs): - Encapsulate function search logic - 10 lines → 1 line (90% reduction) - Reusable for Pattern 2-5 ### Python Side **PhiManager Box** (phi_manager.py - new): - Centralized PHI lifecycle management - 47 lines → 8 lines (83% reduction) - SSOT: builder.vmap owns PHIs - Fail-Fast: No silent overwrites **Integration**: - LLVMBuilder: Added phi_manager - block_lower.py: Delegated to PhiManager - tagging.py: Register PHIs with manager ### Documentation **New Files**: - docs/development/architecture/exit-phi-design.md - docs/development/current/main/investigations/phase132-llvm-exit-phi-wrong-result.md - docs/development/current/main/phases/phase-132/ **Updated**: - docs/development/current/main/10-Now.md - docs/development/current/main/phase131-3-llvm-lowering-inventory.md ### Design Principles - Box-First: Logic encapsulated in classes/methods - SSOT: Single Source of Truth (builder.vmap for PHIs) - Fail-Fast: Early explicit failures, no fallbacks - Separation of Concerns: 3-layer architecture 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-15 03:17:31 +09:00
- `docs/development/current/main/phases/phase-132/README.md`
- `docs/development/current/main/investigations/phase132-llvm-exit-phi-wrong-result.md`
feat(joinir): Phase 132-P3 - Exit PHI collision early detection Added verify_exit_phi_no_collision() to contract_checks.rs for early detection of ValueId collisions between exit PHIs and other instructions. Problem detected: - If exit_phi_builder uses builder.value_gen.next() (module-level) instead of func.next_value_id() (function-level), ValueIds can collide: Example: - bb0: %1 = const 0 (counter init) - bb3: %1 = phi ... (exit PHI - collision!) Previous behavior: - Error only detected at LLVM backend runtime - Cryptic error: "Cannot overwrite PHI dst=1" New behavior: - Panic at Rust compile time (debug build) - Clear error message with fix suggestion: "Exit PHI dst %1 collides with instruction in block 0 Fix: Use func.next_value_id() in exit_phi_builder.rs" Benefits: - 🔥 Fail-Fast: Catch errors during Rust compilation, not LLVM execution - 📋 Clear messages: Exact collision point + fix suggestion - 🧪 Testable: verify_exit_phi_no_collision() can be unit tested 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-15 06:00:48 +09:00
- `docs/development/current/main/investigations/phase132-case-c-llvm-exe.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: mark loop canonicalizer Phase 137-141 complete
2025-12-16 07:54:33 +09:00
### P0: Canonicalizer の適用範囲拡大（実ループ 1 本）
docs(phase131): LLVM SSOT強化 + ConsoleBox調査完了 + Phase86-90要約 Phase 131-1 完了: LLVM exe line SSOT 強化 - phase87-selfhost-llvm-exe-line.md に 4セクション追加（+300行） - 環境変数リファレンス（14変数） - 成功/失敗基準（exit code 0/1/2/3） - コンパイラモード説明（harness vs crate） - デバッグセクション拡張 - "1コマンドで再現" 可能な状態を確立 Phase 131-2 完了: ConsoleBox 問題調査 - VM の 3重登録経路を特定（BoxFactoryRegistry/UnifiedRegistry/Builtin） - LLVM backend は Phase 133 で解決済み - 3つのドキュメント作成: - phase131-2-consolebox-investigation.md（詳細調査） - phase131-2-summary.md（エグゼクティブサマリ） - phase131-2-box-resolution-map.md（Box 解決マップ） Phase 86-90 完了: Loop frontends 要約 - phase86-90-loop-frontends-summary.md 追加 - Pattern4/ContinueReturn/ParseStringComposite の経緯を1枚に集約 - INDEX から導線追加 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:24:31 +09:00
docs: mark loop canonicalizer Phase 137-141 complete
2025-12-16 07:54:33 +09:00
**状態**: ✅ Phase 137-141 完了、次は “適用対象を増やす” 段階
docs(phase131): SSOT整備 - VM入口/env var/次の入口を1箇所に固定 Phase 131 SSOT 整備完了: 1) VM Box 解決の入口SSOT（phase131-2-box-resolution-map.md） - 📍 入口3行を先頭に追記（handle_new_box/UnifiedRegistry/BoxFactoryRegistry） - NYASH_VM_FAST を bench/profile-only 特例と明記 2) 環境変数のSSOTを1箇所へ（environment-variables.md） - ## LLVM Build Pipeline セクション新設（14変数） - phase87 の Environment Variables セクションを参照リンクに置き換え - 重複表を削除、SSOTドキュメントへの導線確立 3) 次の開発の入口を明確化（CURRENT_TASK.md） - P1（Loop Canonicalizer）: 🔶 設計待ち（外部検討中） - P2（JoinIR / Selfhost depth-2）: ✅ 実装可能 - 次に触るSSOTを1行で指定: - Loop系: joinir-architecture-overview.md - VM Box系: phase131-2-box-resolution-map.md Impact: - 迷子防止: 各領域のSSOTが1行で分かる - 重複削減: env var 表を environment-variables.md に集約 - 状態明確化: P1/P2 の「設計待ち/実装可能」が一目瞭然 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:27:39 +09:00
docs: mark loop canonicalizer Phase 137-141 complete
2025-12-16 07:54:33 +09:00
**目的**: canonicalizer を「実アプリ由来ループ」に 1 本ずつ適用し、認識→decision→strict parity を増やして coverage を広げる（既定挙動は不変、dev-only）。
docs(phase131): SSOT整備 - VM入口/env var/次の入口を1箇所に固定 Phase 131 SSOT 整備完了: 1) VM Box 解決の入口SSOT（phase131-2-box-resolution-map.md） - 📍 入口3行を先頭に追記（handle_new_box/UnifiedRegistry/BoxFactoryRegistry） - NYASH_VM_FAST を bench/profile-only 特例と明記 2) 環境変数のSSOTを1箇所へ（environment-variables.md） - ## LLVM Build Pipeline セクション新設（14変数） - phase87 の Environment Variables セクションを参照リンクに置き換え - 重複表を削除、SSOTドキュメントへの導線確立 3) 次の開発の入口を明確化（CURRENT_TASK.md） - P1（Loop Canonicalizer）: 🔶 設計待ち（外部検討中） - P2（JoinIR / Selfhost depth-2）: ✅ 実装可能 - 次に触るSSOTを1行で指定: - Loop系: joinir-architecture-overview.md - VM Box系: phase131-2-box-resolution-map.md Impact: - 迷子防止: 各領域のSSOTが1行で分かる - 重複削減: env var 表を environment-variables.md に集約 - 状態明確化: P1/P2 の「設計待ち/実装可能」が一目瞭然 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:27:39 +09:00
docs: add loop canonicalizer SSOT + MirBuilder entrypoint
2025-12-16 04:37:47 +09:00
SSOT:
- `docs/development/current/main/design/loop-canonicalizer.md`
feat(mir): Loop Canonicalizer Phase 3 - skip_whitespace pattern recognition ## Summary skip_whitespace パターンを Skeleton→Decision で認識可能に。 dev-only 観測で chosen=Pattern3IfPhi / missing_caps=[] を固定。 ## Changes - src/mir/loop_canonicalizer/mod.rs: - try_extract_skip_whitespace_pattern() 追加 - loop(cond) { ... if check { p = p + 1 } else { break } } パターン認識 - carrier name, delta, body statements を抽出 - canonicalize_loop_expr() 拡張（skip_whitespace 対応） - Pattern3IfPhi 成功時は RoutingDecision::success 返却 - Skeleton に HeaderCond, Body, Update ステップ追加 - CarrierSlot に Counter role 設定 - ExitContract に has_break=true 設定 - Phase 3 unit tests 追加 - test_skip_whitespace_pattern_recognition: 基本パターン - test_skip_whitespace_with_body_statements: body 付きパターン - test_skip_whitespace_fails_without_else: else なし失敗 - test_skip_whitespace_fails_with_wrong_delta: 減算パターン失敗 - Phase 2 obsolete tests 削除 - src/mir/builder/control_flow/joinir/routing.rs: - Debug 出力拡張（chosen pattern 表示） ## Tests - cargo test --release --lib loop_canonicalizer::tests: PASS（11 tests） - cargo test --release --lib: PASS（1044 tests, 退行なし） - HAKO_JOINIR_DEBUG=1 test_pattern3_skip_whitespace.hako: - chosen=Pattern3IfPhi ✅ - missing_caps=[] ✅ ## Validation - ✅ dev-only 観測（HAKO_JOINIR_DEBUG=1）のときだけログ出力 - ✅ フラグ OFF 時は完全不変 - ✅ skip_whitespace パターンで SUCCESS 固定 - ✅ unit tests で全パターン固定 Phase 137-3 complete
2025-12-16 05:38:18 +09:00
実装:
docs: update Phase 137-1 completion status and Phase 2 roadmap ## Summary Loop Canonicalizer Phase 1（型定義）の完了と、Phase 2（dev-only 観測）への ロードマップを記録。 ## Changes ### loop-canonicalizer.md - Status: Design (P0) → Phase 1 done（型定義まで） - 実装の入口を明記（src/mir/loop_canonicalizer/mod.rs） - NYASH_LOOP_ROUTING_TRACE → joinir_dev_enabled() に変更 （新 ENV を増やさず、既存のスイッチに寄せる） ### CURRENT_TASK.md - Phase 137-1 完了を追記 - P0 を「設計」→「Phase 2（dev-only 観測）」へ更新 ### phases/README.md - Phase 137 を追加 ### phases/phase-137/README.md (NEW) - Phase 1 完了サマリ - Phase 2 予定を最小で記録 ### joinir-design-map.md / 01-JoinIR-Selfhost-INDEX.md - loop-canonicalizer への導線を追加 ## Next Steps Phase 2: dev-only 観測の導入 - canonicalize_loop_expr() の薄い入口を追加 - joinir_dev_enabled() 配下でログ出し - 既定挙動は完全不変 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-16 05:10:29 +09:00
- `src/mir/loop_canonicalizer/mod.rs`
docs: mark loop canonicalizer Phase 137-141 complete
2025-12-16 07:54:33 +09:00
（SSOT入口）
- `src/mir/builder/control_flow/joinir/routing.rs`（`choose_pattern_kind`）
docs: add loop canonicalizer SSOT + MirBuilder entrypoint
2025-12-16 04:37:47 +09:00
**次に触るSSOT**:
docs(phase131): SSOT整備 - VM入口/env var/次の入口を1箇所に固定 Phase 131 SSOT 整備完了: 1) VM Box 解決の入口SSOT（phase131-2-box-resolution-map.md） - 📍 入口3行を先頭に追記（handle_new_box/UnifiedRegistry/BoxFactoryRegistry） - NYASH_VM_FAST を bench/profile-only 特例と明記 2) 環境変数のSSOTを1箇所へ（environment-variables.md） - ## LLVM Build Pipeline セクション新設（14変数） - phase87 の Environment Variables セクションを参照リンクに置き換え - 重複表を削除、SSOTドキュメントへの導線確立 3) 次の開発の入口を明確化（CURRENT_TASK.md） - P1（Loop Canonicalizer）: 🔶 設計待ち（外部検討中） - P2（JoinIR / Selfhost depth-2）: ✅ 実装可能 - 次に触るSSOTを1行で指定: - Loop系: joinir-architecture-overview.md - VM Box系: phase131-2-box-resolution-map.md Impact: - 迷子防止: 各領域のSSOTが1行で分かる - 重複削減: env var 表を environment-variables.md に集約 - 状態明確化: P1/P2 の「設計待ち/実装可能」が一目瞭然 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:27:39 +09:00
- Loop系の設計: `docs/development/current/main/joinir-architecture-overview.md`
docs(phase131): LLVM SSOT強化 + ConsoleBox調査完了 + Phase86-90要約 Phase 131-1 完了: LLVM exe line SSOT 強化 - phase87-selfhost-llvm-exe-line.md に 4セクション追加（+300行） - 環境変数リファレンス（14変数） - 成功/失敗基準（exit code 0/1/2/3） - コンパイラモード説明（harness vs crate） - デバッグセクション拡張 - "1コマンドで再現" 可能な状態を確立 Phase 131-2 完了: ConsoleBox 問題調査 - VM の 3重登録経路を特定（BoxFactoryRegistry/UnifiedRegistry/Builtin） - LLVM backend は Phase 133 で解決済み - 3つのドキュメント作成: - phase131-2-consolebox-investigation.md（詳細調査） - phase131-2-summary.md（エグゼクティブサマリ） - phase131-2-box-resolution-map.md（Box 解決マップ） Phase 86-90 完了: Loop frontends 要約 - phase86-90-loop-frontends-summary.md 追加 - Pattern4/ContinueReturn/ParseStringComposite の経緯を1枚に集約 - INDEX から導線追加 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:24:31 +09:00
注意:
docs: update Phase 137-1 completion status and Phase 2 roadmap ## Summary Loop Canonicalizer Phase 1（型定義）の完了と、Phase 2（dev-only 観測）への ロードマップを記録。 ## Changes ### loop-canonicalizer.md - Status: Design (P0) → Phase 1 done（型定義まで） - 実装の入口を明記（src/mir/loop_canonicalizer/mod.rs） - NYASH_LOOP_ROUTING_TRACE → joinir_dev_enabled() に変更 （新 ENV を増やさず、既存のスイッチに寄せる） ### CURRENT_TASK.md - Phase 137-1 完了を追記 - P0 を「設計」→「Phase 2（dev-only 観測）」へ更新 ### phases/README.md - Phase 137 を追加 ### phases/phase-137/README.md (NEW) - Phase 1 完了サマリ - Phase 2 予定を最小で記録 ### joinir-design-map.md / 01-JoinIR-Selfhost-INDEX.md - loop-canonicalizer への導線を追加 ## Next Steps Phase 2: dev-only 観測の導入 - canonicalize_loop_expr() の薄い入口を追加 - joinir_dev_enabled() 配下でログ出し - 既定挙動は完全不変 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-16 05:10:29 +09:00
- 既定挙動は変えない（dev-only で観測→段階投入）
- 新しい環境変数は増やさない（`joinir_dev_enabled()` の範囲で観測する）
docs(phase131): LLVM SSOT強化 + ConsoleBox調査完了 + Phase86-90要約 Phase 131-1 完了: LLVM exe line SSOT 強化 - phase87-selfhost-llvm-exe-line.md に 4セクション追加（+300行） - 環境変数リファレンス（14変数） - 成功/失敗基準（exit code 0/1/2/3） - コンパイラモード説明（harness vs crate） - デバッグセクション拡張 - "1コマンドで再現" 可能な状態を確立 Phase 131-2 完了: ConsoleBox 問題調査 - VM の 3重登録経路を特定（BoxFactoryRegistry/UnifiedRegistry/Builtin） - LLVM backend は Phase 133 で解決済み - 3つのドキュメント作成: - phase131-2-consolebox-investigation.md（詳細調査） - phase131-2-summary.md（エグゼクティブサマリ） - phase131-2-box-resolution-map.md（Box 解決マップ） Phase 86-90 完了: Loop frontends 要約 - phase86-90-loop-frontends-summary.md 追加 - Pattern4/ContinueReturn/ParseStringComposite の経緯を1枚に集約 - INDEX から導線追加 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:24:31 +09:00
docs: Update CURRENT_TASK.md - Phase 91 planning complete ## P1 Status Update - Phase 91 Step 1: ✅ COMPLETE - Loop inventory: 34 loops across 6 files - Pattern P5b design: Complete - Test fixture: Created - Capability taxonomy: Extended - Phase 91 Step 2: NEXT (Implementation) - detect_escape_pattern() in Canonicalizer - Unit tests + parity verification - No lowering in Step 2 (deferred to Step 3) ## Key Findings - Current JoinIR readiness: 47% (16/30 loops) - Pattern P5b unlocks: All escape sequence parsers - Effort estimate: 2-3 days for recognition phase ## Next Priority Phase 91 Step 2: Implement Canonicalizer recognition for P5b pattern 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-16 14:22:55 +09:00
### P1: JoinIR / Selfhost depth-2 の前進（Phase 91 - 設計完了）
docs(phase131): SSOT整備 - VM入口/env var/次の入口を1箇所に固定 Phase 131 SSOT 整備完了: 1) VM Box 解決の入口SSOT（phase131-2-box-resolution-map.md） - 📍 入口3行を先頭に追記（handle_new_box/UnifiedRegistry/BoxFactoryRegistry） - NYASH_VM_FAST を bench/profile-only 特例と明記 2) 環境変数のSSOTを1箇所へ（environment-variables.md） - ## LLVM Build Pipeline セクション新設（14変数） - phase87 の Environment Variables セクションを参照リンクに置き換え - 重複表を削除、SSOTドキュメントへの導線確立 3) 次の開発の入口を明確化（CURRENT_TASK.md） - P1（Loop Canonicalizer）: 🔶 設計待ち（外部検討中） - P2（JoinIR / Selfhost depth-2）: ✅ 実装可能 - 次に触るSSOTを1行で指定: - Loop系: joinir-architecture-overview.md - VM Box系: phase131-2-box-resolution-map.md Impact: - 迷子防止: 各領域のSSOTが1行で分かる - 重複削減: env var 表を environment-variables.md に集約 - 状態明確化: P1/P2 の「設計待ち/実装可能」が一目瞭然 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:27:39 +09:00
docs: Update CURRENT_TASK.md - Phase 91 planning complete ## P1 Status Update - Phase 91 Step 1: ✅ COMPLETE - Loop inventory: 34 loops across 6 files - Pattern P5b design: Complete - Test fixture: Created - Capability taxonomy: Extended - Phase 91 Step 2: NEXT (Implementation) - detect_escape_pattern() in Canonicalizer - Unit tests + parity verification - No lowering in Step 2 (deferred to Step 3) ## Key Findings - Current JoinIR readiness: 47% (16/30 loops) - Pattern P5b unlocks: All escape sequence parsers - Effort estimate: 2-3 days for recognition phase ## Next Priority Phase 91 Step 2: Implement Canonicalizer recognition for P5b pattern 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-16 14:22:55 +09:00
**状態**: ✅ **Phase 91 計画完了** → 次は実装フェーズ
docs(current): mark Phase 77 done, queue Phase 78
2025-12-13 06:14:00 +09:00
docs: Update CURRENT_TASK.md - Phase 91 planning complete ## P1 Status Update - Phase 91 Step 1: ✅ COMPLETE - Loop inventory: 34 loops across 6 files - Pattern P5b design: Complete - Test fixture: Created - Capability taxonomy: Extended - Phase 91 Step 2: NEXT (Implementation) - detect_escape_pattern() in Canonicalizer - Unit tests + parity verification - No lowering in Step 2 (deferred to Step 3) ## Key Findings - Current JoinIR readiness: 47% (16/30 loops) - Pattern P5b unlocks: All escape sequence parsers - Effort estimate: 2-3 days for recognition phase ## Next Priority Phase 91 Step 2: Implement Canonicalizer recognition for P5b pattern 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-16 14:22:55 +09:00
**目的**: Selfhost コンパイラの未対応ループを JoinIR 対象に拡大
**成果（Phase 91 Step 1）**:
- ✅ ループ在庫分析: 34ループ across 6ファイル（47% JoinIR対応）
- ✅ Pattern P5b (Escape Handling) デザイン完成
- ✅ テストフィクスチャ作成 (`test_pattern5b_escape_minimal.hako`)
- ✅ Capability 拡張（P5b専用タグ）
**優先順位**:
1. **P5b (Escape Handling)** - `json_loader.hako:30` (8行)
- Effort: 2-3日
- Impact: JSON/CSV パーサー全般を JoinIR 対応可能に
- Status: 設計完了、実装待ち
2. **P5 (Guard-Bounded)** - `mini_vm_core.hako:541` (204行)
- Effort: 1-2週
- Impact: 大規模ループ最適化（guard counter除去）
- Status: 分析完了、設計待ち
3. **P6 (Nested Loops)** - `seam_inspector.hako:76` (7+ levels)
- Effort: 2-3週
- Impact: 深い入れ子対応（将来）
- Status: 候補識別完了
docs(current): mark Phase 77 done, queue Phase 78
2025-12-13 06:14:00 +09:00
docs(phase131): SSOT整備 - VM入口/env var/次の入口を1箇所に固定 Phase 131 SSOT 整備完了: 1) VM Box 解決の入口SSOT（phase131-2-box-resolution-map.md） - 📍 入口3行を先頭に追記（handle_new_box/UnifiedRegistry/BoxFactoryRegistry） - NYASH_VM_FAST を bench/profile-only 特例と明記 2) 環境変数のSSOTを1箇所へ（environment-variables.md） - ## LLVM Build Pipeline セクション新設（14変数） - phase87 の Environment Variables セクションを参照リンクに置き換え - 重複表を削除、SSOTドキュメントへの導線確立 3) 次の開発の入口を明確化（CURRENT_TASK.md） - P1（Loop Canonicalizer）: 🔶 設計待ち（外部検討中） - P2（JoinIR / Selfhost depth-2）: ✅ 実装可能 - 次に触るSSOTを1行で指定: - Loop系: joinir-architecture-overview.md - VM Box系: phase131-2-box-resolution-map.md Impact: - 迷子防止: 各領域のSSOTが1行で分かる - 重複削減: env var 表を environment-variables.md に集約 - 状態明確化: P1/P2 の「設計待ち/実装可能」が一目瞭然 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:27:39 +09:00
**次に触るSSOT**:
docs: Update CURRENT_TASK.md - Phase 91 planning complete ## P1 Status Update - Phase 91 Step 1: ✅ COMPLETE - Loop inventory: 34 loops across 6 files - Pattern P5b design: Complete - Test fixture: Created - Capability taxonomy: Extended - Phase 91 Step 2: NEXT (Implementation) - detect_escape_pattern() in Canonicalizer - Unit tests + parity verification - No lowering in Step 2 (deferred to Step 3) ## Key Findings - Current JoinIR readiness: 47% (16/30 loops) - Pattern P5b unlocks: All escape sequence parsers - Effort estimate: 2-3 days for recognition phase ## Next Priority Phase 91 Step 2: Implement Canonicalizer recognition for P5b pattern 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-16 14:22:55 +09:00
- Phase 91 詳細計画: `docs/development/current/main/phases/phase-91/README.md`
- P5b デザイン: `docs/development/current/main/design/pattern-p5b-escape-design.md`
- Loop Canonicalizer: `docs/development/current/main/design/loop-canonicalizer.md`
docs(phase131): SSOT整備 - VM入口/env var/次の入口を1箇所に固定 Phase 131 SSOT 整備完了: 1) VM Box 解決の入口SSOT（phase131-2-box-resolution-map.md） - 📍 入口3行を先頭に追記（handle_new_box/UnifiedRegistry/BoxFactoryRegistry） - NYASH_VM_FAST を bench/profile-only 特例と明記 2) 環境変数のSSOTを1箇所へ（environment-variables.md） - ## LLVM Build Pipeline セクション新設（14変数） - phase87 の Environment Variables セクションを参照リンクに置き換え - 重複表を削除、SSOTドキュメントへの導線確立 3) 次の開発の入口を明確化（CURRENT_TASK.md） - P1（Loop Canonicalizer）: 🔶 設計待ち（外部検討中） - P2（JoinIR / Selfhost depth-2）: ✅ 実装可能 - 次に触るSSOTを1行で指定: - Loop系: joinir-architecture-overview.md - VM Box系: phase131-2-box-resolution-map.md Impact: - 迷子防止: 各領域のSSOTが1行で分かる - 重複削減: env var 表を environment-variables.md に集約 - 状態明確化: P1/P2 の「設計待ち/実装可能」が一目瞭然 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:27:39 +09:00
docs: Update CURRENT_TASK.md - Phase 91 planning complete ## P1 Status Update - Phase 91 Step 1: ✅ COMPLETE - Loop inventory: 34 loops across 6 files - Pattern P5b design: Complete - Test fixture: Created - Capability taxonomy: Extended - Phase 91 Step 2: NEXT (Implementation) - detect_escape_pattern() in Canonicalizer - Unit tests + parity verification - No lowering in Step 2 (deferred to Step 3) ## Key Findings - Current JoinIR readiness: 47% (16/30 loops) - Pattern P5b unlocks: All escape sequence parsers - Effort estimate: 2-3 days for recognition phase ## Next Priority Phase 91 Step 2: Implement Canonicalizer recognition for P5b pattern 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-16 14:22:55 +09:00
**Phase 91 Step 2 (次)**: Canonicalizer 実装
1. `detect_escape_pattern()` 関数追加
2. Unit tests (P5b 認識)
3. Parity verification (strict mode)
4. Documentation 更新
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
受け入れ基準:
docs: Update CURRENT_TASK.md - Phase 91 planning complete ## P1 Status Update - Phase 91 Step 1: ✅ COMPLETE - Loop inventory: 34 loops across 6 files - Pattern P5b design: Complete - Test fixture: Created - Capability taxonomy: Extended - Phase 91 Step 2: NEXT (Implementation) - detect_escape_pattern() in Canonicalizer - Unit tests + parity verification - No lowering in Step 2 (deferred to Step 3) ## Key Findings - Current JoinIR readiness: 47% (16/30 loops) - Pattern P5b unlocks: All escape sequence parsers - Effort estimate: 2-3 days for recognition phase ## Next Priority Phase 91 Step 2: Implement Canonicalizer recognition for P5b pattern 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-16 14:22:55 +09:00
- ✅ P5b パターン認識で `decision.chosen == Pattern5bEscape`
- ✅ `missing_caps == []`（すべての capability 充足）
- ✅ `HAKO_JOINIR_STRICT=1` で parity green
- ✅ 既存テスト退行なし
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: add loop canonicalizer SSOT + MirBuilder entrypoint
2025-12-16 04:37:47 +09:00
### P2: Ownership/Relay runtime 対応の再開（Phase 92 候補）
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(phase131): LLVM SSOT強化 + ConsoleBox調査完了 + Phase86-90要約 Phase 131-1 完了: LLVM exe line SSOT 強化 - phase87-selfhost-llvm-exe-line.md に 4セクション追加（+300行） - 環境変数リファレンス（14変数） - 成功/失敗基準（exit code 0/1/2/3） - コンパイラモード説明（harness vs crate） - デバッグセクション拡張 - "1コマンドで再現" 可能な状態を確立 Phase 131-2 完了: ConsoleBox 問題調査 - VM の 3重登録経路を特定（BoxFactoryRegistry/UnifiedRegistry/Builtin） - LLVM backend は Phase 133 で解決済み - 3つのドキュメント作成: - phase131-2-consolebox-investigation.md（詳細調査） - phase131-2-summary.md（エグゼクティブサマリ） - phase131-2-box-resolution-map.md（Box 解決マップ） Phase 86-90 完了: Loop frontends 要約 - phase86-90-loop-frontends-summary.md 追加 - Pattern4/ContinueReturn/ParseStringComposite の経緯を1枚に集約 - INDEX から導線追加 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:24:31 +09:00
### Done: Phase 86–90（Loop frontends）
docs(joinir): Phase 86 SSOT 追記完了 + Phase 88 準備 Phase 86 SSOT 追記（P0 完了）: - 10-Now.md: carrier_init_builder / error_tags 確立を追記 - CURRENT_TASK.md: P0→P1 繰り上げ、Done 節追加 Phase 88 準備: - nyash_kernel/lib.rs: AOT 実行器で Ring0Context 初期化 - nyash.toml: プラグインパス正規化（plugins/...） - auto_detect.conf: integration タイムアウト 120秒に延長 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 00:05:16 +09:00
docs(phase131): LLVM SSOT強化 + ConsoleBox調査完了 + Phase86-90要約 Phase 131-1 完了: LLVM exe line SSOT 強化 - phase87-selfhost-llvm-exe-line.md に 4セクション追加（+300行） - 環境変数リファレンス（14変数） - 成功/失敗基準（exit code 0/1/2/3） - コンパイラモード説明（harness vs crate） - デバッグセクション拡張 - "1コマンドで再現" 可能な状態を確立 Phase 131-2 完了: ConsoleBox 問題調査 - VM の 3重登録経路を特定（BoxFactoryRegistry/UnifiedRegistry/Builtin） - LLVM backend は Phase 133 で解決済み - 3つのドキュメント作成: - phase131-2-consolebox-investigation.md（詳細調査） - phase131-2-summary.md（エグゼクティブサマリ） - phase131-2-box-resolution-map.md（Box 解決マップ） Phase 86-90 完了: Loop frontends 要約 - phase86-90-loop-frontends-summary.md 追加 - Pattern4/ContinueReturn/ParseStringComposite の経緯を1枚に集約 - INDEX から導線追加 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 05:24:31 +09:00
- まとめ（SSOT）: `docs/development/current/main/phase86-90-loop-frontends-summary.md`
docs: add loop canonicalizer SSOT + MirBuilder entrypoint
2025-12-16 04:37:47 +09:00
- MirBuilder の入口（Context 分割）: `src/mir/builder/README.md` + `docs/development/current/main/01-JoinIR-Selfhost-INDEX.md`
docs(joinir): Phase 86 SSOT 追記完了 + Phase 88 準備 Phase 86 SSOT 追記（P0 完了）: - 10-Now.md: carrier_init_builder / error_tags 確立を追記 - CURRENT_TASK.md: P0→P1 繰り上げ、Done 節追加 Phase 88 準備: - nyash_kernel/lib.rs: AOT 実行器で Ring0Context 初期化 - nyash.toml: プラグインパス正規化（plugins/...） - auto_detect.conf: integration タイムアウト 120秒に延長 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-14 00:05:16 +09:00
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`
Reference in New Issue Copy Permalink