Implements block-level unreachable code detection using MIR CFG information. Complements Phase 153's method-level HC019 with fine-grained analysis. Core Infrastructure (Complete): - CFG Extractor: Extract block reachability from MirModule - DeadBlockAnalyzerBox: HC020 rule for unreachable blocks - CLI Integration: --dead-blocks flag and rule execution - Test Cases: 4 comprehensive patterns (early return, constant false, infinite loop, break) - Smoke Test: Validation script for all test cases Implementation Details: - src/mir/cfg_extractor.rs: New module for CFG→JSON extraction - tools/hako_check/rules/rule_dead_blocks.hako: HC020 analyzer box - tools/hako_check/cli.hako: Added --dead-blocks flag and HC020 integration - apps/tests/hako_check/test_dead_blocks_*.hako: 4 test cases Architecture: - Follows Phase 153 boxed modular pattern (DeadCodeAnalyzerBox) - Optional CFG field in Analysis IR (backward compatible) - Uses MIR's built-in reachability computation - Gracefully skips if CFG unavailable Known Limitation: - CFG data bridge pending (Phase 155): analysis_consumer.hako needs MIR access - Current: DeadBlockAnalyzerBox implemented, but CFG not yet in Analysis IR - Estimated 2-3 hours to complete bridge in Phase 155 Test Coverage: - Unit tests: cfg_extractor (simple CFG, unreachable blocks) - Integration tests: 4 test cases ready (will activate with bridge) - Smoke test: tools/hako_check_deadblocks_smoke.sh Documentation: - phase154_mir_cfg_inventory.md: CFG structure investigation - phase154_implementation_summary.md: Complete implementation guide - hako_check_design.md: HC020 rule documentation Next Phase 155: - Implement CFG data bridge (extract_mir_cfg builtin) - Update analysis_consumer.hako to call bridge - Activate HC020 end-to-end testing 🤖 Generated with Claude Code (https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2.0 KiB
2.0 KiB
Parser/Bridge: Unary and ASI Alignment (Stage‑2)
Status: open (bridge/parser alignment memo)
Context
- Rust parser already parses unary minus with higher precedence (parse_unary → factor → term) but PyVM pipe path did not reflect unary when emitting MIR JSON for the PyVM harness.
- Bridge(JSON v0 path)is correct for unary by transforming to
0 - exprin the Python MVP, but Rust→PyVM path usesemit_mir_json_for_harnesswhich skippedUnaryOp. - ASI in arguments split over newlines is not yet supported in Rust (e.g., newline inside
(..., ...)after a comma in a chained call), while Bridge/Selfhost cover ASI for statements and operators.
Proposed minimal steps
-
Unary for PyVM harness:
- Option A (preferred later): extend
emit_mir_json_for_harness[_bin]to export aunopinstruction and add PyVM support. Requires schema change. - Option B (quick): legalize unary
NegtoConst(0); BinOp('-', 0, v)before emitting, by inserting a synthetic temporary. This requires value id minting in emitter to remain self‑consistent, which we currently do not have. So Option B is non‑trivial without changing emitter capabilities. - Decision: keep Bridge JSON v0 path authoritative for unary tests; avoid relying on Rust→PyVM for unary until we add a
unopschema.
- Option A (preferred later): extend
-
ASI inside call arguments (multi‑line):
- Keep as NOT SUPPORTED for Rust parser in Phase‑15. Use single‑line args in tests.
- Selfhost/Bridge side already tolerate semicolons optionally after statements; operator‑continuation is supported in Bridge MVP.
Tracking
- If we want to support unary in the PyVM harness emitter:
- Add
unopto tools/pyvm_runner.py and src/llvm_py/pyvm/vm.py (accept{op:"unop", kind:"neg", src: vid, dst: vid}) - Teach emitters to export
UnaryOpaccordingly (emit_mir_json_for_harness[_bin]).
- Add
Status
- Bridge unary: OK(ny_stage2_bridge_smoke includes unary)
- Rust→PyVM unary: not supported in emitter; will stay out of CI until schema update
- ASI in args over newline: not supported by Rust parser; keep tests single‑line for now