hakorune/CURRENT_TASK.md

Current Task

このファイルは「いま何に集中しているか」と「次にやる候補」だけを書く軽量ビューに戻すよ。
過去フェーズの詳細ログは docs/development/current/main/10-Now.md と各 phase-XX*.md に残してあるので、履歴はそちらを見てね。

---

🎯 今フォーカスしているテーマ

1. JoinIR ループ基盤 → JsonParser / Trim への適用

• 現状

  • LoopBuilder は完全削除済み。ループは JoinIR Pattern1–4（while / break / if‑PHI / continue）で統一。
  • LoopExit / ExitLine / Boundary / Header PHI のラインは代表ケース（Pattern1–4）で安定。
  • LoopConditionScopeBox（Phase 170‑D）はバグ修正済みで、
    • ループ条件に出てくる変数を LoopParam / OuterLocal / LoopBodyLocal に分類
    • 関数パラメータや外側ローカル（例: s, pos, len）は正しく OuterLocal と判定できるようになった。

• 直近の目的

  • JsonParserBox / Trim 系ループを、Pattern1–4 + LoopConditionScopeBox の上にどこまで安全に載せられるかを再観測する。
  • LoopBodyLocal を条件に含むパターン（Trim の ch など）を、Pattern5 でどう扱うか設計する。

• 次にやる候補

  • Phase 171‑A: LoopConditionScope 修正版で JsonParser / Trim ループの再インベントリ ✅ → どのループが Pattern1–4 内に入り、どれが LoopBodyLocal 条件で弾かれているかを整理。
  • Phase 171‑B: Pattern5‑A のターゲット決定 ✅ → Trim の leading whitespace ループを代表として選定。
  • Phase 171‑C-1: LoopBodyCarrierPromoter スケルトン実装 ✅ → API 定義（PromotionRequest → PromotionResult）、基本検出ロジック。
  • Phase 171‑C-2: Trim パターン昇格ロジック実装 ✅ → find_definition_in_body(), is_substring_method_call(), extract_equality_literals() 実装。 → TrimPatternInfo で検出結果を返す。10 unit tests。
  • Phase 171‑C-3: Pattern 2/4 ルーティングとの統合 ✅ → routing.rs で LoopBodyCarrierPromoter を呼び出し、昇格可能なら Pattern2 へルート。
  • Phase 171‑C-4: CarrierInfo への統合 ✅ (2025-12-07) → CarrierInfo::merge_from() で昇格後のキャリアをマージ。 → TrimPatternInfo::to_carrier_info() で変換ヘルパ実装。 → Pattern2/4 lowerer で Promoted ブランチをマージに更新。7 unit tests。
  • Phase 171‑C-5: TrimLoopHelper 設計 ✅ (2025-12-07) → TrimLoopHelper struct で Trim 専用ロジックを一箇所に集約。 → CarrierInfo::trim_helper() アクセサ追加。4 unit tests。
  • Phase 171‑impl-Trim: Trim 用 JoinIR 生成 ✅ (2025-12-08) → CarrierInfo::trim_helper() を使って bool carrier の初期化・更新・exit PHI を生成。
  • Phase 172-Trim-impl: Trim 用 MIR 生成 ✅ (2025-12-08) → Pattern2 で Trim パターンの JoinIR→MIR lowering 実装完了。 → emit_whitespace_check(), extract_substring_args() ヘルパ追加。
  • Phase 173: JsonParser P5 展開 ✅ (2025-12-08) → Task 173-1: JsonParser 代表ループの再チェック（_skip_whitespace 選定）。 → Task 173-2: 「Trim と同型」なループを 1 本選定（_skip_whitespace 確定）。 → Task 173-3: Trim 用 P5 パイプラインを JsonParser 用にも開放する設計（設計ドキュメント作成）。 → Task 173-4: 1 本だけ実際に JoinIR で通す（_skip_whitespace Pattern detection 成功）。 → Task 173-5: ドキュメント更新（phase173-jsonparser-p5-impl.md + CURRENT_TASK）。 → 成果: Trim パイプラインが JsonParser でも機能することを実証、P5 の汎用性が完全証明された。
  • Phase 200: JoinIR パイプライン Cleanup (Part 1) ✅ (2025-12-08) → Task 200-1: Pattern × Box マトリクス表をドキュメント化（loop_pattern_space.md に追加）。 → Task 200-2: JoinInlineBoundaryBuilder 導入（Pattern2 で試験導入、Builder パターンで構築統一化）。 → Task 200-3: JoinIRVerifier 追加（LoopHeader PHI / ExitLine 契約のデバッグ検証）。 → Task 200-4: CURRENT_TASK/overview 微修正（Phase 200 内容を反映）。
  • Phase 201: JoinInlineBoundaryBuilder Pattern3/4 展開 ✅ (2025-12-08) → Task 201-1: Pattern2 の Builder 使用パターンを正として固める（設計ドキュメント作成）。 → Task 201-2: Pattern3 を Builder に載せ替え（フィールド直書き排除）。 → Task 201-3: Pattern4 を Builder に載せ替え（continue/Trim 特例対応）。 → Task 201-4: 共通ルールチェック & unit test 拡張（2つの新テスト追加）。 → Task 201-5: ドキュメント更新（overview + CURRENT_TASK）。 → 成果: 全パターン（P1/P2/P3/P4）で Builder 統一完了、フィールド直書き完全排除、挙動不変（テスト全 PASS）。
  • Phase 174: JsonParser 複雑ループ P5 拡張（設計＋1本め） ✅ (2025-12-08) → Task 174-1: 残り JsonParser ループの再チェック（_parse_string/_parse_array/_parse_object 分析）。 → Task 174-2: 「次に攻める1本」を決定（_parse_string 選定、Trim に最も近い構造）。 → Task 174-3: 箱の再利用 vs 追加を決定（TrimLoopHelper 再利用可能、最小化版で検証）。 → Task 174-4: 小さな PoC を 1 本動かす（_parse_string 最小化版で P5 パイプライン成功）。 → Task 174-5: ドキュメント更新（phase174-jsonparser-p5b-design.md + CURRENT_TASK）。 → 成果: Trim P5 パイプラインが _parse_string 最小化版でも機能することを実証。 文字比較対象が "\""（終端クォート）でも Trim と同じ昇格パターンで動作確認。
  • Phase 175: P5 複数キャリア対応（_parse_string 向け） ✅ (2025-12-08) → Task 175-1: _parse_string のキャリア候補を洗い出す（pos, result, is_ch_match の 3 キャリア特定）。 → Task 175-2: CarrierInfo / ExitMeta に複数キャリアを載せる設計を固める（既存箱がすべて複数対応済みと確認）。 → Task 175-3: 小さい PoC で 2 キャリアだけ通してみる（MIR 検証で Pattern2 の制約を特定）。 → Task 175-4: CURRENT_TASK / joinir-architecture-overview 更新。 → 成果: P5 アーキテクチャが複数キャリアに対応済みであることを確認。 CarrierInfo は 3 キャリア検出済み（pos, result, is_ch_match）。 Pattern2 実装が Trim 最適化により pos のみ emit する制約を発見（Phase 176 改善対象）。
  • Phase 176: Pattern2 multi-carrier lowering ✅ (2025-12-08) → Task 176-1: 制限ポイント特定（10箇所の TODO マーク） → Task 176-2: CarrierUpdateLowerer ヘルパ実装（6 unit tests） → Task 176-3: ヘッダ PHI / ループ更新 / ExitLine を全キャリア対応に拡張 → Task 176-4: E2E テスト成功（2キャリア: pos + result） → Task 176-5: ドキュメント更新 → 成果: Pattern2 が複数キャリアに完全対応。CarrierInfo に載っている全キャリアの UpdateExpr を MIR に emit。 → バグ修正: Trim pattern の loop_var_name 上書き問題、InstructionRewriter の latch_incoming 設定問題。

• 今後 1〜2 フェーズの TODO（JoinIR 周りのサマリ）

  • Phase 177: Multi-carrier PHI 接続修正 ✅ (2025-12-08) - Task 177-STRUCT-1: CarrierVar に join_id 追加 - Task 177-STRUCT-2: carrier_order で順序保持（LoopHeaderPhiInfo） - 成果: Int テスト成功（sum=3）、index mismatch 問題解決
  • Phase 178: LoopUpdateAnalyzer string 検出 ✅ (2025-12-08) - Task 178-1: UpdateRhs 拡張（StringLiteral, Other 追加） - Task 178-2: analyze_rhs 分岐拡張（string/method call 検出） - Task 178-3: Pattern2/4 can_lower で string 拒否（Fail-Fast） - Task 178-4: Legacy fallback コメント修正（LoopBuilder 削除済み反映） - 成果: String loop は明示的エラー、numeric loop は正常動作維持 - 注意: グローバルテスト 79 件失敗は Phase 178 以前からの既知問題（別途対応）
  • Phase 180: Trim/P5 サブモジュール化 ✅ (2025-12-08) - Task 180-1: 設計ドキュメント作成（phase180-trim-module-design.md） - Task 180-2: TrimLoopLowerer スケルトン実装（try_lower_trim_like_loop 骨格） - Task 180-3: Pattern2 リファクタリング（~160 行の Trim ロジックを TrimLoopLowerer に委譲） - Task 180-4: Pattern4 分析（Trim 検出のみで lowering なし、スキップ） - Task 180-5: ドキュメント更新（joinir-architecture-overview.md + CURRENT_TASK.md） - 成果: Pattern2 から Trim 専用ロジックを完全分離、-135 行の削減 - TrimLoopLowerer: LoopConditionScopeBox + LoopBodyCarrierPromoter 統合 - 再利用性向上: Pattern2/4/未来パターンすべてで同じ Trim lowering を利用可能 - テスト: cargo build --release SUCCESS (0 errors, warnings のみ)
  • Phase 181: JsonParser ループ空間の再インベントリ ✅ (2025-12-08) - Task 181-1: JsonParserBox 内の全 11 ループを LoopPatternSpace の軸（A〜F）で分類 - Task 181-2: 各ループの Pattern1–4 + P5 へのマッピング（_parse_number/_atoi/_match_literal 等は P2/P1 で対応可能） - Task 181-3: _skip_whitespace / _trim* / _parse_string 最小版 など、既に JoinIR/P5 経路で動作しているケースを確認 - Task 181-4: 残りループの優先度と難易度を整理（_parse_array/_parse_object/_unescape_string は後続 Phase で対応） - 成果: JsonParser の全ループが「形としては P1–P4(+P5) で表現可能」であることを確認。 ループ形の追加は不要で、複雑さは BoolExprLowerer / ContinueBranchNormalizer / TrimLoopLowerer 側で吸収する方針を確定。
  • Phase 179-B: Generic Pattern Framework ✅ (2025-12-08) - Task 179-B-1: 設計ドキュメント作成（phase179-generic-pattern-framework.md） - Task 179-B-2: PatternPipelineContext 実装（pattern_pipeline.rs） - Task 179-B-3: Pattern 1 統一（168→149行, 11%削減） - Task 179-B-4: Pattern 3 統一（168→149行, 11%削減） - Task 179-B-5: Pattern 2 統一（517→509行, 1.5%削減） - Task 179-B-6: Pattern 4 統一（422→414行, 1.9%削減） - Task 179-B-7: テスト・ドキュメント更新（全代表ケース PASS） - 成果: 全パターン（P1/P2/P3/P4）で PatternPipelineContext 統一、 前処理ロジック一本化、挙動不変（テスト全 PASS）。 - 設計原則: Pure analysis container（解析のみ、emission なし）、 Analyzer-only dependencies、Pattern-specific variants（Option）。 - 注意: Pattern 2/4 の複雑ロジック（Trim, carrier 解析）は inline 維持。 将来 Phase 180+ で Trim module 化予定。
  • Phase 181: JsonParser 残りループ設計調査 ✅ (2025-12-08) - Task 181-1: 全11ループの再チェック（Pattern × Box マトリクス作成） - Task 181-2: ブロック分析（LoopConditionScopeBox 制約との照合） - Task 181-3: ロードマップ作成（phase181-jsonparser-loop-roadmap.md） - 成果: 全ループが「LoopParam/OuterLocal のみ」という制約を満たし、理論的に全対応可能 - 発見: ブロックされるループは存在しない（Trim は昇格パターンで対応済み） - 優先度: P2 Break（3個: _parse_number/_atoi/_atof_loop）> P1 Simple（1個: _match_literal）> P4 Continue（3個: _parse_array/_parse_object/_unescape_string）
  • Phase 182: JsonParser P1/P2 パターン検証 ✅ (2025-12-08) - Task 182-1: 設計ドキュメント作成（phase182-simple-loops-design.md） - Task 182-2: Routing whitelist 更新（_parse_number/2, _atoi/1, _match_literal/3 追加） - Task 182-3: Pattern routing 確認（NYASH_JOINIR_STRUCTURE_ONLY=1 tracing） - Task 182-5: 代表テスト作成・実行 - ✅ Pattern1: phase182_p1_match_literal.hako PASS - ✅ Pattern2: phase182_p2_break_integer.hako PASS - Task 182-6: ドキュメント更新（joinir-architecture-overview.md, CURRENT_TASK.md） - 成果: P1/P2 パターンの基本動作確認完了（整数演算・early return で動作実証） - ブロッカー発見: 1. LoopBodyLocal 変数処理（ch, digit_pos, pos） - 現状: Trim 専用の carrier 昇格を試みてエラー - 必要: P1/P2 で純粋なローカル変数（昇格不要）として扱う仕組み 2. 文字列連結フィルタ（Phase 178） - 現状: num_str = num_str + ch を保守的に reject - 必要: JsonParser 向けに段階的有効化 - 次ステップ: Phase 183 で LoopBodyLocal 処理と string ops 対応
  • Phase 183: LoopBodyLocal 役割分離 ✅ (2025-12-08) - Task 183-1: 設計メモ作成（phase183-loopbodylocal-role-separation.md） - LoopBodyLocal を 2 カテゴリに分類設計（Condition vs Body-only） - Trim promotion は条件に出てくる変数のみ対象 - body-only local は昇格スキップ - Task 183-2: LoopBodyLocal 役割分離実装 - TrimLoopLowerer に is_var_used_in_condition() ヘルパー追加 - 条件で使われていない LoopBodyLocal を Trim 昇格対象から除外 - 5 unit tests（variable detection, binary op, method call, nested） - Task 183-3: 代表ループテスト作成 - phase183_body_only_loopbodylocal.hako: body-only LoopBodyLocal デモ - トレース確認: [TrimLoopLowerer] No LoopBodyLocal detected, skipping Trim lowering ✅ - Task 183-4: ドキュメント更新（joinir-architecture-overview.md, CURRENT_TASK.md） - 成果: LoopBodyLocal 役割分離完了、body-only 変数は Trim promotion されない - 残課題: body-local 変数の MIR lowering 対応（Phase 184+ で対応予定） - 発見: Pattern1 実行問題（別途対応必要、Phase 183 スコープ外）
  • Phase 184+: Body-local 変数 MIR lowering + String ops 有効化 - body-local 変数（local temp in loop body）の MIR 生成対応 - String concat フィルタの段階的緩和 - _parse_number, _atoi 完全実装
  • Phase 183+: JsonParser 中級パターン実装 - _parse_array, _parse_object （P4 Continue, MethodCall 複数対応） - _parse_string 完全版 （P2/P4, string concat + escape）
  • Phase 184+: JsonParser 高級パターン実装 - _unescape_string （P4 Continue, 複雑キャリア + flatten）

---

2. Self‑Host depth‑2 / MIR JSON v0 / JoinIR Analyzer ライン

• 現状
  • .hako から Program JSON v0 / MIR JSON を読み込む準備は整備済み（Phase 160 系）。
  • JsonParserBox / JsonParserBox.ProgramJSONBox / JsonParserBox.JsonParserBox 自体は箱として実装されている。
  • MIR/JoinIR Analyzer Box 群（MirAnalyzerBox, JoinIrAnalyzerBox）は基盤実装済み。
• 直近の目的
  • JoinIR ループ基盤が安定した前提で、「selfhost depth‑2 の最小ループ」がどこまで回るかを再確認する。
  • JsonParserBox 側のループ制約（Pattern1–4 + 将来 Pattern5）と、Analyzer Box の入力形式を揃える。
• 次にやる候補
  • Phase 161‑続き: MirAnalyzerBox / JoinIrAnalyzerBox に対する代表ケースの再実行
    （loop パターンが JoinIR 統一後も正しく認識できているか確認）。
  • Phase 166‑続き: Program JSON v0 / MIR JSON v1 を .hako 側で安全にパースできるか確認
    （JsonParserBox のループ制約と衝突しないかをチェック）。

---

3. hako_check / MIR CFG / JoinIR 解析ライン

• 現状
  • HC019 / HC020（DeadCode / DeadBlocks）など、hako_check 側の Box は JoinIR/MIR CFG を読む経路に統一済み。
  • JsonParserBox による JSON パーサー共通ライブラリ化も進行中（Phase 170–172）。
• 直近の目的
  • JoinIR / MIR ラインの変更（Pattern1–4, ExitLine, Boundary, ConditionScope）が hako_check に与える影響を最小に保ちつつ、
    解析結果の精度を維持する。
• 次にやる候補
  • Phase 155+ の MIR JSON v1 統合ラインを、最新の JoinIR/Loop 仕様に追随させるかどうかの判断。
    （今のところブロッカーではないので優先度は中〜低）

---

✅ 最近完了した主なフェーズ（抜粋）

ここは「今の作業に強く関係する直近フェーズ」だけをざっくり残すよ。詳細は各 phase ドキュメントを参照。

• Phase 33‑16/20/21: Loop header PHI / ExitLine / Boundary の SSOT 化
  → ループ変数の現在値と exit 値が header PHI / ExitLine 経由で一貫して伝播するようになった。

• Phase 33‑18/19/20: Pattern4（continue）・else‑continue 正規化・carrier フィルタリング
  → continue 含みのループ（Pattern4）が JoinIR 統一ラインの中で動作。
  ContinueBranchNormalizer / LoopUpdateAnalyzer / CarrierInfo ラインが安定。

• Phase 165: JoinIR ループ Pattern1–4 代表ケースの完全検証
  → loop_min_while / joinir_min_loop / loop_if_phi / loop_continue_pattern4 で
  [joinir/freeze] と SSA‑undef を全排除。

• Phase 170‑D (＋BugFix): LoopConditionScopeBox 実装＆パラメータ誤分類バグ修正
  → ループ条件の変数スコープ分類（LoopParam / OuterLocal / LoopBodyLocal）が安定。
  JsonParserBox の s, pos, len など関数パラメータが正しく OuterLocal と見なされるようになった。

• Phase 168–169: BoolExprLowerer / condition_to_joinir 強化
  → _trim / _skip_whitespace の OR chain / AND / NOT を JoinIR/MIR に正しく落とせるようになった。
  （ただし LoopBodyLocal 条件をどう扱うかは Pattern5 設計の領域として切り出し済み）

---

📌 このファイルの運用方針

• CURRENT_TASK.md には「直近 1〜2 週間で触っているライン」と「次にやる候補」だけを書く。
• フェーズごとの詳細ログ・長文の議事録・実装メモは:
  • docs/development/current/main/10-Now.md
  • docs/development/current/main/phaseXX*.md に移し、このファイルからはリンクまたは簡単な要約だけに留める。
• もし CURRENT_TASK がまた肥大化してきたら、
  古いセクションを phase ドキュメント側に逃して、このファイルを再度「現在地サマリ」に戻す。