tomoaki/hakorune
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
f740e6542f6efa4131f47d6e0fc0871f0738d2fb
hakorune/docs/development/current/main/phases/phase-286
History
tomoaki 6b64e6415c docs(phase-286): Add complete llvm.rs modularization instructions 
Created comprehensive, self-contained instructions for modularizing
llvm.rs (449 lines → 10 boxes + orchestrator), following Phase 33
success pattern.

Contents:
- Background & current problems (12 responsibilities in 1 function)
- Phase 33 success case reference
- Detailed box design (10 boxes with responsibilities/inputs/outputs)
- Step-by-step implementation guide (staged migration)
- Acceptance criteria (build/test requirements)
- Important warnings (PyVM preservation, feature-gated code)

Box breakdown:
1. plugin_init.rs - Plugin initialization
2. using_resolver.rs - Using/prelude handling
3. mir_compiler.rs - AST → MIR compilation
4. method_id_injector.rs - method_id injection
5. joinir_experiment.rs - JoinIR experiment (feature-gated)
6. pyvm_executor.rs - PyVM harness (dev/test, MUST PRESERVE)
7. object_emitter.rs - LLVM object emit
8. harness_executor.rs - LLVM harness execution
9. exit_reporter.rs - Leak report (Phase 285LLVM-0)
10. fallback_executor.rs - Mock/legacy execution

Expected improvements:
- Code quality: 449 lines → 150-200 orchestrator + 10 focused boxes
- Testability: Each box independently testable
- Reusability: Boxes reusable across backends
- Maintainability: Single responsibility per box

CRITICAL: PyVM executor (pyvm_executor.rs) MUST be preserved
- Used by 8 JSON AST smoke tests
- NOT removable legacy code

Ready for handoff to other AI (ChatGPT, etc.) for implementation.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-24 10:08:40 +09:00
..
llvm-modularization-instructions.md
docs(phase-286): Add complete llvm.rs modularization instructions
2025-12-24 10:08:40 +09:00
P0-INSTRUCTIONS.md
feat(phase284): P1 Complete - Return in Loop with Block Remap Fix
2025-12-23 14:21:27 +09:00
README.md
feat(phase284): P1 Complete - Return in Loop with Block Remap Fix
2025-12-23 14:21:27 +09:00

README.md

Phase 286: JoinIR Line Absorption（JoinIR→CorePlan/Frag 収束）

Status: Planned (design-first)

Goal

移行期間に残っている「2本の lowering」を、構造で 1 本に収束させる。

  • Plan line（Pattern6/7）: CorePlan → Frag(compose) → emit_frag() が SSOT
  • JoinIR line（Pattern1–5,9）: JoinIR → bridge → merge が SSOT

Phase 286 では JoinIR line を “第2の lowerer” として放置せず、Plan/Frag SSOT へ吸収する道筋を固定する。

Why（なぜ今）

  • return のような「大きな出口語彙」は、責務が分散すると実装場所が揺れて事故りやすい
  • 移行期間の弱点は「同じASTでも経路により意味論が割れる可能性がある」こと
  • pattern を溶かしていく思想の最後の壁が “JoinIR line の残存” になりやすい

SSOT（Phase 286 で守る憲法）

  • SSOT=extract（Phase 282）: 検出は extract の成功でのみ決める。pattern_kind は O(1) safety valve のみ。
  • CFG/terminator SSOT（Phase 280/281）: Frag + compose::* + emit_frag() が唯一の terminator 生成点。
  • Fail-Fast: close-but-unsupported を Ok(None) で黙殺しない（silent reroute 禁止）。

Responsibility Map（どこを触るか）

  • JoinIR line の共通入口（現状）:
    • src/mir/builder/control_flow/joinir/patterns/conversion_pipeline.rs
    • src/mir/join_ir_vm_bridge/bridge.rs
    • src/mir/builder/control_flow/joinir/merge/mod.rs
  • Plan/Frag SSOT（収束先）:
    • src/mir/builder/control_flow/plan/*
    • src/mir/builder/control_flow/edgecfg/api/compose.rs
    • src/mir/builder/control_flow/edgecfg/api/emit.rs

Scope（提案）

P0（docs-only）

  • 「JoinIR line をどの粒度で吸収するか」を SSOT として決める
    • 例: JoinIR は DomainPlan 生成の補助へ降格 / JoinIR→MIR merge を段階撤去
  • “禁止事項” を明文化（pattern 側への散布、二重 SSOT の再発）

P1（investigation）

  • JoinIR line が持っている「本当は SSOT に寄せたい責務」を棚卸し
    • return/break/continue の扱い
    • exit phi / boundary の責務
    • optimizer/type propagation の入り口

P2（PoC）

  • 代表 1 パターン（例: Pattern4）を “JoinIR 生成 → CorePlan/Frag” に変換する PoC
    • 目的: merge を通さずに emit_frag() 経由で終端が生成できることの証明

Acceptance（P0）

  • 2本の lowering が “設計として” どこで 1 本に収束するかが明文化されている
  • Phase 284（Return）/ Phase 285（GC）と矛盾しない