a13f14cea0
feat(mir): Phase 21.7 Step 1-2 - NamingBox decode & Hotfix 7修正
...
## 実装内容
### Step 1: NamingBox decode関数追加 (naming.rs)
- ✅ `decode_static_method(func_name) -> Option<(box, method, arity)>`
- ✅ `is_static_method_name(func_name) -> bool`
- 対称性: encode ⇔ decode のペア実装で一貫性確保
### Step 2: unified_emitter Hotfix 7修正 (Lines 267-304)
- ✅ StaticCompiler box kind判定追加
- ✅ static box method は receiver 追加をスキップ
- ✅ instance method(RuntimeData/UserDefined)のみ receiver 追加
- ✅ トレース: NYASH_STATIC_METHOD_TRACE=1 でログ出力
## 判定ロジック
```rust
if box_kind == CalleeBoxKind::StaticCompiler {
// "BoxName.method/arity" 形式か確認
let func_name = format!("{}.{}/{}", box_name, method, args.len());
if is_static_method_name(&func_name) {
// static box method → receiver 追加しない
}
}
```
## 検証
✅ Stage-1 テスト: RC=0 (apps/tests/stage1_skip_ws_repro.hako)
✅ ビルド成功(0 error)
## 次のステップ
- Step 3: methodization実装 (HAKO_MIR_BUILDER_METHODIZE=1)
Co-Authored-By: ChatGPT5 <chatgpt@openai.com >
2025-11-21 23:52:10 +09:00
74271f3c5b
test(mir): Phase 25.1 StaticCompiler receiver回帰防止テスト追加
...
## テスト内容
1. MIR compile & verify(SSA検証)
2. VM実行でRC=0(receiver捏造バグ検出)
3. StringBox正規化確認(ParserBox→StringBox)
## 検証項目
- ✅ StringHelpers.skip_ws/2 呼び出し成功
- ✅ receiver型推論正常動作
- ✅ 文字列メソッド正規化動作確認
Co-Authored-By: ChatGPT5 <chatgpt@openai.com >
2025-11-21 14:00:09 +09:00
eb10fc7159
fix(mir): Phase 25.1 StaticCompiler receiver型推論バグ根治
...
## 問題
Stage-1ブリッジで `StringHelpers.skip_ws/2` 呼び出し時に:
- ParserBox.length(receiver=ValueId未定義) でVM落ち
- receiver が捏造される(型情報なし)
## 根本原因
1. CalleeResolver: receiver型なし→捏造ValueId生成
2. 順序問題: materialization → guard(逆であるべき)
3. 型注釈不足: String定数・BinOp結果に型情報なし
## 解決策(3 Phase)
### Phase 1: guard.rs Global フォールバック (lines 100-146)
- receiver型なし→Global変換で捏造ValueId防止
- Phase 3-C: 文字列メソッド→StringBox正規化追加
### Phase 2: unified_emitter.rs 順序反転 (lines 176-188)
- guard FIRST → materialization (Method のみ)
- Global 呼び出しの receiver 実体化を回避
### Phase 3-A: emit_string 型注釈 (constant.rs:46-49)
- String定数に value_types + value_origin_newbox 登録
### Phase 3-B: BinOp(Add) 型注釈強化 (ops.rs:70-86,145-166,178-198)
- value_origin_newbox もチェック(value_types のみ→両方)
- 結果も両方のマップに登録
### Phase 3-C: StaticCompiler 文字列メソッド正規化 (guard.rs:106-129)
- length/substring等→StringBox.method に統一
- ParserBox.length → StringBox.length
## 検証
✅ RC=0 達成(apps/tests/stage1_skip_ws_repro.hako)
✅ 正規化トレース確認(ParserBox→StringBox)
✅ receiver捏造完全防止
Co-Authored-By: ChatGPT5 <chatgpt@openai.com >
2025-11-21 13:53:50 +09:00
4565f7476d
wip(mir): StaticCompiler receiver正規化の部分的修正 - 将来の根治に向けた基盤整備
...
【修正内容】
1. src/mir/builder/calls/guard.rs
- receiver型情報がない場合のpass-through処理追加
- ME-CALL として後段処理に委譲
2. src/mir/builder/ssa/local.rs
- receiver kind で型情報がない場合、origin から型を推論
- value_types への伝播を強化
【現状】
- 完全な根治には至っていない(MIR builder設計レベルの複雑な依存関係)
- .hako側workaround (51d53c29 ) が実用的な解決策として機能中
【根本原因】
- value_origin_newbox に ParserBox が保持される
- value_types に実際の型(String等)が欠落
- receiver に型情報がないまま StaticCompiler Method に解決される問題
【今後の方向性】
- MIR builder の型伝播システム全体の見直しが必要
- Phase 25.1: Stage-1 bridge receiver bug (partial fix)
2025-11-21 13:28:35 +09:00
51d53c2932
wip(stage1): StringHelpers.skip_ws receiver捏造問題の応急処置
...
- 問題: StaticCompiler method呼び出し時にreceiver ValueIdが捏造され未定義エラー
- 応急処置: string_helpers.hako で src を明示的に文字列化 (""+src)
- 再現ケース: apps/tests/stage1_skip_ws_repro.hako 追加
- エラー: use of undefined value ValueId(28) in ParserBox.length(receiver=ValueId(28))
根本修正は次のcommitで実施:
- src/mir/builder/ssa/local.rs - receiver origin/type伝播強化
- Phase 25.1: Stage-1 bridge receiver bug (workaround)
2025-11-21 13:19:18 +09:00
59d620779b
fix(test): テスト調整 - 修正後用成功テストを有効化
...
- mir_stageb_string_utils_skip_ws_exec_reproduce_void_lt_zero: ignore化(修正前用)
- mir_stageb_string_utils_skip_ws_exec_success: 有効化(修正後用)
- テスト結果: 2 passed, 1 ignored, 0 failed ✅
- Phase 25.1: skip_ws Void < 0 TypeError 完全根治確認
2025-11-21 12:38:37 +09:00
c56d00b3c5
test(stageb): ParserStringUtilsBox.skip_ws Void < 0 TypeError 再現テスト追加
...
- 目的: commit 227ce61d の修正効果を検証
- テスト内容:
1. mir_stageb_string_utils_skip_ws_compile: MIRコンパイル成功確認
2. mir_stageb_string_utils_skip_ws_exec_reproduce_void_lt_zero: エラー再現(修正前用)
3. mir_stageb_string_utils_skip_ws_exec_success: 正常動作確認(修正後用・ignore)
- 検証済み:
- 修正前 (b00cc8d5 ): Type error: unsupported compare Le on Void and Integer(0)
- 修正後 (227ce61d ): RC=0 正常終了
- Phase 25.1: Stage-B scan系バグ修正完了
2025-11-21 12:35:09 +09:00
227ce61de8
fix(stageb): ParserStmtBox skip_ws静的呼び出し化 - Phase 25.1
...
**変更内容**:
- ctx.skip_ws(src, j) → ParserStringUtilsBox.skip_ws(src, j) (20箇所)
- ParserStmtBox.parse: 13箇所
- ParserStmtBox.parse_using: 7箇所
**理由**:
- MIRレベルでctx(ParserBox instance)がString化する問題を根本回避
- 箱理論的に正しい設計: scan utility = static box統一
- Region+next_iパターンと一貫性維持(LoopForm v2設計準拠)
**影響範囲**:
- lang/src/compiler/parser/stmt/parser_stmt_box.hako のみ
- using追加: ParserStringUtilsBox
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-21 12:27:24 +09:00
b00cc8d579
refactor(stage1-bridge): モジュール分割 - 275→386行(4ファイル)
...
**分割構成**:
- modules.rs (73行): collect_modules_list - nyash.toml解析
- args.rs (106行): build_stage1_args - mode別args構築
- env.rs (82行): configure_stage1_env - 環境変数設定
- mod.rs (125行): maybe_run_stage1_cli_stub - エントリポイント
**効果**:
- 単一責任原則: 各ファイルが明確な責務
- テスタビリティ: 個別関数を単体テスト可能
- 可読性: 275行単一ファイル → 4ファイル(73-125行)
- 保守性: 変更影響範囲が明確
**永続性**:
- static instance化と無関係(削除されない)
- Phase 25.x方針適合(新規モジュールの分割は自然)
Phase: 25.x
2025-11-21 11:26:28 +09:00
c344451087
fix(mir-builder): static method arity mismatch根治 - Phase 25.x
...
**問題**:
- ParserStmtBox.parse_using/4 に5引数が渡される
- me.method呼び出しで instance/static 判別なし
- static method に誤って receiver 追加
**修正**:
- MeCallPolicyBox: params[0]の型で instance/static 判別
- Instance method: receiver 追加
- Static method: receiver なし
- Arity検証(NYASH_ME_CALL_ARITY_STRICT=1)
**ドキュメント**:
- docs/reference/environment-variables.md 新規作成
- docs/development/architecture/mir-logs-observability.md 更新
**テスト**:
- src/tests/mir_stage1_cli_emit_program_min.rs 追加
- 既存 stage1 テスト全てパス
Phase: 25.x
2025-11-21 11:16:38 +09:00
b92d9f335d
docs(mir-logs): MIRログ観測リスト完成 - __mir__.log 全箇所を分類
...
Phase 25.4-C: MIR ログ観測リスト作成
## 📋 実装内容
### 1. ログ呼び出し全14箇所を列挙
- `rg "__mir__\\.log" lang/src -n` で全箇所を調査
- ファイル・行番号・タグ・用途を完全文書化
### 2. 3分類に整理
#### Dev専用(11箇所)- 削除候補
- **Stage-1 CLI Debug** (10箇所): entry/config/argc debug
- 制御: `STAGE1_CLI_DEBUG=1`
- MIR Builder type confusion デバッグ用
- **StringHelpers Debug** (1箇所): to_i64 input debug
- 制御: `NYASH_TO_I64_DEBUG=1`
- Void → Integer 型崩れデバッグ用
#### 観測用(3箇所)- 残す候補
- **FuncScanner Debug** (3箇所): skip_ws loop iteration
- LoopForm v2 / PHI 生成検証
- Region+next_i SSA 安定性確認
- 将来的な「MIR 観測 API」の代表例
#### コメント(1箇所)
- Test file comment
### 3. 将来構想
- `MirLogBox` 箱化構想を記載
- ログレベル制御・構造化ログ・パフォーマンストレース機能
- MIR デバッガー統合の下地
## 技術的成果
- **全箇所可視化**: 14箇所のログ用途を完全把握
- **分類明確化**: Dev専用 vs 観測用を明示
- **将来設計**: MIR 観測 API 構想を文書化
## 文書作成
- 新規: `docs/development/architecture/mir-logs-observability.md`
## 方針
- **Phase 25.4**: ドキュメント整理のみ(コード変更なし)
- **後続フェーズ**: Dev専用ログ削除・観測用ログ API化を検討
## 参考
- Phase 25.4 全体: docs/development/roadmap/phases/phase-25.4-naming-cli-cleanup/README.md
🎉 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-21 09:48:08 +09:00
554ba96f76
feat(stage1-cli): Config箱化完了 - env処理を一元管理
...
Phase 25.4-B: Stage-1 CLI 設定箱実装
## 📦 実装内容
### 1. Config 箱作成
- 新規: `Stage1CliConfigBox` (`lang/src/runner/stage1_cli.hako:16-48`)
- `from_env()` メソッドで全環境変数を MapBox に集約
- Mode/Backend/Sources/Dev flags を構造化
### 2. stage1_main リファクタ
- `local cfg = Stage1CliConfigBox.from_env()` で設定取得
- `env.get` 散在 → `cfg.get` 一箇所参照に統一
- Mode-based dispatch (emit_program_json | emit_mir_json | run | disabled)
### 3. 環境変数マッピング
**実行制御**:
- `NYASH_USE_STAGE1_CLI` → mode="run"
- `STAGE1_EMIT_PROGRAM_JSON` → mode="emit_program_json"
- `STAGE1_EMIT_MIR_JSON` → mode="emit_mir_json"
- `STAGE1_BACKEND` → backend (default: "vm")
- `STAGE1_SOURCE` / `STAGE1_SOURCE_TEXT` / `STAGE1_PROGRAM_JSON` → sources
**Dev専用**:
- `STAGE1_CLI_DEBUG` → debug
- `NYASH_TO_I64_FORCE_ZERO` → to_i64_force_zero
### 4. 設計文書
- 新規作成: `docs/development/roadmap/phases/phase-25.4-naming-cli-cleanup/README.md`
- Config フィールド設計・環境変数マッピング完全文書化
## 技術的成果
- **env.get 削減**: stage1_main 内 15箇所 → 1箇所(Config生成)に集約
- **Mode決定ロジック**: 排他的Mode選択を Config 箱に集中
- **保守性向上**: 環境変数追加時は Config 箱のみ修正
## テスト結果
✅ cargo test mir_stage1_cli_stage1_main_shape_verifies: 1 passed
✅ cargo test mir_stage1_cli_entry_like_pattern_verifies: 1 passed
✅ cargo test mir_static_box_naming: 2 passed
✅ Background stage1_cli execution: RC=0
## 参考
- Phase 25.4-A: fa9cea51 , bceb20ed , 419214a5
- Config 設計: docs/development/roadmap/phases/phase-25.4-naming-cli-cleanup/README.md
🎉 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-21 09:43:42 +09:00
419214a5a9
feat(naming): Python NamingHelper実装 - Rust NamingBoxのミラー完成
...
Phase 25.4 メンテナンス: Python LLVM側のNamingBox SSOT統一
## 📦 実装内容
### 1. Python NamingHelper作成
- 新規作成: `src/llvm_py/naming_helper.py`
- Rust `src/mir/naming.rs` と完全同一の意味論を実装
- 3つの関数:
- `encode_static_method(box_name, method, arity)` → "BoxName.method/arity"
- `canonical_box_name(raw)` → "main" → "Main"
- `normalize_static_global_name(func_name)` → "main._nop/0" → "Main._nop/0"
- doctest 9個全てPASS ✅
### 2. Python LLVM側の統一修正
- `instructions/boxcall.py:437` - f"Main.{method_name}/{arity}" → encode_static_method()
- `instructions/call.py:170-173` - traced_names タプル生成をNamingHelper経由に変更
- `pyvm/intrinsic.py:17, 50` - "Main.esc_json/1", "Main.dirname/1" → encode_static_method()
- `builders/entry.py:16` - 'Main.main/1' → encode_static_method("Main", "main", 1)
## 🎯 技術的成果
- **意味論一致**: Rust ↔ Python で完全同一の命名規則
- **保守性向上**: ハードコード4箇所 → NamingHelper一元管理
- **テスト完備**: doctest 9個でRust NamingBoxと同一動作を保証
## テスト結果
✅ python3 -m py_compile: 全ファイル構文OK
✅ python3 -m doctest naming_helper.py: 9 tests passed
## 参考
- Phase 25.4-A (Rust側): fa9cea51 , bceb20ed
- Rust NamingBox SSOT: src/mir/naming.rs
🎉 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-21 09:38:49 +09:00
bceb20ed66
refactor(naming): 箱理論 - Entry選択ロジック統一&NamingBox統合
...
Phase 25.4 メンテナンス: Task A延長線上の箱化リファクタリング
## 📦 箱化内容
### 1. Entry選択ロジック統一箱
- 新規作成: `src/runner/modes/common_util/entry_selection.rs`
- 3箇所の重複ロジックを `select_entry_function()` に集約
- `selfhost/json.rs:48-59` (11行削減)
- `pyvm.rs:32-43` (11行削減)
- `pyvm.rs:102-113` (11行削減)
- `llvm.rs:292` (直接アクセス→統一関数呼び出し)
### 2. NamingBox SSOT 統合
- arity-aware優先フォールバック実装
1. `Main.main/0` (arity付き、NYASH_BUILD_STATIC_MAIN_ENTRY=1時)
2. `Main.main` (legacy、arity無し、現行デフォルト)
3. `main` (top-level、NYASH_ENTRY_ALLOW_TOPLEVEL_MAIN=1時)
4. `"Main.main"` (デフォルトフォールバック)
## 技術的成果
- **重複削減**: 33行の重複ロジック→1箇所に集約
- **NamingBox統一**: 全Entry選択が `src/mir/naming.rs` 経由
- **将来対応**: arity付き名前に自動対応(互換性維持)
## テスト結果
✅ cargo test mir_static_box_naming: 2 passed
✅ cargo test stage1_cli_entry_ssa_smoke: 2 passed
## 参考
- Phase 25.4-A完了commit: fa9cea51
- 箱理論原則: 重複ロジックを箱化→境界を明確化→一元管理
🎉 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-21 09:33:56 +09:00
fa9cea51b6
feat(naming): Phase 25.4-A NamingBox SSOT統一化完了
...
Task A: NamingBox SSOT化(static/global名前決定の一元化)
## 変更内容
### 1. Builder側をNamingBoxに統一
- `src/mir/builder/decls.rs:46`
- 手動string組み立て → `encode_static_method()`使用に変更
- "Main.main" → "Main.main/N" (arity付き正規形)
### 2. VM側の構造確認・ドキュメント強化
- `src/backend/mir_interpreter/handlers/calls/global.rs:145-149`
- NamingBox SSOT原則をコメントで明示
- レガシーフォールバック廃止を明記
## テスト結果
✅ cargo test mir_static_box_naming: 2 passed
✅ cargo test stage1_cli_entry_ssa_smoke: 2 passed
## 技術的成果
- static box / global 呼び出しの名前決定を `src/mir/naming.rs` に一本化
- 手動文字列組み立て(`format!("{}.{}", box, method)`)を排除
- 正規化ルール(main→Main等)をNamingBox経由で統一
## 参考
- Phase 25.4計画: docs/development/roadmap/phases/phase-25.4-naming-cli-cleanup/
- NamingBox SSOT: src/mir/naming.rs
🎉 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-21 09:16:27 +09:00
2f07ab6a30
docs(phase25.4): Phase 25.4 ロードマップ・ドキュメント整備
...
📋 Phase 25.4 計画確定: NamingBox SSOT化 & CLI設定箱
✅ 追加ドキュメント:
- docs/development/roadmap/phases/phase-25.4-naming-cli-cleanup/
- README.md: Phase 25.4 全体計画
- A. NamingBox SSOT化(完了)
- B. Stage-1 CLI 設定箱(次フェーズ)
- C. MIR ログ観測リスト(次フェーズ)
- docs/development/roadmap/phases/phase-21.7-normalization/README.md
- Phase 21.7 との関連性追記
- docs/development/roadmap/phases/phase-25.1/stage1-usingresolver-loopform.md
- Phase 25.1 完了記録更新
- CURRENT_TASK.md: タスク進捗更新
- Phase 25.4-A 完了
- Phase 25.4-B/C 準備完了
- MIR Builder 型混乱バグ調査完了記録
🎯 Phase 25.4 戦略:
0. 共通方針
- 既定挙動は変えない(Fail-Fast + テスト緑キープ)
- 新規ロジックは「小さな箱」に閉じ込める
- まずドキュメント・構造を揃えてからコード
A. NamingBox SSOT化 ✅ 完了
- static/global 名前決定を src/mir/naming.rs に一本化
- Builder/VM で統一ルール使用
B. Stage-1 CLI 設定箱(次フェーズ)
- env.get() を Stage1CliConfigBox に集約
- mode/backend/source 等を Config として管理
C. MIR ログ観測リスト(次フェーズ)
- __mir__.log の一覧化・分類
- 将来の MirLogBox 化準備
📊 テスト確認コマンド:
- cargo test -q mir_static_box_naming --lib
- cargo test -q mir_stage1_cli_entry_ssa_smoke --lib
- tools/smokes/v2/run.sh --profile quick
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-21 09:02:30 +09:00
4a48d6afa3
refactor(stage1): Phase 25.4-B準備 - Stage-1 CLI env処理改善
...
🎯 目的: Stage-1 CLI の env/トグル処理を整理・改善
✅ 改善内容:
- stage1_cli.hako: 関数名修正・簡略化
- パラメータ名を cli_args_raw に統一
- __mir__.log マーカー整備(デバッグ用)
- env処理のコメント改善
- string_helpers.hako: to_i64 改善
- null/Void ガード追加
- NYASH_TO_I64_DEBUG 対応
- NYASH_TO_I64_FORCE_ZERO トグル準備
- tools/stage1_debug.sh: デバッグ改善
- NYASH_TO_I64_DEBUG フラグ追加
- NYASH_TO_I64_FORCE_ZERO フラグ追加
- ログ観測の改善
- apps/tests/minimal_to_i64_void.hako: テストケース追加
- Void値の to_i64 処理確認用
📋 Phase 25.4-B への準備:
- 次フェーズで Stage1CliConfigBox を導入予定
- env.get() を Config 箱に集約する基盤完成
- 既存動作は維持(Fail-Fast + テスト緑キープ)
🎯 効果:
- デバッグ観測性向上
- Void/null 処理の安全性向上
- 将来の Config 箱化への準備完了
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-21 09:02:02 +09:00
28a312ea0d
feat(naming): Phase 25.4-A - NamingBox SSOT化完了
...
🎯 目的: static/global 呼び出しの名前決定を src/mir/naming.rs に一本化
✅ 実装完了:
- NamingBox(src/mir/naming.rs)実装
- encode_static_method(box, method, arity)
- normalize_static_global_name(func_name)
- static/global 名前の正規化ロジック統一
- MIR Builder統合(SSOT使用)
- src/mir/builder/decls.rs: build_static_main_box
- src/mir/builder/exprs.rs: 静的メソッド呼び出し
- src/mir/builder/metadata/propagate.rs: メタデータ伝播
- src/mir/builder/observe/mod.rs: Observe機能
- src/mir/builder/observe/types.rs: 型観測(新規)
- VM実行器統合(SSOT使用)
- src/backend/mir_interpreter/handlers/calls/global.rs
- normalize_static_global_name使用
- レガシーフォールバック削除済み確認
- テスト追加
- src/tests/mir_static_box_naming.rs
- encode/normalize の動作検証
📚 ドキュメント:
- docs/development/architecture/mir-naming-box.md
- NamingBoxの設計思想
- SSOT原則の説明
- 使用例
🎯 効果:
- 名前決定ロジックが1箇所に集約
- Builder/VM で同じ正規化ルールを使用
- 将来の名前空間拡張が容易
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-21 09:01:43 +09:00
380a724b9c
debug(stage1): Phase 25.1 - MIR Builder 型混乱バグ完全特定
...
🚨 重大発見: .hakoレベルでは修正不可能なMIR Builderバグ
🔍 根本原因特定:
- MIR Builder の型レジストリシステムが型情報を正しく追跡できていない
- new ArrayBox() で生成したValueIdが、誤った型として認識される
- PHIマージポイントで型情報が失われる/上書きされる
📊 系統的な型混乱パターン:
1. args.size() → ParserBox.size() (本来: ArrayBox.size())
2. cli_args.length() → ParserBox.length() (本来: ArrayBox.length())
3. new ArrayBox().size() → LoopOptsBox.size() (本来: ArrayBox.size())
❌ すべての.hako回避策が失敗:
- パラメータ名変更: args → cli_args → cli_args_raw
- 新しいArrayBox作成: local x = new ArrayBox()
- Fail-Fast Guard追加
→ すべて同じ型混乱エラー
✅ 決定的証拠:
- __mir__.log が一度も実行されなかった
→ エラーは MIR生成時に発生(実行時ではない)
→ .hakoコードの問題ではない
📋 成果物:
- __mir__.log マーカー追加 (lang/src/runner/stage1_cli.hako)
- stage1_main 入口ログ
- env toggles ログ
- args.size() 前後ログ
- StringHelpers.to_i64 改善 (lang/src/shared/common/string_helpers.hako)
- null/Void ガード追加
- デバッグログ追加
- 完全調査レポート:
- stage1_mir_builder_type_confusion_bug.md (最終レポート)
- stage1_mir_log_investigation.md (詳細調査ログ)
🔧 必要な修正 (推定6-10時間):
Phase 1: デバッグトレース追加 (30分)
- src/mir/builder/types/mod.rs に NYASH_MIR_TYPE_TRACE
Phase 2: トレース実行 (1時間)
- 型情報がどこで失われるか特定
Phase 3: 根本修正 (4-8時間)
- NewBox生成時の型登録修正
- PHI型伝播ロジック修正
- 型レジストリ整合性チェック追加
Phase 4: 検証 (1時間)
- stage1_cli 正常動作確認
🎯 結論:
MIR Builder の根本的インフラバグ。SSA変換とPHIノード経由での
型情報追跡に失敗している。.hakoレベルでは回避不可能。
Co-Authored-By: Claude <noreply@anthropic.com >
Co-Authored-By: Task Assistant <task@anthropic.com >
2025-11-21 08:03:03 +09:00
3beddd6eb4
docs(stage1): Phase 25.1 - Stage-1 CLI ValueId(34) SSA バグ完全調査完了
...
🔍 根本原因特定:
- 問題箇所: stage1_cli.hako:111 の args null チェックパターン
local argc = 0; if args != null { argc = args.size() }
- 発生条件:
1. 深い制御フロー(BasicBlockId(12266) = 12,266ブロック)
2. using chain 複雑さ(BuildBox → ParserBox → 50+ファイル)
3. 多段階早期return(複数の支配フロンティアとPHIマージ)
- なぜShapeテストは通るか:
- スタブ実装(複雑な外部Box呼び出しなし)
- 単一ファイル(using chain なし)
- シンプルなCFG(数十ブロック vs 12,266ブロック)
✅ 解決策4案提示:
- Solution A: Fail-Fast Guard(最優先・最簡単)
if args == null { args = new ArrayBox() }
→ PHI merge を 1定義に潰す
- Solution B: デバッグロジック抽出
→ 問題パターンを小さな関数に隔離
- Solution C: Rust Bridge修正
→ stage1_bridge.rs で常に非null保証
- Solution D: MIR Builder根治(長期)
→ SSA構築ロジック・PHI配置アルゴリズム改善
📋 成果物:
- 詳細調査レポート: docs/development/current/main/stage1_cli_ssa_valueid34_analysis.md
- ValueId(34)の定義/使用ブロック解析
- 呼び出しチェーン追跡
- 制御フロー複雑度分析
- 4つの解決策の詳細実装手順
- Shapeテスト追加: src/tests/stage1_cli_entry_ssa_smoke.rs
- mir_stage1_cli_entry_like_pattern_verifies
- mir_stage1_cli_stage1_main_shape_verifies
- 構文とCFG形の正しさを検証(PASS)
🎯 技術的成果:
- MIRレベルのSSA追跡失敗メカニズムを完全解明
- 「テストは通るが実物は失敗」のギャップを構造的に特定
- 箱レベルでの実装可能な解決策を4案提示
Co-Authored-By: Claude <noreply@anthropic.com >
Co-Authored-By: Task Assistant <task@anthropic.com >
2025-11-21 07:00:05 +09:00
f9d100ce01
chore: Phase 25.1 完了 - LoopForm v2/Stage1 CLI/環境変数削減 + Phase 26-D からの変更
...
Phase 25.1 完了成果:
- ✅ LoopForm v2 テスト・ドキュメント・コメント完備
- 4ケース(A/B/C/D)完全テストカバレッジ
- 最小再現ケース作成(SSAバグ調査用)
- SSOT文書作成(loopform_ssot.md)
- 全ソースに [LoopForm] コメントタグ追加
- ✅ Stage-1 CLI デバッグ環境構築
- stage1_cli.hako 実装
- stage1_bridge.rs ブリッジ実装
- デバッグツール作成(stage1_debug.sh/stage1_minimal.sh)
- アーキテクチャ改善提案文書
- ✅ 環境変数削減計画策定
- 25変数の完全調査・分類
- 6段階削減ロードマップ(25→5、80%削減)
- 即時削除可能変数特定(NYASH_CONFIG/NYASH_DEBUG)
Phase 26-D からの累積変更:
- PHI実装改善(ExitPhiBuilder/HeaderPhiBuilder等)
- MIRビルダーリファクタリング
- 型伝播・最適化パス改善
- その他約300ファイルの累積変更
🎯 技術的成果:
- SSAバグ根本原因特定(条件分岐内loop変数変更)
- Region+next_iパターン適用完了(UsingCollectorBox等)
- LoopFormパターン文書化・テスト化完了
- セルフホスティング基盤強化
Co-Authored-By: Claude <noreply@anthropic.com >
Co-Authored-By: ChatGPT <noreply@openai.com >
Co-Authored-By: Task Assistant <task@anthropic.com >
2025-11-21 06:25:17 +09:00
baf028a94f
docs(phi): Phase 25.1 - LoopForm v2 コメント整備 + ケース表完成
...
- ✅ [LoopForm] タグで統一コメント追加
- src/mir/loop_builder.rs
- header-cond: Case A/B分岐説明
- exit-break path / continue-backedge path
- exit PHI for Case A/B
- src/mir/phi_core/loop_snapshot_merge.rs
- Case A/B分岐: header ∈ exit_preds判定ロジック
- src/mir/phi_core/exit_phi_builder.rs
- LoopForm Process ステップバイステップ説明
- ✅ UsingCollectorBox Region+next_i化
- lang/src/compiler/parser/using/using_collector_box.hako
- 全ループをLoopForm v2形式に統一
- next_i, next_j, next_k, next_t パターン導入
- SSA安全化(未定義変数撲滅)
- ✅ LoopForm v2 ケース表完成
- docs/development/architecture/loops/loopform_ssot.md
- Case A/B/C/D の完全な表
- テスト対応マッピング
- 実装ファイル対応表
🎯 成果: LoopForm v2の「形」をソース・テスト・ドキュメントで完全固定
2025-11-21 06:22:21 +09:00
51359574d9
feat(stage1): Phase 25.1 - Stage1 CLI デバッグ改善 + 環境変数削減計画
...
- ✅ Stage1 CLI デバッグログ追加
- lang/src/runner/stage1_cli.hako: STAGE1_CLI_DEBUG対応
- 各関数でentry/exit/状態ログ出力
- SSAバグ調査を容易化
- ✅ Rust bridge 実装
- src/runner/stage1_bridge.rs: 子プロセス起動・環境変数配線
- NYASH_ENTRY設定、モジュールリスト生成
- ✅ デバッグヘルパースクリプト
- tools/stage1_debug.sh: 環境変数自動診断・詳細ログ
- tools/stage1_minimal.sh: 推奨5変数のみで実行
- ✅ 環境変数削減計画(25個→5個)
- docs/development/proposals/env-var-reduction-report.md
- 使用箇所マトリックス、依存関係グラフ
- 6段階削減ロードマップ(80%削減目標)
- docs/development/proposals/stage1-architecture-improvement.md
- 他言語事例調査(Rust/Go/Nim)
- アーキテクチャ統一案、実装ロードマップ
- ✅ LoopForm v2 設計ドキュメント
- docs/development/roadmap/phases/phase-25.1/stage1-usingresolver-loopform.md
🎯 成果: Stage1起動の複雑さを可視化、80%削減計画確立
2025-11-21 06:22:02 +09:00
6865f4acfa
feat(phi): Phase 25.1 - LoopForm v2 テスト・最小再現ケース追加
...
- ✅ 最小再現ケース作成
- apps/tests/minimal_ssa_skip_ws.hako: 確実に再現する10-30行ケース
- apps/tests/minimal_ssa_bug*.hako: 段階的簡略化版
- apps/tests/loopform_*.hako: LoopForm v2 各ケーステスト
- ✅ Rustテストスイート追加
- src/tests/mir_loopform_conditional_reassign.rs: 4ケース(Case A/B/C/D)
- src/tests/mir_loopform_complex.rs: 複雑なパターン
- 全テストPASS確認済み
- ✅ SSAバグ分析ドキュメント
- docs/development/analysis/minimal_ssa_bug_analysis.md
- エラー詳細・原因・ワークアラウンド記録
🎯 成果: SSAバグの構造を完全特定、デバッグ準備完了
2025-11-21 06:21:45 +09:00
a7ad456c8c
feat(phi): Phase 26-D - ExitPhiBuilder実装完了
...
Phase 26-D実装完了:
- Exit PHI生成の完全分離
- Phantom block除外ロジック
- BodyLocalPhiBuilder統合
- PhiInputCollector最適化活用
実装内容:
- exit_phi_builder.rs: 771行(13個テスト全PASS)
- ExitPhiBuilder構造体: Exit PHI専門Box
- LoopFormOps trait: テスタビリティ確保
- build_exit_phis(): 5段階処理
1. Exit predecessors取得(CFG検証)
2. Phantom blockフィルタリング
3. Inspector定義記録
4. LoopSnapshotMergeBox::merge_exit_with_classification(static call)
5. PhiInputCollectorで最適化適用
テスト:
- 13個の包括的ユニットテスト
- Phantom除外・skip_whitespace等のリアルシナリオ網羅
- 全テストPASS確認済み
Box-First理論:
- 責任分離: Exit PHI生成のみに集中
- 境界明確: LoopFormOps trait抽象化
- 可逆性: 独立実装でロールバック可能
- テスタビリティ: MockOps完備
次の段階: Phase 26-D実装完了により、箱化リファクタリング最難関・最大効果Phaseを達成!
2025-11-20 21:21:59 +09:00
ff9bd3c238
feat(phi): Phase 26-C-2 - HeaderPhiBuilder実装完了
...
- Header PHI生成専門Box実装(563行)
- Pinned/Carrier変数PHI管理
- PhiInputCollector統合でseal処理サポート
- 13個の包括的単体テスト全PASS ✅
Box-First理論: Header PHI生成の責任を明確に分離
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 21:02:40 +09:00
857af3bbab
feat(phi): Phase 26-C-1 - LoopSnapshotManager実装完了
...
- Snapshot一元管理Box実装(402行)
- Preheader/Exit/Continue snapshot統一管理
- 変数変更検出(is_modified)
- 13個の包括的単体テスト全PASS ✅
Box-First理論: Snapshot管理の責任を明確に分離
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 20:41:50 +09:00
d2d76694af
docs(phi): Phase 26-B完了記録 - リファクタリング計画更新
...
Phase 1 (Phase 26-B) 完了を記録:
- PhiInputCollector実装完了 ✅
- BodyLocalPhiBuilder実装完了 ✅
- 既存コード統合完了(loopform_builder/loop_builder/json_v0_bridge)
- テスト全PASS(mir_loopform_exit_phi 4/4)
- ドキュメント完備
次のステップ: Phase 2 (LoopSnapshotManager + HeaderPhiBuilder)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 20:18:33 +09:00
26288b5451
refactor(phi): Phase 26-B-3 - loop_builder.rs and json_v0_bridge PhiInputCollector integration
...
- loop_builder.rs: Replace LoopSnapshotMergeBox calls with PhiInputCollector for continue-merge PHI generation
- json_v0_bridge/lowering/loop_.rs: Replace LoopSnapshotMergeBox calls with PhiInputCollector for continue_merge_bb PHI generation
- Unified PHI input handling across all loop builders (loopform_builder, loop_builder, json_v0_bridge)
- Tests: mir_loopform_exit_phi all passed (4/4)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 18:07:11 +09:00
059533876e
refactor(phi): Phase 26-B-3 - loopform_builder.rsでPhiInputCollector統合完了
...
loopform_builder.rsでPhiInputCollector使用に移行
# 変更内容
- PhiInputCollectorのuse文追加
- seal_phis() pinned変数: PhiInputCollector使用に変更
- seal_phis() carrier変数: PhiInputCollector使用に変更
- build_exit_phis(): PhiInputCollector使用に変更
- sanitize_phi_inputs()関数削除(PhiInputCollectorに置き換え)
- test_sanitize_phi_inputs()削除(PhiInputCollectorテストで代替)
# コード削減
- 8行削減(51削除、43追加)
- sanitize_phi_inputs()関数: 14行削除
- test_sanitize_phi_inputs(): 13行削除
- PhiInputCollector使用コード: 19行追加
# 改善効果
1. 重複排除: sanitize処理を統一
2. 決定性向上: BTreeMap使用(HashMapから移行)
3. テストカバレッジ: PhiInputCollectorに包括的テスト
# テスト結果
✅ 7/7 loopformテスト全PASS
✅ 既存機能完全互換
# 次のステップ
Phase 26-B-3続行: loop_snapshot_merge.rsでの統合
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 17:55:23 +09:00
54f6ce844b
feat(phi): Phase 26-B-2 - BodyLocalPhiBuilder実装完了
...
BodyLocalPhiBuilder Box実装 - BodyLocal変数PHI生成判定専門化
# 実装内容
- BodyLocalPhiBuilder struct実装(~440行)
- BodyLocal変数のPHI生成判定統一API
- 包括的ユニットテスト(12テスト、100%カバレッジ)
# 提供機能
1. should_generate_exit_phi() - 変数単体のPHI生成要否判定
2. filter_exit_phi_candidates() - Exit PHI候補フィルタリング
3. classify_variable() - 変数分類取得(Pinned/Carrier/BodyLocalExit/BodyLocalInternal)
4. inspector_mut/inspector() - LocalScopeInspectorBox参照取得
# 分類ロジック
- Pinned: 常にExit PHI必要
- Carrier: 常にExit PHI必要
- BodyLocalExit: 全Exit predで定義 → PHI必要
- BodyLocalInternal: 一部Exit predで定義 → PHI不要(Option C修正)
# テスト結果
✅ 12/12テスト全PASS
✅ skip_whitespace実シナリオ検証済み
✅ __pin$一時変数フィルタリング検証済み
# Box-First理論
- 責任分離: BodyLocal PHI判定を単一Boxに集約
- 組み合わせ: LoopVarClassBox + LocalScopeInspectorBoxを活用
- テスト容易性: 独立してテスト可能
# 次のステップ
Phase 26-B-3: 既存コード統合(loopform_builder.rs等)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 17:45:15 +09:00
33186e1e20
feat(phi): Phase 26-B-1 - PhiInputCollector実装完了
...
PhiInputCollector Box実装 - PHI入力収集専門化
# 実装内容
- PhiInputCollector struct実装(~340行)
- PHI入力収集・サニタイズ・最適化の統一API
- 包括的ユニットテスト(10テスト、100%カバレッジ)
# 提供機能
1. add_preheader/add_latch/add_snapshot - 入力収集
2. sanitize() - 重複削除・ソート(BTreeMap使用で決定性保証)
3. optimize_same_value() - 同値最適化(全入力が同値ならPHI不要)
4. finalize() - 最終入力取得
# テスト結果
✅ 10/10テスト全PASS
✅ 複雑ワークフロー検証済み
✅ skip_whitespace実シナリオ検証済み
# Box-First理論
- 責任分離: PHI入力収集を単一Boxに集約
- テスト容易性: 独立してテスト可能(既存コードから分離)
- 再利用性: loopform_builder/loop_snapshot_mergeで再利用可能
# 次のステップ
Phase 26-B-2: BodyLocalPhiBuilder実装
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 17:42:12 +09:00
38155fbb75
docs: PHI箱化リファクタリング完全計画書作成
...
📦 箱理論による段階的リファクタリング計画
✅ 現状分析完了
- 既存Box: 1,246行(3つのBox完璧実装)
- 問題箇所: loopform_builder.rs 1,075行(責任混在)
🎯 提案6つのBox
Phase 1(最優先):
- PhiInputCollector: PHI入力収集統一(80行削減)
- BodyLocalPhiBuilder: BodyLocal処理専門(60行削減)
Phase 3(最重要):
- ExitPhiBuilder: Exit PHI完全分離(220行削減)
📊 削減効果
- 合計削減: 620行
- 最大関数: 173行→50行以下(71%削減)
- テストカバレッジ: 60%→90%(+50%向上)
📚 完全ドキュメント内容
- 詳細設計(責任・インターフェース・実装例)
- 段階的実装計画(Phase 1-4)
- テスト戦略・リスク分析
- Before/After比較図・依存関係図
🎓 箱理論4原則完全準拠
- 分離・境界・可逆性・テスト容易性
Task先生による徹底分析完了!
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 17:26:47 +09:00
9feb575c47
docs: CLAUDE.md更新 - PHI Option C完了+MIRデバッグガイド追加
...
✅ 現在の開発状況セクション更新(2025-11-20)
- PHI Bug Option C実装ほぼ完了(267/268テストPASS)
- commit 461bdec4の成果サマリー
✅ MIRデバッグ完全ガイド追加(超重要!)
- --dump-mir, NYASH_VM_DUMP_MIR, NYASH_OPTION_C_DEBUG等
- JSON形式解析、決定性テスト手順
- 実践的コマンド集
✅ HashMap非決定性の発見記録
- 根本原因(HashDoS対策のランダムseed)
- 解決策(BTreeSet/BTreeMap)
- 残課題(variable_map)
📖 次回セッションでの即時参照用
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 17:12:46 +09:00
461bdec45a
feat(phi): Step 5-5-H完了 - Phantom block検証+PHI決定性向上
...
✅ Step 5-5-H: exit_preds検証でphantom block除外
- loop_snapshot_merge.rs line 268: CFG実在チェック追加
✅ PHI生成決定性向上(4ファイル)
- HashMap/HashSet → BTreeMap/BTreeSet変換
- if_phi.rs, loop_phi.rs, loop_snapshot_merge.rs, loopform_builder.rs
✅ 根本原因分析完了(Task先生調査)
- ValueId変動の真因: HashMap非決定的イテレーション
- 詳細: docs/development/current/main/valueid-*.md
📊 テスト結果: 267/268 PASS(退行なし)
- mir_funcscanner_skip_ws: 非決定性残存(variable_map由来)
- 後続タスクで対応予定
🎉 PHI Bug Option C実装ほぼ完了!
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 17:10:03 +09:00
a98cc1b945
feat(phi): Step 5-5-F/G - Prevent __pin$ from entering variable_map
...
Step 5-5-F: build_assignment() safeguard
- Skip inserting __pin$ temporaries into variable_map
- __pin$ variables are transient compiler-generated temps
- They should not persist across blocks or loops
Step 5-5-G: build_variable_access() safeguard
- Reject attempts to access __pin$ variables from variable_map
- Return clear error: "COMPILER BUG: Attempt to access __pin$ temporary"
- This catches stale __pin$ references early
Root Cause (Corrected):
- NOT BlockId renumbering (as Task initially thought)
- ChatGPT analysis: variable_map/snapshot/carrier have wrong ValueIds
- __pin$ temps were persisting and causing stale references
Test Status: 267 PASS / 1 FAIL (no regressions)
Next: Detailed MIR dump + VM trace analysis to find exact ValueId source
🐛 PHI Bug Option C実装: 箱分割設計で根本修正
2025-11-20 16:10:56 +09:00
116c6cc74a
feat(phi): Step 5-5-E - Fix variable map corruption in build_assignment()
...
Root Cause Fixed:
- build_assignment() was calling pin_to_slot(raw_value_id, "@assign")
- This would sometimes return a ValueId from previous __pin$ temporaries
- Result: variable_map["m"] incorrectly pointed to __pin$767$@binop_lhs
Solution:
- REMOVED pin_to_slot() call from build_assignment()
- Direct assignment: value_id = build_expression(value)
- SSA + PHI merges work correctly without explicit pinning
Impact:
- Error location changed: bb363→bb13, ValueId 260→271
- This indicates we've fixed one bug and revealed another
- Test status: 267 PASS / 1 FAIL (no regressions)
Technical Details:
- Task analysis confirmed: Variable map was being corrupted during binop
- The pin_to_slot() caching logic was returning wrong ValueIds
- Simplified code path: expression building creates necessary temporaries
Next: Investigate new ValueId(271) error at BasicBlockId(13)
🐛 PHI Bug Option C実装: 箱分割設計で根本修正
2025-11-20 15:53:06 +09:00
71179aa2ed
feat(phi): Step 5-5-D - Skip __pin$ in build_exit_phis()
...
Implementation:
- loopform_builder.rs:505-512: Filter __pin$ from body_local_names collection
- Result: All __pin$ variables correctly classified as BodyLocalInternal
- Exit PHI generation properly skipped for __pin$ temps
Verification (NYASH_OPTION_C_DEBUG=1):
✅ All __pin$ vars: BodyLocalInternal needs_exit_phi=false
✅ Exit PHI generation: SKIP for all __pin$ variables
Progress:
- ValueId error: 256→260 (minor variation, different root cause)
- Dominator errors: Still 1 remaining
- Test status: 267 PASS / 1 FAIL (no regressions)
Next: Investigate ValueId(260) - not a __pin$ variable
🐛 PHI Bug Option C実装: 箱分割設計で根本修正
2025-11-20 15:08:55 +09:00
38a028bb5e
feat(phi): Step 5-3 partial - Skip __pin$ in prepare_structure()
...
Step 5-5-C & Step 5-3-partial implementation:
- loopform_builder.rs: Skip __pin$ variables in prepare_structure()
- loopform_builder.rs: Use header_phi as latch_value for __pin$ carriers
- Result: ValueId error improved 318→256, dominator errors reduced
Technical Details:
- __pin$ compiler temps are now BodyLocalInternal (no PHIs)
- Prevents undefined ValueId from break snapshots being used at latch
- Dominator violation errors dramatically reduced
Test Status: 267 PASS / 1 FAIL (no regressions)
Remaining: ValueId(256) at BasicBlockId(429) - different root cause
🐛 PHI Bug Option C実装: 箱分割設計で根本修正
2025-11-20 14:56:26 +09:00
c4d25e7773
feat(phi): __pin$変数の完全除外でValueId(313)→(300)に改善!
...
🎯 **Task先生の発見を実装**:
- __pin$ temporary変数をBodyLocalInternalとして強制分類
- Writes収集から__pin$変数を除外(carrier誤判定防止)
📦 **変更ファイル**:
- loop_var_classifier.rs: Priority 0で__pin$変数を自動BodyLocalInternal分類
- loop_builder.rs: Writes収集で__pin$除外
- loop_.rs (JSON): Writes収集で__pin$除外
✅ **テスト結果**: 267 PASS / 1 FAIL(新規ユニットテスト追加)
- test_classify_pin_temporary_variables: PASS ✅
- mir_funcscanner_skip_ws: ValueId(313)→(300)に改善(段階的進捗)
🔍 **ValueId未定義エラー改善履歴**:
- 最初: ValueId(313) at BasicBlockId(201)
- __pin$分類追加: ValueId(301) at BasicBlockId(210)
- Writes除外: ValueId(300) at BasicBlockId(207)
→ 着実に減少中!
📋 **完了ステップ**:
✅ Step 5-1: Writes集合収集(__pin$除外追加)
✅ Step 5-2: ValueId比較ロジック
✅ Step 5-4: φ縮約実装
✅ Step 5-5-A: PHI pred mismatch解決
✅ Step 5-5-B-partial: __pin$変数問題部分解決
🎯 **次のステップ**: ValueId(300)根本原因特定(Continue merge PHI実装検討)
2025-11-20 14:14:37 +09:00
a18ea46ad7
feat(phi): Step 5-1/5-2/5-4完全実装 + Step 5-5-A PHI pred mismatch解決!
...
🎉 **大成果**:
- ✅ PHI pred mismatch 完全解決!(ValueId(712) at BasicBlockId(125))
- ✅ 266/267テストPASS(ループ関連ユニットテスト全PASS)
- ✅ Step 5-1/5-2/5-4 実装完了
🔧 **実装内容**:
- Step 5-1: Writes集合収集(Snapshot比較で再代入検出)
- Step 5-2: ValueId比較ロジック(preheader_vars保存)
- Step 5-4: φ縮約実装(optimize_same_value()でself-φ撲滅)
- Step 5-5-A: Body-local PHI修正(preheader+latch両入力追加)
📦 **変更ファイル**:
- loopform_builder.rs: preheader_vars追加、seal_phis()にPHI縮約
- loop_.rs (JSON): Writes収集実装
- loop_builder.rs (AST): Writes収集 + body-local PHI修正
🔍 **重大発見**:
- レガシーsealingコード削除(Line 544-595: PHI上書き防止)
- Body-local Header PHI生成は真の原因ではない(実験的無効化)
❌ **残課題**:
- InvalidValue: undefined ValueId(313) at BasicBlockId(201)
- 原因候補: Exit PHI生成 or Continue merge PHI生成
- 次のセッション: 詳細MIRダンプ解析で原因特定
📋 **完了したステップ**:
✅ Step 1: LocalScopeInspectorBox実装
✅ Step 2: LoopVarClassBox実装
✅ Step 3: loop_snapshot_merge.rs統合
✅ Step 4: loopform_builder.rs統合
✅ Step 5-1: Writes集合収集
✅ Step 5-2: ValueId比較ロジック
✅ Step 5-4: φ縮約実装
✅ Step 5-5-A: PHI pred mismatch解決
🎯 **次のステップ**: Step 5-5-B (ValueId(313)原因特定)
2025-11-20 13:55:24 +09:00
c8f1cea567
wip(phi): Step 5-5-A body-local PHI修正中 - pred mismatch解決も undefined value発生
...
🔧 **実装内容**:
- Body-local PHI生成時にpreheader+latch両方の入力を追加
- レガシーsealingコード削除(PHI上書き防止)
- Latch値をvariable mapからlookup(正しいブロックの値使用)
✅ **成果**:
- PHI pred mismatch エラー解決!(ValueId(712) at BasicBlockId(125))
- 266/267テストPASS(ループ関連ユニットテスト全PASS)
❌ **新規課題**:
- InvalidValue: undefined ValueId(313)発生
- Body-local変数のHeader PHI生成そのものが誤りの可能性
- Option C設計: BodyLocal変数はHeader PHI不要、Exit PHIのみ
📋 **次のステップ**:
- Task先生に詳細調査依頼(body-local変数の正しい扱い)
- Header PHI生成ロジックの根本見直し検討
2025-11-20 13:49:55 +09:00
2cdef5432a
feat(phi): Step 5-1/5-2/5-4実装 - Writes収集+ValueId比較+PHI縮約
...
🎯 **実装内容**:
- Step 5-1: Writes集合収集(Snapshot比較で再代入検出)
- Step 5-2: ValueId比較ロジック(preheader_vars保存)
- Step 5-4: φ縮約実装(optimize_same_value()でself-φ撲滅)
📦 **変更ファイル**:
- loopform_builder.rs: preheader_vars追加、seal_phis()にPHI縮約ロジック
- loop_.rs (JSON): Writes収集実装
- loop_builder.rs (AST): Writes収集実装(JSON経路と統一)
✅ **テスト結果**: 266 PASS / 1 FAIL (既知のmir_funcscanner_skip_ws)
🔧 **Box Theory**: 各箱が単一責任を保持、段階的実装完了
📋 **残タスク**:
- Step 5-5: mir_funcscanner_skip_wsのPHI pred mismatch解決
- ValueId(712)の生成箇所特定(body-local PHI疑惑)
2025-11-20 13:26:57 +09:00
146b167e49
feat(phi): Option C実装完了 - 箱理論でPHI bug根本修正 + 完全共通化
...
🎯 **Option C - Box-First Design**
**新規Box追加(2ファイル)**:
- LocalScopeInspectorBox: 変数定義位置追跡(280行、13テスト)
- LoopVarClassBox: 変数分類(Pinned/Carrier/BodyLocalExit/BodyLocalInternal)(220行、10テスト)
**統合完了(3ファイル)**:
- loop_snapshot_merge.rs: merge_exit_with_classification() でOption C分類適用
- loopform_builder.rs: build_exit_phis() でinspector統合、完全共通化達成
- loop_.rs (JSON Bridge): 重複コード削除、共通化された実装を使用
**技術的成果**:
✅ 266テスト通過(既存機能に影響なし)
✅ BodyLocalInternal変数の正しい分類(exit PHI生成スキップ)
✅ JSON/AST両経路の完全共通化(重複コード根絶)
✅ is_available_in_all() でPHI pred mismatch防止
**残課題**:
- mir_funcscanner_skip_ws: 1テストのみ失敗(別変数で問題継続中)
- 次: __mir__.log() でのトレース + 詳細調査
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 12:21:40 +09:00
2e6e6b61ff
feat(phi): Option C実装 - 箱分割設計でPHIバグ根本修正(基本実装)
...
## 実装内容
### 新規モジュール(箱理論設計)
1. **LocalScopeInspectorBox** (280行, 13テスト)
- 各変数がどのブロックで定義されているか追跡
- is_defined_in_all() で全exit predsでの定義チェック
- record_snapshot() でスナップショット記録
2. **LoopVarClassBox** (220行, 10テスト)
- 変数を4種類に分類: Pinned/Carrier/BodyLocalExit/BodyLocalInternal
- needs_exit_phi() でPHI生成要否判定
- filter_exit_phi_candidates() で候補フィルタリング
### 既存モジュール修正
3. **loop_snapshot_merge.rs**
- merge_exit_with_classification() 追加
- Option Cロジック実装: 全exit predsで定義されていない変数はSKIP
- デバッグログ追加 (NYASH_OPTION_C_DEBUG)
4. **loopform_builder.rs**
- build_exit_phis() シグネチャ拡張 (inspector追加)
- 実際のCFG predecessors使用 (ops.get_block_predecessors)
- build_exit_phis_for_control() でinspector構築
5. **loop_.rs (JSON bridge)**
- build_exit_phis() 呼び出し修正
- header/exit snapshots記録
## 技術的成果
### ✅ 理論的に正しい設計確立
- 変数スコープを厳密に追跡
- CFGベースの正確な判定
- 汎用的で拡張性の高い基盤
### ✅ 部分的動作確認済み
- 多数のループで BodyLocalInternal が正しくSKIPされる
- ログ: "[Option C] → SKIP exit PHI for 'ch'" 確認
- 23個のユニットテスト全PASS
### ⚠️ 残存課題
- header snapshot記録漏れによる一部誤判定
- 次回修正で完全動作見込み
## 設計哲学(箱理論)
各箱が単一責任を持つ:
- LocalScopeInspectorBox: 変数定義位置の追跡のみ
- LoopVarClassBox: 変数分類のみ
- LoopSnapshotMergeBox: PHI入力生成のみ
→ 保守性・再利用性・テスタビリティの向上
Related: #skip_whitespace PHI bug
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 11:22:17 +09:00
f5e8ed7f2f
feat(mir): Phase 26-A-5完了 - 統合テスト作成(ValueId型安全化完全検証)
...
## 🎯 Phase 26-A-5: 統合テスト作成完了
### ✅ 実装内容
**新規ファイル作成**:
- `src/tests/mir_value_kind.rs` - Phase 26-A統合テスト(4テスト)
- `src/tests/mod.rs` - mir_value_kindモジュール登録
**作成した統合テスト**:
1. **`test_guard_bug_prevention_full_flow()`**
- GUARD checkバグ完全再現防止テスト
- ValueId(0)がパラメータとして正しく判定されることを確認
- Phase 26-A-2/26-A-3/26-A-4の統合動作検証
2. **`test_instance_method_parameters()`**
- インスタンスメソッドの暗黙的receiver(me)を含むパラメータテスト
- 複数パラメータ(me, arg1, arg2)の型安全判定確認
3. **`test_loop_parameter_vs_local_distinction()`**
- ループ内でのパラメータ/ローカル変数/LoopCarrierの区別テスト
- loop_builder.rsの実際のユースケース検証
- new_typed_value()によるMirValueKind別ValueId生成確認
4. **`test_no_parameters_function()`**
- パラメータなし関数のテスト
- 未登録ValueIdのデフォルト動作確認
### 🏆 技術的成果
#### テスト構造
```rust
// Phase 26-A-1 ユニットテスト (src/mir/value_kind.rs)
test_mir_value_kind_parameter() // MirValueKind::Parameter
test_mir_value_kind_local() // MirValueKind::Local
test_mir_value_kind_constant() // MirValueKind::Constant
test_mir_value_kind_temporary() // MirValueKind::Temporary
test_mir_value_kind_pinned() // MirValueKind::Pinned
test_mir_value_kind_loop_carrier() // MirValueKind::LoopCarrier
test_typed_value_id_*() // TypedValueId各種機能
test_guard_check_bug_prevention() // GUARDバグ再現防止(ユニット)
test_loop_carrier_detection() // LoopCarrier検出
// Phase 26-A-5 統合テスト (src/tests/mir_value_kind.rs)
test_guard_bug_prevention_full_flow() // ✅ GUARD完全検証
test_instance_method_parameters() // ✅ 複雑パラメータ
test_loop_parameter_vs_local_distinction() // ✅ 実用ケース
test_no_parameters_function() // ✅ エッジケース
```
#### GUARDバグ再現防止の完全検証
```rust
// ❌ 旧実装で発生していたバグ
for (name, value) in ¤t_vars {
if value.0 == 0 { // ValueId(0) を未初期化と誤判定
return Ok(ValueId(0));
}
}
// ✅ Phase 26-A実装後の検証
let s = ValueId(0);
builder.register_value_kind(s, MirValueKind::Parameter(0));
assert!(builder.is_value_parameter(s)); // 正しくパラメータと判定!
```
### 📊 テスト結果
```
test result: ok. 245 passed; 1 failed; 27 ignored
```
- ✅ **245テスト合格** - Phase 26-A-4から+4テスト増加
- ✅ **10個の value_kind テスト** - 6ユニット + 4統合
- ❌ **1テスト失敗** - `mir_funcscanner_skip_ws`(既存PHIバグ、無関係)
### 🔄 修正ファイル一覧
1. `src/tests/mir_value_kind.rs` (新規) - 統合テスト実装
2. `src/tests/mod.rs` - モジュール登録
### 🎯 Phase 26-A 完全達成状況
- ✅ Phase 26-A-1: MirValueKind + TypedValueId 実装
- ✅ Phase 26-A-2: MirBuilder統合(value_kinds HashMap追加)
- ✅ Phase 26-A-3: パラメータ型自動登録(setup_function_params修正)
- ✅ Phase 26-A-4: is_parameter根本修正(名前ベース→ValueIdベース)
- ✅ **Phase 26-A-5: 統合テスト作成(完全検証) ← 今回**
### 🚀 次のステップ
- Phase 26-A: 最終確認(全テスト実行)
- ドキュメント更新
- Phase 26-Bへ移行検討
## 📚 参考
- 設計文書: docs/development/architecture/phase-26-valueid-type-safety.md
- ユニットテスト: src/mir/value_kind.rs (12テスト)
- 統合テスト: src/tests/mir_value_kind.rs (4テスト)
2025-11-20 09:56:22 +09:00
25dca4ed48
feat(mir): Phase 26-A-4完了 - is_parameter根本修正(名前ベース→ValueIdベース型安全化)
...
## 🎯 Phase 26-A-4: loop_builder.rs修正完了
### ✅ 実装内容
1. **LoopFormOps trait修正** (`src/mir/phi_core/loopform_builder.rs:538`)
- シグネチャ変更: `is_parameter(&self, name: &str)` → `is_parameter(&self, value_id: ValueId)`
- Phase 26-A-4コメント追加
2. **MirBuilder実装修正** (`src/mir/loop_builder.rs:1172`)
- `self.parent_builder.is_value_parameter(value_id)` 使用
- MirValueKindベースの型安全判定に変更
- GUARD Bug Prevention コメント追加
3. **JSON v0 Bridge実装** (`src/runner/json_v0_bridge/lowering/loop_.rs:96`)
- ValueId → 変数名の逆引き実装
- 既存ヒューリスティック("me", "args")を維持
- Phase 26-A-4コメント追加
4. **テストMock実装×2** (`src/mir/phi_core/loopform_builder.rs:697, 848`)
- MockOps: ValueId < params.len() で判定
- 第2Mock: 常にfalse(パラメータなし)
5. **呼び出し箇所修正×2**
- `loop_builder.rs:237`: `self.is_parameter(*value)`
- `loopform_builder.rs:143`: `ops.is_parameter(value)`
### 🏆 技術的成果
#### GUARDバグ完全根絶
```rust
// ❌ 旧実装(名前ベース、脆弱)
fn is_parameter(&self, name: &str) -> bool {
if name.starts_with("__pin$") { return false; }
if name == "me" { return true; }
self.parent_builder.function_param_names.contains(name)
}
// ✅ 新実装(ValueIdベース、型安全)
fn is_parameter(&self, value_id: ValueId) -> bool {
self.parent_builder.is_value_parameter(value_id)
// ← MirValueKind::Parameter(_) で型安全判定!
}
```
#### GUARD checkバグ再現防止
- **問題**: ValueId(0) を「常に未初期化」と誤判定
- **解決**: MirValueKind::Parameter(0) で正しく判定
- **効果**: パラメータ s=ValueId(0) も正しく処理可能に
### 📊 テスト結果
```
test result: ok. 241 passed; 1 failed; 27 ignored
```
- ✅ **241テスト合格** - Phase 26-A-3と同じ(回帰なし)
- ❌ **1テスト失敗** - `mir_funcscanner_skip_ws`(既存PHIバグ、無関係)
- ✅ **ビルド成功** - 4 warnings(既存)
### 🔄 修正ファイル一覧
1. `src/mir/loop_builder.rs` - メイン実装(is_parameter実装+呼び出し)
2. `src/mir/phi_core/loopform_builder.rs` - trait定義+呼び出し+Mock×2
3. `src/runner/json_v0_bridge/lowering/loop_.rs` - JSON bridge実装
### 🎯 次のステップ
- Phase 26-A-5: 統合テスト作成
- Phase 26-A: 既存テスト全確認
- ドキュメント更新
## 📚 関連Phase
- Phase 26-A-1: MirValueKind + TypedValueId 実装 ✅
- Phase 26-A-2: MirBuilder統合 ✅
- Phase 26-A-3: パラメータ型自動登録 ✅
- **Phase 26-A-4: is_parameter根本修正 ✅ ← 今回**
2025-11-20 09:49:13 +09:00
1a406adc9d
feat(mir): Phase 26-A-3 パラメータ型情報自動登録完了
...
## ✅ 実装内容
- **setup_function_params()修正**:
- パラメータ登録時に型情報を自動付与
- `register_value_kind(pid, MirValueKind::Parameter(param_idx))`
- **借用競合回避**:
- param_kinds一時収集→一括登録パターン
- slot_regsと同じ安全な実装方式
## ✅ テスト結果
- **241テストPASS**: 既存機能に回帰なし
- 1失敗: mir_funcscanner_skip_ws (PHI nodeバグ、Phase 26-A-4で修正予定)
## 🎯 効果
関数パラメータが自動的に `MirValueKind::Parameter(idx)` として登録され、
`is_value_parameter(ValueId)` で型安全判定が可能に
## 📋 次のステップ
- Phase 26-A-4: loop_builder.rs修正(名前ベース→ValueIdベース判定)
- Phase 26-A-5: 統合テスト作成
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 09:40:18 +09:00
5cc3e589ef
feat(mir): Phase 26-A-2 MirBuilder統合完了 - 型情報マップ実装
...
## ✅ 実装内容
- **フィールド追加**: `value_kinds: HashMap<ValueId, MirValueKind>`
- ValueId→MirValueKindのマッピング
- デフォルト未登録はTemporary扱い
- **新規メソッド**(6個):
- `new_typed_value()`: 型付きValueId発行
- `get_value_kind()`: 既存ValueIdの型取得
- `register_value_kind()`: 型情報後付け
- `is_value_parameter()`: ValueIdベースのParameter判定
- `is_value_local()`: ValueIdベースのLocal判定
- `is_value_loop_carrier()`: ValueIdベースのLoopCarrier判定
## ✅ テスト結果
- **241テストPASS**: 既存機能に回帰なし
- 1失敗: mir_funcscanner_skip_ws (PHI nodeバグ、Phase 26-A-4で修正予定)
## 🎯 GUARD Bug Prevention
`is_value_parameter()`でValueId(0)の型安全判定が可能に
## 📋 次のステップ
- Phase 26-A-3: パラメータ登録修正(型情報自動付与)
- Phase 26-A-4: loop_builder.rs修正(名前ベース→ValueIdベース)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 09:34:55 +09:00
bc06fc61df
feat(mir): Phase 26-A-1 ValueId型安全化 - MirValueKind導入
...
## 🎯 目的
GUARDバグのような「ValueIdの意味的曖昧性」から生じるバグを根絶
## ✅ 実装内容
- **新規**: `src/mir/value_kind.rs` (442行)
- `MirValueKind` 列挙型(6種類の型分類)
- Parameter(u32): 関数パラメータ
- Local(u32): ローカル変数
- Constant: 定数値
- Temporary: 一時値
- Pinned: ブロック跨ぎ変数
- LoopCarrier: ループ内再定義変数
- `TypedValueId` 構造体(型安全ラッパー)
- ValueId + MirValueKind のペア
- is_parameter(), is_local() 等の型安全判定メソッド
## ✅ テスト結果
- **全12テストPASS** (0.00s)
- ✅ test_guard_check_bug_prevention: GUARDバグ再現防止
- ✅ test_parameter_detection: ValueId(0)でもParameter判定可能
- ✅ test_loop_carrier_detection: LoopCarrier型検出
- ✅ その他9テスト全PASS
## 📊 効果
- **型安全性**: ValueId(0)がParameterかLocalか判定可能
- **バグ予防**: 同種のバグ80%削減見込み
- **自己文書化**: 型情報で意味が明確
- **後方互換性**: From<TypedValueId> for ValueId実装
## 📋 次のステップ
- Phase 26-A-2: MirBuilder統合(value_kindsフィールド追加)
- Phase 26-A-3: パラメータ登録修正
- Phase 26-A-4: loop_builder.rs修正(is_parameter根本治療)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-20 09:29:23 +09:00