hakorune/docs/development/current/main/phase232-failing-tests-inventory.md

# Phase 232: Failing Tests Inventory & Classification

このドキュメントは、2025-12 時点の `cargo test --release` で残っている 7 件の FAIL を  
「どの箱／どのパターン／どのレイヤの問題か」で棚卸しするフェーズ用のメモだよ。

---

## 1. 失敗テスト一覧（Task 232-1）

ベースコマンド:

```bash
cargo test --release
```

このセッションでの FAIL は次の 7 件だったよ（当時: 890 passed / 7 failed / 64 ignored）。  
**Update (Phase 233)**: `loop_update_summary` の 4 件を AST ベーステストに刷新して PASS 化し、いまは **894 passed / 3 failed / 64 ignored** だよ（残りは array_filter 系 3 件のみ）。

### 1.1 loop_update_summary 系ユニットテスト（4 件 → Phase 233 で解消済み）

対象ファイル: `src/mir/join_ir/lowering/loop_update_summary.rs`

1. `mir::join_ir::lowering::loop_update_summary::tests::test_analyze_mixed`
   - パターン: if-sum / Counter+Accumulation 検出ロジック（P3 if-sum 用の分析箱）。
   - 失敗種類: **期待値 mismatch（名前ベースヒューリスティック vs 新 AST ベース実装）**
     - 現行実装 `analyze_loop_updates()` は deprecated だが、テストはまだ古いヒューリスティック前提。
   - 備考: 実運用では `analyze_loop_updates_from_ast()` が主経路（Phase 219）。

2. `mir::join_ir::lowering::loop_update_summary::tests::test_analyze_single_counter`
   - パターン: CounterOnly（単一カウンタ）判定。
   - 失敗種類: **期待値 mismatch（deprecated API の挙動とテスト期待のズレ）**
   - 備考: `analyze_loop_updates()` 内で kind を全て AccumulationLike にしているため、テストの CounterLike 期待と合わない。

3. `mir::join_ir::lowering::loop_update_summary::tests::test_is_simple_if_sum_pattern_basic`
   - パターン: P3 if-sum の「i + sum」基本パターン検出。
   - 失敗種類: **期待値 mismatch（is_simple_if_sum_pattern の入力を deprecated wrapper で生成している）**
   - 備考: 本番 if-sum 経路は Phase 219 以降、AST ベースの update 検出に移行済み。

4. `mir::join_ir::lowering::loop_update_summary::tests::test_is_simple_if_sum_pattern_with_count`
   - パターン: P3 if-sum の「i + sum + count」マルチキャリアパターン。
   - 失敗種類: **期待値 mismatch（上と同様、テスト専用の古い summary 生成ロジック）**

Update (Phase 233): 上記 1–4 はすべて `analyze_loop_updates_from_ast()` を直接呼ぶ AST フィクスチャベースのテストに置き換え、`cargo test --release` で PASS になったよ。

### 1.2 ArrayExtBox.filter まわりの joinir mainline テスト（3 件）

対象ファイル: `src/tests/joinir/mainline_phase49.rs`

5. `tests::joinir::mainline_phase49::phase49_joinir_array_filter_smoke`
   - パターン: P3 if-phi / Array filter ループ（実戦寄り PoC）。
   - 失敗種類: **[joinir/freeze] 系エラー → accumulator `'sum' not found in variable_map` で panic**
     - メッセージ: `"[cf_loop/pattern3] Accumulator variable 'sum' not found in variable_map"`
   - 備考: JoinIR mainline に route したあと、Pattern3 PoC lowerer が `sum` を carrier として見つけられず Fail-Fast。

6. `tests::joinir::mainline_phase49::phase49_joinir_array_filter_fallback`
   - パターン: 同じ ArrayExtBox.filter の fallback 経路（Structure-only / legacy PoC の確認用）。
   - 失敗種類: **テスト側期待値「fallback compile should succeed」 vs 実際は Fail-Fast エラー**
     - つまり「今は array_filter の JoinIR 対応をまだ本番とみなさない」状態をどう扱うかのポリシーの問題。

7. `tests::joinir::mainline_phase49::phase49_joinir_array_filter_ab_comparison`
   - パターン: Array filter の route A/B 比較テスト。
   - 失敗種類: **Route A compile should succeed → 同じ `'sum' not found` エラーで失敗**
   - 備考: いずれも core バグというより「ArrayExtBox.filter の JoinIR 適用方針が途中」のフェーズ感のテストだよ。

---

## 2. 箱・レイヤごとの分類（Task 232-2）

ここでは「どのラインの箱から見た問題か」をざっくり割り当てるよ。

### 2.1 JoinIR core ライン

- ArrayExtBox.filter 系（テスト 5–7）
  - 主に Pattern3 if-phi / carrier detection / variable_map との橋渡しライン。
  - エラー文言から見えるのは:
    - `Accumulator variable 'sum' not found in variable_map`
    - → **LoopPattern + CarrierInfo + ExitLine の間の「carrier 定義/再接続」が足りない**。
  - ただし、これは「内部の SSOT が崩れている」というより、PoC lowerer と本線 lowerer が混在している歴史的ライン。

### 2.2 LoopPattern ライン

- loop_update_summary 系（テスト 1–4）
  - P3 if-sum / CaseA パターン検出の一部。
  - 現行本番経路:
    - AST ベースの `analyze_loop_updates_from_ast()` ＋ P3 if-sum 実装（Phase 212/213/220）。
  - テストが見ているのは:
    - deprecated な `analyze_loop_updates()`（名前ベース）と、それにぶら下がる is_simple_if_sum_pattern の挙動。
  - 位置づけとしては **LoopPattern (分析箱) の「旧 API テスト」**。

### 2.3 表現ライン（ConditionEnv / ExprLowerer / MethodCallLowerer / LoopBodyLocalEnv）

- 今回の 7 件の FAIL は、直接にはこの表現レイヤにはかかっていない:
  - Type error / SSA-undef / alias 解決の失敗ではなく、
    - 「古い分析 API のテスト期待値のまま」
    - 「PoC lowerer の carrier 認識が足りない」
    といったレベルの問題に収まっている。
- つまり Phase 232 時点では、ExprLowerer/ScopeManager まわりの **新実装が原因の FAIL はゼロ** という整理でよさそうだよ。

---

## 3. P0/P1/P2 分類（Task 232-3）

ここでは、次フェーズでどう扱うかの優先度分類をするよ。

### 3.1 P0: すぐ直したい JoinIR core バグ

- **今回は P0 該当なし** として扱うのがよさそう。
  - 理由:
    - SSA-undef / PHI 破損 / ValueId 衝突 / ExitLine 契約違反のような「core 崩壊系」の FAIL は含まれていない。
    - ArrayExtBox.filter 系も「PoC lowerer の制約に当たって Fail-Fast」が明示的に出ているだけで、  
      既存の JsonParser / if-sum ラインを壊しているわけではない。

### 3.2 P1: パターン拡張で解決できるもの

候補としては次の 2 グループだよ（Phase 232 時点の整理; その後の更新を併記するね）:

1. **loop_update_summary ユニット（テスト 1–4）** → Phase 233 で解消済み
   - 実際の本番 if-sum ラインは AST ベースで動いているので、
     - これらのテストを「deprecated wrapper の振る舞いテスト」ではなく、
     - `analyze_loop_updates_from_ast()` ベースのテストに差し替える  
     ことで自然に緑にできる。
   - つまり「core バグ」ではなく **テストの更新／仕様の追随** で解消可能。
   - **Phase 233 で実施済み（PASS 化）**。

2. **ArrayExtBox.filter 系（テスト 5–7）**
   - Pattern3 if-phi / Accumulation パターンとして見れば、  
     - `sum` を carrier として認識する
     - legacy PoC lowerer のエラー文言を **「意図的な Fail-Fast」か「サポートする方向」か** 決める  
     といった「パターン拡張 or ポリシー明確化」で解決可能。
   - ただし、こちらは実戦 ArrayExtBox.filter の仕様をどうしたいかに依存するので、  
     先に loop_update_summary 側を P1 で触るほうがスコープが小さくて良さそう。

### 3.3 P2: 当面 Fail-Fast に残すもの

Phase 234 の結論:

- **ArrayExtBox.filter 系 3 テスト（5–7）は P2 に固定**（意図した Fail-Fast / 将来拡張候補）。
  - 理由:
    - ArrayFilter は「BoxCall ベース Accumulation（out.push）」であり、数値 if-sum ラインとは別系統の設計が必要。
    - JsonParser / selfhost / ExprLowerer など、既に進行中のコアラインより優先して手を入れる理由がまだ弱い。
    - 現状の `[cf_loop/pattern3] Accumulator variable 'sum' not found in variable_map` は、「P3 if-PHI の外側にある PoC 領域」を示すラベルとして有用。
  - したがって Phase 234 では:
    - コード変更は行わず、
    - `phase234-array-filter-design.md` に ArrayFilter パターンと P3 if-PHI との関係、将来フェーズでの拡張案だけを整理する。

一方、loop_update_summary ユニット（1–4）は:

- P1（「次にテストを更新するときに一緒に触る」）として扱うのが妥当だよ。
  - 本番経路は既に `analyze_loop_updates_from_ast()` を使っており、  
    deprecated wrapper の仕様を保つ必要は低い。

---

## 4. 次フェーズ候補（Task 232-4）

Phase 232 の整理を前提にした「次の軸」の候補だけメモしておくね（コードはまだ書かない）。

- **Phase 233（P1: 分析箱テストのアップデート）**
  - ねらい:
    - `loop_update_summary.rs` のテスト 1–4 を `analyze_loop_updates_from_ast()` ベースに更新し、  
      実戦 if-sum ラインとテスト仕様を揃える。
  - やることの例:
    - AST フィクスチャ（簡単な if-sum ループ）を直接組んで `analyze_loop_updates_from_ast()` をテスト。
    - deprecated `analyze_loop_updates()` のテストは「歴史メモ」扱いに移すか、最小限だけ残す。

- **Phase 234（P1: ArrayExtBox.filter ラインの設計再検討）**
  - ねらい:
    - ArrayExtBox.filter を「P3 if-phi + Accumulation pattern」として本当に JoinIR で扱うかどうかを設計レベルで決める。
  - やることの例:
    - phase49 の mainline テストが期待しているシナリオを整理（route A/B、fallback の位置づけ）。
    - Pattern3 if-sum / array filter / map/filter 系の位置づけを `loop_pattern_space.md` に追記。
    - まだコードには触らず、「やるならこういう箱に分ける」という案まで。

- **Phase 235（P2: B 系パターンの扱い方の設計だけ）**
  - ねらい:
    - いまは Fail-Fast している B 系パターン（複雑ネスト / 多段メソッドチェーンなど）を  
      「今後も Fail-Fast のままにするのか」「別レイヤの箱で扱うか」を整理する。
  - やることの例:
    - `[joinir/freeze]` 系メッセージを洗い出して、B 系パターンの代表例を docs にまとめる。
    - async / catch / filter/map 連鎖などを、JoinIR 本体ではなく上位レイヤに逃がす設計案を書くだけに留める。

---

## 5. まとめ

- 現状の 7 FAIL は:
- 4 件: **loop_update_summary の deprecated API テスト**（Phase 233 で AST ベースに刷新し PASS 化済み）。
- 3 件: **ArrayExtBox.filter の PoC パターン3 lowerer に対する挙動確認テスト**（意図的 Fail-Fast に近い） ← 現在残っている FAIL。
- JoinIR core（PHI/ValueId/ExitLine/SSA）としての致命的な崩れは含まれていないので、  
  Phase 232 の結論としては「**今の FAIL は “どこをまだやっていないか” を教えてくれるラベル**」とみなしてよさそうだよ。