Completes Phase 218 investigation: Identifies root cause preventing AST-based if-sum lowerer from activating. ## Investigation Summary ### Test Case Created - File: apps/tests/phase218_json_if_sum_min.hako - Pattern: JsonParser-style conditional accumulation (sum = sum + i) - Expected: RC=10, Actual: RC=0 (blocked by phantom carrier) ### Root Cause Identified: Phantom Carrier Bug **Problem**: AST-based if-sum lowerer (Phase 213) never activates **Cause Chain**: 1. loop_update_summary.rs uses name-based heuristics 2. Detects phantom "count" variable (doesn't exist in code) 3. counter_count() returns 2 instead of 1 (i + phantom "count") 4. is_simple_if_sum_pattern() returns false 5. Dual-mode dispatch uses legacy fallback instead of AST lowerer **Evidence**: ``` Debug output shows hardcoded template "i % 2 == 1" (legacy lowerer) Not from AST extraction (AST-based lowerer never called) ``` ### Critical Discovery **Phase 216 claim "RC=2 ✅" for phase212_if_sum_min.hako is false** - Current execution: RC=0 (wrong) - Expected: RC=2 - Indicates: Phase 213-217 "success" was actually legacy lowerer ### Documentation Gap Phase 216/217 tests may not have been executed correctly, or regression occurred. All "if-sum" patterns are currently broken due to phantom carrier detection blocking AST lowerer activation. ## Files Created 1. apps/tests/phase218_json_if_sum_min.hako - Test case 2. docs/development/current/main/phase218-jsonparser-if-sum-min.md - Investigation report ## Files Updated 1. CURRENT_TASK.md - Phase 218 investigation results 2. joinir-architecture-overview.md - Phase 218 entry ## Next Steps: Phase 219 **Target**: Fix phantom carrier detection in loop_update_summary.rs **Fix**: Remove name-based heuristics, use assignment-based detection only **Expected Result**: Both phase212 and phase218 tests pass with correct RC ## Lessons Learned 1. Documentation can become stale - verify test results 2. Silent fallbacks hide bugs - dual-mode needs clear activation logging 3. Name heuristics are fragile - prefer structural analysis 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
7.3 KiB
7.3 KiB
Current Task
このファイルは「いま何に集中しているか」と「次にやり得る候補」だけを書く軽量ビューだよ。
詳細ログや過去フェーズの記録は docs/development/current/main/ 以下の各 phase-*.md と
joinir-architecture-overview.md を真実のソースとして扱うことにするね。
🎯 今フォーカスしているテーマ(2025-12-09 時点のスナップショット)
1. JoinIR ループ基盤の状態
- LoopBuilder は完全削除済みで、ループは JoinIR Pattern1–4(while / break / if‑PHI / continue)+ P5(Trim系) で統一。
- JoinValueSpace / LoopHeaderPhi / ExitLine / JoinInlineBoundary / JoinIRVerifier まで含めた 「Loop → JoinIR → MIR → return」のパイプラインは、代表パターンと JsonParser ミニケースで安定している。
- Phase 213–217 完了: P3(if‑PHI) は if‑sum 最小パターン(
phase212_if_sum_min.hako)まで AST ベースで一般化済みで、 Phase 215 で ExprResult の出口契約を Pattern2 と同じ形に揃えて RC=2 まで通すようになった。 Phase 216 で selfhost 側の production test も検証完了。 Phase 217 でマルチキャリア if‑sum(sum+count)も追加実装0行で動作確認 - Phase 195/214/215 の箱組合せで完璧動作。 - Phase 218 調査完了: JsonParser-style if‑sum 適用を試行し、パターン認識のギャップを特定。
- Phantom
countcarrier が誤検出され、is_if_sum_pattern()が false を返す根本原因を解明。 - AST ベース lowerer は実装済みだが、carrier 検出ロジックの問題で起動されていないことを確認。
- 次フェーズで carrier 検出修正 → AST lowerer 起動検証が必要。
- Phantom
2. JsonParser / Trim / selfhost への適用状況
- Trim 系:
_trim/_skip_whitespaceの P5 パイプライン(LoopBodyLocal 昇格 → bool carrier → TrimLoopLowerer)は
JoinIR→MIR まで end‑to‑end で安定動作。
- JsonParser:
- 11 ループ中、基本形(P1/P2/P5 相当)の 7 本は JoinIR インフラ上で理論的にカバー可能と確認済み。
- すでに JoinIR で実戦投入できているのは
_skip_whitespace/_trim*/_match_literal/_atoi_min/_parse_number_min。 - 残りの複雑ループ(
_parse_array/_parse_object/_unescape_string/ 本体_parse_stringなど)は
「LoopBodyLocal + 複数 MethodCall + 複数フラグ」という組み合わせで、今後の拡張対象として整理済み。
- selfhost (.hako):
- selfhost stage‑3 depth‑1(Rust→.hako)までは JoinIR 経路で代表ケースが緑。
- depth‑2(.hako 側で JSON/MIR を読み、JoinIR/MIR/VM/LLVM に流すライン)は、JsonParser 側のループカバレッジ拡張が前提。
3. 直近で意識しておきたい設計の芯
- Loop パターン空間は有限で整理済み:
- P1: Simple While
- P2: Break
- P3: If‑PHI(単一/複数キャリア)
- P4: Continue(then/else‑continue 正規化込み)
- P5: LoopBodyLocal 昇格(Trim/JsonParser 用の部分適用)
- 「増やすべき」は新しい Pattern ではなく、既存 Pattern の前処理箱:
- BoolExprLowerer / ConditionEnv / LoopConditionScopeBox / LoopBodyCarrierPromoter /
TrimLoopHelper / ComplexAddendNormalizer / LoopBodyLocalEnv / UpdateEnv などで
条件式とキャリア更新を吸収し、Pattern1–4 は「ループ骨格」に専念させる方針。
- BoolExprLowerer / ConditionEnv / LoopConditionScopeBox / LoopBodyCarrierPromoter /
TrimLoopHelper / ComplexAddendNormalizer / LoopBodyLocalEnv / UpdateEnv などで
- Fail‑Fast 原則:
- JoinIR 以外のループ lowering パスは存在しない(LoopBuilder は削除済み)。
- 「わからないパターン」は必ず
[joinir/freeze]系の明示エラーにして、サイレントフォールバックはしない。
✅ 最近まとまった大きな塊(超要約)
ここ半年くらいで終わっている主な塊だけをざっくり書くね。
細かいタスク・バグ票・議論は phase-XXX*.md に全部残っているので、必要になったときだけそちらを読む想定。
- LoopBuilder 削除ライン(Phase 180 前後)
- LoopBuilder を dev‑only → hard freeze → 物理削除まで完了。
- Loop lowering の SSOT を JoinIR に一本化。
- LoopPattern / Router ライン(Phase 170–179)
- LoopFeatures / LoopPatternKind / PatternRouter / PatternPipelineContext を整備。
- Pattern1–4 の検出・ルーティングを「構造ベース+AST features」で統一(関数名ベタ書き依存を除去)。
- Exit / Boundary / ValueId ライン(Phase 172–205)
- ExitMeta / ExitLineReconnector / JoinInlineBoundary(+Builder) / LoopHeaderPhiBuilder を箱化。
- JoinValueSpace(Param/Local 領域)+ PHI 契約 Verifier で ValueId 衝突と PHI 破損を根治。
- P5(Trim/JsonParser) ライン(Phase 171–176, 173–175, 190–193)
- LoopBodyLocal 昇格パイプライン(Trim,
_skip_whitespace,_parse_string簡易版)を構築。 - StringAppend / NumberAccumulation / Complex addend 正規化など、更新式まわりの箱を揃えた。
- LoopBodyLocal 昇格パイプライン(Trim,
- P3 (If‑PHI) 汎用化ライン(Phase 195–196, 212–215)
- multi‑carrier P3 の JoinIR 生成を整理。
- Select 展開 / JoinIR→MIR ブリッジ側のバグ(PHI inputs, back‑edge, 二重 remap)を修正。
- if‑sum 最小パターンを AST ベースで一般化し、ExprResult Exit 契約まで Pattern2 と揃えた。
このあたりが「JoinIR ループ基盤の芯」で、以降の Phase は JsonParser/selfhost の各ループへの適用フェーズ、という位置づけだよ。
🧭 これからの候補(まだ「やる」とは決めていないメモ)
ここは「やることリスト」ではなく「今後やるとしたらこの辺」というメモにする。
実際に着手するタイミングで、別途 Phase/タスクを切る想定だよ。
- JsonParser 残りループへの JoinIR 展開
_parse_array/_parse_object/_unescape_string/ 本体_parse_stringなど。- 既存の P2/P3/P4+P5 パイプラインをどこまで延ばせるかを検証するフェーズ。
- selfhost depth‑2 ラインの再開
.hako側で Program/MIR JSON を読んで JoinIR/MIR/VM/LLVM に流すライン。- JsonParser 側のカバレッジが上がったあとに、小さいループから順に移植する。
- JoinIR Verify / 最適化まわり
- すでに PHI/ValueId 契約は debug ビルドで検証しているので、 必要なら SSA‐DFA や軽い最適化(Loop invariant / Strength reduction)を検討。
📎 このファイルの運用ルール(自分向けメモ)
- 過去フェーズの詳細な ToDo/Done リストは CURRENT_TASK には書かない。
代わりにphase-XXX*.mdとjoinir-architecture-overview.mdを SSOT として維持する。 - CURRENT_TASK は「あくまで最新のフォーカスと次の候補だけ」に絞る。
目安として このファイル自体は 2〜3画面程度(〜300行以内) に収める。 - 新しい大フェーズを始めたら:
- まず docs 配下に
phase-XXX-*.mdを書く。 - CURRENT_TASK には「そのフェーズの一行要約」と「今のフォーカスかどうか」だけを書く。
- まず docs 配下に