# Current Task — Phase 21.8 / 25 / 25.1 / 25.2 Snapshot（2025-11-18 時点） > このファイルは「今どこまで終わっていて、次に何をやるか」を 1000 行以内でざっくり把握するためのスナップショットだよ。 > 詳細な履歴やログは `git log CURRENT_TASK.md` からいつでも参照できるようにしておくね。 --- ## 0. 現在地ざっくり - フェーズ軸: - **21.8**: Numeric Core / Core-15 まわりの安定化（既に日常的には安定運用）。 - **25.x**: Stage0/Stage1/Stage‑B / Selfhost ラインのブートストラップと LoopForm v2 / LoopSSA v2 まわりの整備。 - **25.1 系**: Stage‑B / Stage‑1 / selfhost 向けに、Rust MIR / LoopForm v2 / LoopSSA v2 を段階的に整える長期ライン。 - Rust 側: - LoopForm v2 + ControlForm + Conservative PHI は、代表テスト（Stage‑1 UsingResolver / Stage‑B 最小ループ）ではほぼ安定。 - 静的メソッド呼び出し規約と `continue` 絡みの PHI は 25.1m までで根治済み。 - .hako 側: - Stage‑B コンパイラ本体 / LoopSSA v2 / BreakFinderBox / PhiInjectorBox はまだ部分実装。 - JSON v0 / selfhost ルートは Rust 側の LoopForm v2 規約に追いつかせる必要がある。 --- ## 1. 最近完了した重要タスク ### 1-1. Phase 25.1m — Static Method / LoopForm v2 continue + PHI Fix（完了） **目的** - 静的メソッド呼び出し時の「暗黙レシーバ＋引数ずれ」バグと、LoopForm v2 経路における `continue` + header PHI の欠落を根本から直す。 **Rust 側（静的メソッド / 暗黙レシーバ / JSON v0 Bridge）** - `src/mir/function.rs::MirFunction::new` - 暗黙 receiver 判定を是正し、**「第 1 パラメータが Box 型の関数だけ」をインスタンスメソッド with receiver** とみなす。 - 非 Box 型（`String`, `Integer` など）で始まるパラメータ列の関数は、暗黙レシーバなしの静的メソッド / Global 関数として扱うように変更。 - その結果: - `static box TraceTest { method log(label) { ... } }` に対して `TraceTest.log("HELLO")` を呼ぶと、 `label` に `"HELLO"` が正しく入る（以前は `label = null` になっていた）。 - `src/mir/builder/decls.rs::build_static_main_box` - `Main.main(args)` を「静的エントリ関数」に lower する経路を **`NYASH_BUILD_STATIC_MAIN_ENTRY=1` のときだけ有効** にし、 通常の VM 実行では wrapper `main()` を正規エントリとして扱うように整理。 - これにより、「`Main.main(args)` 版ではループが 1 度も回らず `return 0` で終わる」バグを解消。 - JSON v0 Bridge 経由の Box メソッド（Stage‑1/Stage‑B defs）: - `src/runner/json_v0_bridge/lowering.rs` で `prog.defs` の降下ロジックを調整し、 - `box_name != "Main"` の関数定義をインスタンスメソッドとして扱って `signature.params` に「暗黙 `me` + 明示パラメータ」を載せる。 - `func_var_map` に `me` → `func.params[0]` を事前バインドし、残りのパラメータ名を `params[1..]` に対応づける。 - これにより、`Stage1UsingResolverFull._build_module_map()` のように JSON では `params: []` でも Hako 側で `me._push_module_entry(...)` を使う関数について、 Rust VM 実行時に `me` が未定義（ValueId(0)）になるケースを構造的に防止。 **LoopForm v2（continue + header PHI）** - `src/mir/phi_core/loopform_builder.rs::LoopFormBuilder::seal_phis` - シグネチャを `seal_phis(ops, latch_id)` → `seal_phis(ops, latch_id, &continue_snapshots)` に拡張。 - preheader と latch に加え、`LoopBuilder` 側で記録している **`continue_snapshots` からの値も header PHI の入力** として統合。 - pinned / carrier いずれも、header の全 predecessor: - `(preheader, preheader_copy)` - `(continue_bb, value_at_continue)` - `(latch, value_at_latch)` を入力として持つようになり、balanced scan など「continue を含むループ」の SSA が正しく構成される。 - `src/mir/loop_builder.rs::build_loop_with_loopform` - `let continue_snaps = self.continue_snapshots.clone();` - `loopform.seal_phis(self, actual_latch_id, &continue_snaps)?;` - という形で、LoopBuilder → LoopForm 側に `continue` スナップショットを橋渡し。 **ControlForm / LoopShape invariant** - `src/mir/control_form.rs::LoopShape::debug_validate`（debug ビルドのみ） - 既存の: - `preheader -> header` エッジ必須 - `latch -> header` バックエッジ必須 - に加えて、次の invariant を追加: - `continue_targets` の各ブロックから `header` へのエッジが存在すること。 - `break_targets` の各ブロックから `exit` へのエッジが存在すること。 - これにより、LoopForm / LoopBuilder が `continue` / `break` 経路を誤配線した場合に、構造レベルで早期検知できる。 **テスト / 検証** - MIR ユニットテスト: - `src/mir/phi_core/loopform_builder.rs::tests::test_seal_phis_includes_continue_snapshots` - LoopFormBuilder 単体で「preheader + continue + latch」が PHI 入力に含まれることを固定。 - `src/tests/mir_stageb_loop_break_continue_verifies` - Stage‑B 風の `loop + break/continue` パターンで MirVerifier 緑。 - `src/tests/mir_stage1_using_resolver_verify.rs::mir_stage1_using_resolver_full_collect_entries_verifies` - LoopForm v2/PHI v2 経路（現在は既定実装）で Stage‑1 UsingResolver フル版が MirVerifier 緑。 - 実行観測: - 開発用 Hako `loop_continue_fixed.hako`: - 期待 `RC=3` / 実測 `RC=3`、PHI pred mismatch なし。 - Stage‑B balanced scan: - `StageBBodyExtractorBox` のバランススキャンループに trace を入れて 228 回イテレーションが回ること、 `ch == "{"` ブランチで `depth` / `i` を更新 → `continue` → 次イテレーションに **確実に戻っている** ことを確認。 --- ### 1-2. Phase 25.1k — LoopSSA v2 (.hako) & Stage‑B harness 追従（Rust 側はおおむね完了） **目的** - Rust 側の LoopForm v2 / ControlForm / Conservative PHI を SSOT としつつ、Stage‑B / selfhost で使っている `.hako` 側 LoopSSA/BreakFinderBox/PhiInjectorBox をその規約に追従させる準備フェーズ。 **Rust 側でやったこと（サマリ）** - Receiver / pinning: - `CallMaterializerBox::materialize_receiver_in_callee` を事実上 no-op にし、 receiver の pinning / LocalSSA 連携を `receiver::finalize_method_receiver` に一本化。 - `MirBuilder` に `pin_slot_names: HashMap` を持たせ、 `LocalSSA.ensure` が「同じ slot にぶらさがる最新の ValueId」へ自動でリダイレクトできるようにした。 - Compiler Box の分類: - `CalleeResolverBox::classify_box_kind` に `BreakFinderBox` / `PhiInjectorBox` / `LoopSSA` を追加し、 Stage‑1/Stage‑B 用 LoopSSA 箱を `CalleeBoxKind::StaticCompiler` として明示。 **IfForm / empty else-branch の SSA fix（Stage‑1 UsingResolverFull 対応）** - `src/mir/builder/if_form.rs`: - `if cond { then }`（else なし）のパターンで、 - else-entry 用に pre_if の `variable_map` から PHI ノードを生成したあと、 - その PHI 適用後の `variable_map` を `else_var_map_end_opt=Some(...)` として merge フェーズに渡すように修正。 - 以前は empty else の場合に `else_var_map_end_opt` が `None` になっており、 `merge_modified_vars` が pre_if の古い ValueId にフォールバックして、 merge ブロックで未定義の `%0` などを参照するケースがあった（`Stage1UsingResolverFull.main/0` の UndefinedValue）。 - 修正後は then/else 両ブランチで「PHI 適用後の variable_map」が merge に渡されるため、 empty else でも header/merge の SSA が崩れない。 - 検証: - `src/tests/mir_stage1_using_resolver_verify.rs::mir_stage1_using_resolver_full_collect_entries_verifies` が `MirVerifier` 緑になり、`Stage1UsingResolverFull.main/0()` の merge ブロックで PHI 後の値（例: `%24`）を正しく参照していることを MIR dump で確認済み。 **.hako 側の今後（25.1k 後半）** - `LoopSSA.stabilize_merges(json)` を Rust LoopForm v2 の Carrier/Pinned 規約に合わせて実装する（現在はほぼ stub）。 - Stage‑B Test2（`tools/test_stageb_min.sh`）で得られる Program(JSON v0) に対し、 - Rust 側で `NYASH_VM_VERIFY_MIR=1` を立てた実行結果と、 - `.hako` 側 LoopSSA v2 適用後の JSON → Rust 実行結果 を比較し、BreakFinderBox / PhiInjectorBox / LoopSSA の責務を切り分けていく。 --- ### 1-3. Phase 25.1e/f/g — LoopForm PHI v2 / ControlForm 統合（サマリ） - 25.1e（LoopForm PHI v2 migration）: - Local SSA（`local a = ...`）の ValueId 分離を完了し、LoopForm v2 を「PHI/SSA の正」とする方向へ寄せた。 - Stage‑1 UsingResolver / 基本的な Stage‑B ループは、LoopForm v2 経路で MirVerifier 緑。 - 25.1f（ControlForm 層の導入）: - `ControlForm` / `LoopShape` / `IfShape` を導入し、Loop / If を共通ビューとして扱う箱を定義。 - ここでは挙動を変えず、「構造だけを先に固定」する方針で設計を固めた。 - 25.1g（Conservative PHI ↔ ControlForm ブリッジ）: - `phi_core::loopform_builder::build_exit_phis_for_control` など、ControlForm から Conservative PHI を呼び出す薄いラッパを追加。 - 既存の PHI ロジックはそのままに、将来の置き換えポイントだけを明示している。 --- ## 2. まだ残っている問題・課題（2025-11-18 時点） ### 2-1. Stage‑B 本体の型エラー（`String > Integer(13)`） - 症状: - Stage‑B の `Main.main` 実行時に、 `Type error: unsupported compare Gt on String(...) and Integer(13)` が発生。 - LoopForm v2 / PHI / continue 修正とは **独立の Stage‑B 固有のロジック問題**。 - 想定される原因: - Stage‑B 側の body 構築 / JSON 生成で、本来数値比較にすべき箇所で「生の文字列」と整数を比較している。 - もしくは、Parser/Scanner が `len` やインデックスを文字列のまま扱っている部分がある。 - 対応方針（次フェーズ向けメモ）: - `StageBBodyExtractorBox.build_body_src` が吐く `body_src` を最小ケースで抽出し、 その中から問題の比較式（`>`）がどのように生成されているかを特定する。 - Stage‑B の box レベルで: - 「どのフェーズで型を決めるか」（例: ParserBox / Stage‑B / VM 手前）を決めてから修正する。 - このタスクは 25.1c 続き or 新フェーズ（25.1n 相当）として、Stage‑B 箱の設計側で扱う。 --- ### 2-2. Stage‑B 再入ガード `env.set/2` の扱い - 現状: - 一部 Stage‑B コードが `env.set/2` を使った再入ガードに依存しており、 Rust VM 側には `env.set/2` extern が定義されていないため、 `❌ VM error: Invalid instruction: extern function: Unknown: env.set/2` が発生するケースがある。 - 方針メモ: - 選択肢 A: Stage‑B 再入ガードを Box 内 state（フィールド）に寄せて、`env.set/2` 依存をなくす。 - 選択肢 B: Stage‑B ハーネス専用に、最小限の `env.set/2` extern を Rust 側に実装する（本番経路では使わない）。 - 25.1m では構造修正（Loop/PHI/receiver）を優先し、この extern の話は据え置き。 --- ### 2-3. .hako 側 LoopSSA v2（Rust LoopForm v2 との乖離） - 現状: - `lang/src/compiler/builder/ssa/loopssa.hako` の `stabilize_merges()` はまだ実質的に stub に近い。 - Stage‑B Test2（`compiler_stageb.hako` 経由）では、Rust MIR 側で LoopForm v2 / PHI v2 が安定した後も、 `.hako` 側 LoopSSA 経由の JSON から生成した MIR で PHI/SSA 問題が残る可能性がある。 - 目標: - Rust LoopForm v2 を「制御構造と PHI の SSOT」とみなし、 `.hako` 側 LoopSSA が同じ Carrier/Pinned / preheader/header/exit の規約を JSON レベルで再現する。 - やること（フェーズ 25.1k 後半〜 25.1f/g 連携）: - 特定の関数（例: `BreakFinderBox._find_loops/2`）を対象に、Rust 側 / .hako 側のそれぞれで生成されるループ構造を比較。 - LoopSSA v2 の中に: - Carrier 変数の検出、 - pinned 変数の扱い、 - exit PHI の構築 を Rust LoopForm v2 に合わせて実装。 - 2025-11-19 追記: - `BreakFinderBox._find_loops/2` については、まず .hako 側を「region box」的に整理した。 - `header_pos` / `header_id` / `exit_pos` / `exit_id` まわりの異常系を `continue` ではなく `next_i` ローカルへの代入で表現し、1 イテレーションの末尾で `i = next_i` に合流させる形に変更。 - これにより、LoopForm v2 / LoopSSA 側から見ると「単一 region 内での分岐＋最後に合流」という構造になり、 carrier/pinned 検出や今後の SSA 解析が行いやすくなった（挙動は従来と同じ）。 ### 2-5. static box / me セマンティクス（観測タスクへ移行） - 現状: - `static box StringHelpers` のようなユーティリティ箱で、`me.starts_with(src, i, kw)` のように 同一箱内のヘルパー（`starts_with`）を `me.` 経由で呼んでいたため、Stage‑3 降下時に引数ずれが発生していた。 - 具体的には、`StringHelpers.starts_with_kw/3` → `StringHelpers.starts_with/3` の降下で 実際の呼び出しが `starts_with("StringHelpers", src, i, kw)` のような 4 引数形になり、 `starts_with(src, i, pat)` 側では `src="StringHelpers"` / `i=<ソース全文>` となって、 `if i + m > n` が `String > Integer(13)` 比較に化けていた。 - 対応（完了済み・局所修正）: - `lang/src/shared/common/string_helpers.hako` の `starts_with_kw` を、 `if me.starts_with(src, i, kw) == 0` から `if starts_with(src, i, kw) == 0` に書き換え、 static box ユーティリティに対する `me` 依存を除去した。 - これにより、`starts_with` 内でのガード比較 `i + m > n` はすべて整数同士となり、 Stage‑B fib ケースで発生していた `String("...") > Integer(13)` の TypeError は解消済み。 - 今後（Phase 25.1p 以降）: - static box 全般における `me` セマンティクス（本当に「シングルトンインスタンス」として扱う箱と、 純粋な名前空間箱をどう区別するか）は、25.1p の DebugLog フェーズで観測しながら設計を詰める。 - 実際に Rust 層（`build_me_expression` / `lower_static_method_as_function` / `FunctionDefBuilder::is_instance_method`）を 統一規約に寄せる作業は、25.1p 以降のサブタスクとして扱う（現時点では局所修正でバグのみ解消）。 --- ### 2-4. Builder / Selfhost まわりの残タスク（超ざっくり） - Builder 内部ルート（20.43 系）: - `MirBuilderBox` 経由の internal ルートで、MIR を stdout 経由ではなく一時ファイル / FileBox に書き出し、 ハーネスがそこから読む形に揃える案が残タスク。 - Selfhost CLI / Stage1 CLI: - Stage‑B / Stage‑1 CLI を「Rust VM / LLVM / PyVM / selfhost」の 4 経路で安定確認するラインは進行中。 - 25.1m では Rust VM + Stage‑B balanced scan を優先し、CLI 全体は次のフェーズで詰める。 --- ## 3. 次にやること（候補タスク） ここから先は「どのフェーズを進めるか」をそのときの優先度で選ぶ感じだよ。 1. **Stage‑B / BreakFinder / FuncScanner ラインの SSA 根治（Phase 25.1m 続き）** - JSON v0 bridge の Loop lowering で、`backedge_to_cond` が `Jump` だけでなく `Branch(cond→header/exit)` も認識するように修正（`loop_.rs`）。 → BreakFinderBox._find_loops/2 のような break を含むループでも header PHI が正しく張られるようにした。 - BreakFinderBox は解析用の static box として扱い、`me._find_loops` / `me._jumps_to` を `BreakFinderBox._find_loops` / `_jumps_to` に正規化。 → `me` 未定義による Undefined ValueId を避ける。 - Stage‑B → Stage‑1 パーサ経路は、`ParserBox.parse_program2` のトップレベルループではなく、`parse_block2` で `Main.main` の本文をブロックとしてパースし、 Program(JSON v0) を自前で組み立てる構造に変更（Stage‑B 固まり問題を回避）。 2. **Stage‑B 再入ガード `env.set/2` の整理** - 再入ガードを Box 内 state で持つ方向か、Rust 側に dev 専用 extern を追加するかを決める。 - どちらにしても「本番経路（prod ランナー）には影響しない」ようフラグでガードする。 3. **.hako LoopSSA v2 実装（LoopForm v2 への追従）** - Rust LoopForm v2 の規約（Carrier/Pinned / preheader/header/latch/exit）を `.hako` の LoopSSA に輸入。 - Stage‑B Test2 / selfhost CLI の JSON→MIR 経路で MirVerifier 緑を目標にする。 4. **Selfhost / CLI 周辺のテスト整理** - 代表的な selfhost / Stage‑B / Stage‑1 CLI ケースに対して、 「Phase 25.1m でどこまで緑になったか」「どこから先が 25.1k 以降の仕事か」を tests / tools 側で見える化する。 --- ## 4. 履歴の見方メモ - 以前の `CURRENT_TASK.md` は ~1900 行の長いログだったけど、読みやすさ重視でこのファイルはスナップショット形式にしたよ。 - 過去の詳細ログが必要になったら: - `git log -p CURRENT_TASK.md` - あるいは特定のコミット時点の `CURRENT_TASK.md` を `git show :CURRENT_TASK.md` でいつでも復元できるよ。 --- 以上が 2025-11-18 時点の Phase 21.8 / 25 / 25.1 / 25.2 ラインの「いまどこ」「なに済み」「なに残り」だよ。 次にどの箱から攻めるか決めたら、ここに箇条書きで足していこうね。 ## 2-? Stage‑B FuncScanner / LoopSnapshotMergeBox（in progress） - StageBFuncScannerBox を `compiler_stageb.hako` 内に追加し、StageBDriverBox.main からは FuncScannerBox ではなくこちらを呼ぶ構成にしている。 - VM 側の Undefined value（BreakFinderBox._find_loops/2）は LoopForm v2 / continue + PHI 修正で解消済み。 - FuncScannerBox.scan_all_boxes/1 については、Phase 25.2 で `LoopSnapshotMergeBox` を導入し、continue/break/exit スナップショットのマージを一元化したことで 13 個の continue を含む複雑ループでも Undefined Value が出ないところまで到達した。 - LoopSnapshotMergeBox 実装: `src/mir/phi_core/loop_snapshot_merge.rs` - `merge_continue_for_header` / `merge_exit` / `optimize_same_value` / `sanitize_inputs` など、ヘッダ/exit PHI 用の入力統合ロジックを提供。 - LoopBuilder / LoopFormBuilder は、この箱を経由して continue_merge / exit PHI を構成するようにリファクタ済み。 - 代表テスト: - ループ系: `mir_stageb_loop_break_continue::*` / `mir_loopform_exit_phi::*` / `mir_stageb_like_args_length::*` はすべて PASS。 - 手書きループ: - 基本ループ: sum=10（0+1+2+3+4）✅ - break/continue を含むループ: sum=19, i=7 ✅ - body-local 変数を含むループ: result=6, i=3 ✅（exit PHI で body-local を正しく統合） - StageBFuncScannerBox.scan_all_boxes(src) は依然として fib サンプルに対して defs=[]（Program(JSON) に `TestBox.fib` が載っていない）という問題が残っているため、 次の担当者は StageBFuncScannerBox.scan_all_boxes/1 と FuncScannerBox.scan_all_boxes/1 の MIR を比較しつつ、 Stage‑B body 抽出 → FuncScanner → defs 注入の導線自体を見直してほしい（LoopForm/PHI/スナップショット側は LoopSnapshotMergeBox でほぼ安定化済み）。 ## 3. Static Box フィールド仕様ドキュメント（完了） - docs/reference/language/LANGUAGE_REFERENCE_2025.md: 3.4 Static Boxパターンに「static box 内のフィールドはすべて static フィールドとして扱われる」旨を明記した。 - 言語仕様としては、static box の中では `PI: FloatBox` のような宣言で十分であり、追加の `static` キーワードは不要であることをドキュメント上で固定。 - 次タスク候補（Claude Code 向け）: static box / box のフィールド挙動に関するサンプルとテスト（VM/JSON v0 両方）の整理、および static box 上の `me` セマンティクス（25.1p DebugLog フェーズと連動）の仕様化。 ## 3. Phase 25.1q — LoopForm Front Unification（DONE / follow-up 別タスクへ） - 目的: Rust AST ルート (LoopBuilder) と JSON v0 ルート (`json_v0_bridge::lower_loop_stmt`) のループ lowering を “LoopFormBuilder + LoopSnapshotMergeBox” に一本化し、どの経路からでも同じ SSOT を見るだけで良い構造に揃える。 - 完了状態: - AST ルート: - `LoopBuilder::build_loop_with_loopform` で canonical `continue_merge_bb` を常時生成し、`continue_target` を header ではなく `continue_merge_bb` に統一済み。 - `LoopFormBuilder::seal_phis` / `LoopSnapshotMergeBox` の continue/exit 入力は「preheader + continue_merge + latch」「header + break snapshots」で完全管理。 - JSON v0 ルート: - `loop_.rs` で `LoopFormJsonOps` を実装し、preheader/header/body/latch/continue_merge/exit の block ID を AST ルートと同じ形で生成。 - break/continue/exit の snapshot を `LoopSnapshotMergeBox` でマージし、canonical continue_merge → header backedge を JSON 側でも採用。 - `tests/json_program_loop.rs` で JSON v0 だけを入力にした軽量ループ（通常 / continue / body-local exit）を `MirVerifier` で確認するスモークを追加。 - Docs/README: - `docs/development/roadmap/phases/phase-25.1q/README.md` に「AST/JSON ともに LoopForm v2 + LoopSnapshotMergeBox が SSOT」と明記。 - `src/runner/json_v0_bridge/README.md` で “bridge は薄いアダプタであり、新しい PHI 仕様は loopform 側でのみ扱う” とガードを追記。 - `src/mir/phi_core/loop_phi.rs` には “legacy（分析用のみ）” コメントを追加。将来の cleanup (Phase 31.x) で削除対象とする。 - 残タスクは別フェーズへ: - Stage‑1 UsingResolver 周りの SSA バグ（`tests::mir_stage1_using_resolver_verify::mir_stage1_using_resolver_full_collect_entries_verifies` の Undefined Value）は 25.1q の範囲外。LoopForm の SSOT 化は終わっているため、今後は Stage‑1 側の PHI/Env スナップショット設計タスクとして切り出す。 - JSON v0 → Nyash AST への統合案や loop_phi.rs の実ファイル削除は、Phase 31.x cleanup 計画側で扱う。