c85d67c92e
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>
23 lines
1.3 KiB
Markdown
23 lines
1.3 KiB
Markdown
## ResultBox Migration TODO (Phase 9.78h follow-up)
|
||
|
||
> **Status**: Legacy TODO（状態スナップショット）
|
||
> **Note**: 実際の移行状況・今後の計画は `RESULTBOX` 関連のコードとロードマップ側を正とし、このメモは Phase 9.78h 時点のタスク列挙の記録としてのみ保持しています。
|
||
|
||
Goal: fully migrate from legacy `box_trait::ResultBox` to `boxes::result::NyashResultBox` (aka `boxes::ResultBox`).
|
||
|
||
### Current usages (grep snapshot)
|
||
- src/backend/vm.rs
|
||
- Handles both new `NyashResultBox` and legacy `box_trait::ResultBox` for `.is_ok/.get_value/.get_error` (deprecation suppressed)。
|
||
|
||
### Proposed steps (small, incremental)
|
||
- Step 1: Keep dual handling but gate legacy path with feature flag or cfg for deprecation-only builds（任意）。
|
||
- Step 2: Audit call sites that construct legacy ResultBox; replace with `boxes::result::NyashResultBox` constructors。
|
||
- Step 3: Remove legacy path from VM once no legacy constructors remain。
|
||
- Step 4: Delete/Archive legacy `box_trait::ResultBox`（テスト緑後）。
|
||
|
||
### Notes
|
||
- New API already aliased: `pub type ResultBox = NyashResultBox;` so external references may transparently resolve after migration。
|
||
- Keep migration scoped: do not mix with unrelated refactors。
|
||
|
||
Last updated: 2025-08-25
|