**箱理論による問題解決**: - ❌ 問題: LoopVarClassBox(ループスコープ分析)とif-merge処理が混在 - ✅ 解決: if-merge専用箱を新設して責務分離 **新箱: IfBodyLocalMergeBox**: - 責務: if-merge専用のbody-local φ候補決定 - ロジック: - 両腕に存在する変数を検出 - pre_ifと比較して値が変わった変数のみ - empty elseは空リスト返す - 特徴: LocalScopeInspector不要、LoopVarClassBox不使用 **変更ファイル**: - src/mir/phi_core/if_body_local_merge.rs: 新規作成(IfBodyLocalMergeBox) - src/mir/phi_core/phi_builder_box.rs: IfBodyLocalMergeBox使用に切り替え - src/mir/phi_core/body_local_phi_builder.rs: filter_if_merge_candidates()削除 - src/mir/loop_builder.rs: BodyLocalPhiBuilder setup削除 - src/mir/phi_core/mod.rs: if_body_local_merge追加 **テスト結果**: - Passed: 353→354 (+1) ✅ - Failed: 14→14 (退行なし) **既知の問題**: - domination error依然残存(%48 in bb48 from bb52) - 次フェーズで調査・修正予定 技術詳細: - ChatGPT箱理論分析による設計 - A案ベースのシンプル実装 - 責務明確化: ループスコープ分析 vs if-merge専用処理
Phase 25.1n — MirBuilder Self‑Host 移植ライン(Rust SSOT → .hako 実装)
Status: planning(設計フェーズ。実装は 25.2 系と並行で段階移行)
ゴール
- Rust 側で固めた SSA/PHI SSOT(LoopForm v2 / IfForm / BodyLocal / PhiBuilderBox) を、
.hako側のMirBuilderBox/LoopFormBox/PhiBuilderBoxに「構造そのまま」移植できるようにするフェーズだよ。 - このフェーズでは:
- Rust
MirBuilderを 唯一のオラクル として扱い、 - その挙動を「表(ケース表+制御構造の形)」と「テスト」で固定する。
.hako側はその表とテストを見ながら、同じ SSA/PHI を組み立てる実装に寄せていく。
- Rust
- 25.1/26‑E まででやってきた LoopForm v2 / ExitPhiBuilder / BodyLocalPhiBuilder / IfForm / PhiBuilderBox の成果を、 Self‑Host 実装に届けるための「橋渡しフェーズ」だよ。
スコープ(25.1n でやること)
N-0: PHI まわりの箱とガードの現状メモ(2025-?? 時点)
- PHI を建てる箱 (SSOT):
PhiBuilderBox- If 形:
get_conservative_if_valuesで PhiInvariantsBox による不変チェックを通すようにした(None/None フォールバックは撤去)。 - Exit 形:
ExitPhiBuilder::build_exit_phisでも PhiInvariantsBox を呼び、pred で未定義な値があれば fail-fast。 - これにより「欠損 incoming で偶然成功する」経路は塞いだよ。
- If 形:
- 不変条件をチェックする箱:
PhiInvariantsBox(新設)- 役目: 「merge に必要な値が全 pred に存在するか」をチェックして early error。
- 適用済み: If, Exit。未着手: Header PHI / ループ body PHI / observe::ssa での観測ガード。
- 解析ヘルパの箱化計画:
if_phi.rsにあるextract_assigned_var / collect_assigned_vars / infer_type_from_phiは
将来IfAnalysisBoxのような解析専用箱へ移動する予定(まだ実装はしないが、移行先をここで宣言しておく)。
N‑A: SSA/PHI SSOT の「表」化(Rust 側設計をテーブルに落とす)
- ファイル候補:
docs/development/architecture/loops/loopform_ssot.md(既存の A/B/C/D ケース表を拡張)docs/development/architecture/ssa/phi_cases_stage1.md(新規)
- やること:
- すでに存在する LoopForm ケース表(Case A/B/C/D)に対して、
LoopVarClass(Pinned / Carrier / BodyLocalExit / BodyLocalInternal)×- LoopCase (A/B/C/D) ×
- place(header / exit / body‑if‑merge) を軸に「どこに PHI を張るか」を表にする。
- If についても:
then/elseの到達可否(break/continue/early‑return)と、- 変数のクラス(Pinned/Carrier/BodyLocal) から、「PHI / direct bind / pre 値そのまま」の 3パターンを表で決める。
- これらを Rust コードに依存しない形で書き下し、
- 「Rust 実装はこの表を実現しているだけ」という関係にする(SSOT = docs + テスト)。
- すでに存在する LoopForm ケース表(Case A/B/C/D)に対して、
N‑B: Rust MirBuilder オラクルテストの整備
- ファイル候補:
src/tests/mir_loopform_conditional_reassign.rssrc/tests/mir_stage1_using_resolver_verify.rssrc/tests/mir_stage1_cli_emit_program_min.rs
- やること:
- 代表的な構造(LoopCase A〜D / Stage‑1 UsingResolver / Stage‑B fib/defs)について、
.hako入力 → RustMirCompiler→MirVerifierの結果を MIR テキストとして固定するテスト(golden テストに近い)を 1〜2 本ずつ用意する。
- これらのテストは「Rust MirBuilder の挙動を凍結する」役割のみを持ち、
.hako側実装が追いつくまでは「期待値 = Rust 実装」の位置付けにする。
- 将来は、
.hako実装の MIR と diff を取る比較テストに発展させる(本フェーズでは準備だけ)。
- 代表的な構造(LoopCase A〜D / Stage‑1 UsingResolver / Stage‑B fib/defs)について、
N‑C: .hako MirBuilderBox への API 設計(移植用インターフェース定義)
- ファイル候補:
lang/src/compiler/mir/mir_builder_box.hako(仮)lang/src/compiler/mir/loopform_box.hako(仮)lang/src/compiler/mir/phi_builder_box.hako(仮)
- やること:
- Rust の
MirBuilder/LoopFormBuilder/PhiBuilderBoxの公開インターフェースから、.hako側で必要になる API を抜き出し、Nyash の Box としてのシグネチャだけ先に決める。
- 例:
MirBuilderBox.emit_block(fn_name, ast)→ MirModule にブロック/関数を追加。LoopFormBox.build_loop(condition, body_ast)→ LoopForm v2 構造を Nyash 側で組み立て。PhiBuilderBox.emit_if_phi(pre_snapshot, then_snapshot, else_snapshot, control_form)→ 既存表に沿って PHI を配置。
- このフェーズでは 実装はまだ書かず、I/F と責務コメント、簡単な docs のみを
.hako側に置く。
- Rust の
N‑D: Self‑Host 用ミニパイプラインの設計
- ファイル候補:
docs/development/runtime/cli-hakorune-stage1.mddocs/development/architecture/mir-selfhost-pipeline.md(新規)
- やること:
- Self‑Host MVP のパイプラインを定義する:
- Stage‑0 Rust CLI → Stage‑B (.hako) → Stage‑1 MirBuilderBox (.hako) → MIR(JSON) → VM 実行。
- MVP では:
- 1〜2 の代表ケース(fib/defs, minimal_program)だけを対象とし、
.hakoMirBuilder は Rust MirBuilder の完全互換ではなく「代表ケースに十分」な subset に留める。
- これを Phase 25.2 以降の実装フェーズのターゲットとして書き切る。
- Self‑Host MVP のパイプラインを定義する:
このフェーズで「やらない」こと
- Rust MirBuilder 実装のロジック変更:
- 25.1n はあくまで「Rust 実装の挙動を SSOT として表+テストに落とす」フェーズであり、
MirBuilder/LoopForm/IfForm/BodyLocalPhiBuilder のロジック変更は 26.x までに終わっていることを前提にする。
- 25.1n はあくまで「Rust 実装の挙動を SSOT として表+テストに落とす」フェーズであり、
.hakoMirBuilder 実装の本格実装:- ここでは Box のシグネチャと責務、テスト用の I/F だけを決める。実装は 25.2/25.2b などのフェーズで段階的に行う。
- GC や Region/RefSlotKind の統合:
- 25.1l の Region 観測レイヤーはあくまで Rust 側のみ。
.hako側 GC/寿命管理は別フェーズ(25.1m 以降)の仕事とし、MirBuilder Self‑Host とは分離する。
- 25.1l の Region 観測レイヤーはあくまで Rust 側のみ。
受け入れ条件(25.1n)
- Docs:
- LoopForm/IfForm/BodyLocal/PhiBuilder について、SSA/PHI の挙動が表形式で整理されている(Rust コードを読まずに「この形ならどの PHI が立つか」が分かる)。
- Self‑Host 用 MirBuilderBox / LoopFormBox / PhiBuilderBox の .hako 側 I/F が定義されている(未実装でも良い)。
- テスト:
- Rust MirBuilder オラクルテストが 2〜3 本(LoopForm ケース / UsingResolver / Stage‑1 CLI minimal)追加され、安定して緑になっている。
- これらのテストは「将来 .hako 実装と比較する」前提で、MIR 構造を固定する役割を持つ。
- 実装範囲:
- Rust 側の MirBuilder ロジックには手を入れていない(設計とテストの “凍結フェーズ” として完了できている)。