Commit Graph

214 Commits

Author SHA1 Message Date
58c5d8c9bc feat(joinir): Phase 66-68 GenericTypeResolver + JoinIR First Chapter Wrap
Phase 66: P3-C ジェネリック型推論箱化
- generic_type_resolver.rs 新設 (180行)
  - is_generic_method(): ArrayBox.get/pop/first/last, MapBox.get 判定
  - resolve_from_phi(): PHI解析によるジェネリック型推論
- TypeHintPolicy::is_p3c_target() 追加
  - P1/P2/P3-A/P3-B 以外を P3-C 候補として判定

Phase 67: P3-C 実利用への一歩
- phase67_generic_type_resolver.rs テスト追加 (3テスト)
- lifecycle.rs に P3-C 経路フック追加
  - GenericTypeResolver を P3-C 対象関数で優先使用
- A/B テストで旧経路との一致確認 (11 tests PASS)

Phase 68: JoinIR First Chapter Wrap (ドキュメント整理)
- 68-1: phase-30 README.md に Section 9 追加 (JoinIR 第1章完了サマリー)
- 68-2: README.md に JoinIR status セクション追加
- 68-3: CURRENT_TASK.md スリム化 (351→132行, 62%削減)
- 68-4: PHI_BOX_INVENTORY.md に Phase 66-67 完了セクション追加

Phase 69-1: Trio 棚卸し
- phase69-1-trio-inventory.md 作成
- Trio 使用箇所の完全棚卸し完了 (削減見込み 457-707行)

🐱 JoinIR 第1章完了!4つの柱確立:
- Structure (LoopForm)
- Scope (LoopScopeShape)
- JoinIR (Select/IfMerge/Loop)
- Type Hints (P1-P3-C)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-30 08:54:18 +09:00
0c23bc0788 docs: Phase 61-5 If PHI 棚卸し完了
Phase 61-5: If PHI 残りパターン棚卸しと削減計画策定

New docs:
- phase61-5-3-if-phi-priority-table.md: P1/P2/P3 優先度表
  - P1: 18関数(薄いラッパー削除候補)
  - P2: 5関数(JoinIR 拡張統合候補)
  - P3: 3関数(型システム統合待ち)

- phase61-5.4-next-phase-candidates.md: Phase 61-6 削減候補(3個)
  - Wave 1: set_if_context 削除(11行)、dev フラグ削除(15行)
  - Wave 2: A/B テスト削除(50行)
  - 合計削減見込み: 76行

- phase61-5-summary.md: Phase 61-5 全体サマリー
  - JoinIR カバー率: 完全28.6% + 部分57.1% = 85.7%
  - Phase 61-6 実装準備完了

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-29 15:57:14 +09:00
588129db65 feat(joinir): Phase 34-6 MethodCall 構造と本物の substring 意味論
**Phase 34-6 実装完了**: MethodCall 構造を JoinIR に追加し、本物の substring
呼び出しを通すことに成功。

## 主要変更

### 1. MethodCall 構造追加 (34-6.1)
- `src/mir/join_ir/mod.rs`: JoinInst::MethodCall バリアント (+8 lines)
  - 構造: `{ dst, receiver, method, args }`
  - 設計原則: JoinIR は構造のみ、意味論は MIR レベル

### 2. extract_value 更新 (34-6.2)
- `src/mir/join_ir/frontend/ast_lowerer.rs`: Method 処理本物化 (+37 lines)
  - receiver/args を extract_value で再帰処理
  - ダミー Const(0) 削除 → 本物の MethodCall 生成
  - cond 処理修正: ValueId(0) ハードコード → extract_value で取得

### 3. JoinIR→MIR 変換実装 (34-6.3)
- `src/mir/join_ir_vm_bridge.rs`: MethodCall → BoxCall 変換 (+12 lines)
- `src/mir/join_ir/json.rs`: MethodCall JSON シリアライゼーション (+16 lines)
- `src/mir/join_ir_runner.rs`: MethodCall 未対応エラー (+7 lines)

### 4. テスト更新 (34-6.4)
- `docs/.../fixtures/json_shape_read_value.program.json`: 本物の substring 構造
- `src/tests/joinir_frontend_if_select.rs`: run_joinir_via_vm 使用
- テスト成功: v="hello", at=3 → "hel" 

## 成果

-  テスト全通過(1 passed; 0 failed)
-  設計原則確立: JoinIR = 構造 SSOT、意味論 = MIR レベル
-  Phase 33-10 原則との整合性: Method でも同じ原則適用

**ドキュメント更新**: CURRENT_TASK.md + TASKS.md(Phase 34-6 完了記録)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-27 17:05:46 +09:00
8750186e55 chore: Phase 26-H セッション完了 - 全ドキュメント更新
Phase 26-H 完了内容:
 JoinIR 型定義実装(src/mir/join_ir.rs)
 MIR → JoinIR 自動変換実装(lower_min_loop_to_joinir)
 自動変換テスト実装(mir_joinir_min_auto_lowering)
 PHI/Loop箱 → JoinIR 移行対応表追加(loopform_ssot.md)

ドキュメント更新:
- Phase 27 JoinIR タスク計画追加
- Phase 26-H タスク完了記録
- 各種 README 更新(進捗反映)
- CURRENT_TASK.md 更新

コミット統計: $(git status --short | wc -l) files changed

次のステップ: Phase 27 一般化 MIR → JoinIR 変換
2025-11-23 05:53:27 +09:00
6815065e72 docs: Phase 21.7++ チェックリスト最終更新 - コミットハッシュ記録
Phase 3 と Phase 4 のコミットハッシュを TBD から実際の値に更新:
- Phase 3: c8ad1dae (全体統一)
- Phase 4: 806e4d72 (ドキュメント整備)

Phase 21.7++ 全フェーズ完全完了!🎊

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-22 02:54:44 +09:00
806e4d72c4 docs(phase21.7): Phase 21.7++ Phase 4完了 - ドキュメント整備
## Phase 4 実装内容

### Phase 4.1: README 更新
- docs/development/roadmap/phases/phase-21.7-normalization/README.md
  - "Phase 21.7++ 実装完了" セクション追加(60行)
  - SSOT ルール・実装箇所・デバッグ環境変数を文書化
  - 全4フェーズの完了状況をコミットハッシュ付きで記録
  - 技術的成果の総括(Silent Failure根絶、arity バグ根治等)

### Phase 4.2: トラブルシューティングガイド作成
- docs/development/troubleshooting/using-resolution.md(新規作成、200+行)
  - 4つのエラーパターン別対処法
  - デバッグフローチャート
  - FAQ セクション
  - Phase 21.7++ 実装前後の比較表

### チェックリスト更新
- docs/development/current/main/phase-21.7-naming-ssot-checklist.md
  - Phase 0-4 完了状況サマリー追加
  - 累計工数: 10時間(進捗率: 50-67%)

## 技術的成果サマリー

 **Phase 0**: Silent Failure 根絶(時間→分)
 **Phase 1**: StaticMethodId SSOT 確立
 **Phase 2**: arity バグ根治(Hotfix 卒業)
 **Phase 3**: 素手 split 根絶(Builder 統一)
 **Phase 4**: ドキュメント整備(再発防止)

**Phase 21.7++ 全フェーズ完了!** 🎊

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-22 02:51:16 +09:00
c8ad1dae65 feat(naming): Phase 21.7++ Phase 3 完全達成 - Builder 側 StaticMethodId SSOT 統一
## 🎊 成果概要
**Phase 3: 全体統一** - MIR Builder 側を StaticMethodId 準拠に統一!

###  実装完了項目(全4タスク)
1. **素手 split 調査** (Phase 3.1)
   - 調査結果: known.rs に2箇所のみ(split_once)
   - unified_emitter には素手 split なし
   - 置き換え対象: 2箇所のみで簡潔

2. **unified_emitter.rs 統一** (Phase 3.2)
   - methodization 部分を StaticMethodId::parse() に変更
   - decode_static_method() → StaticMethodId::parse()
   - is_static_method_name() → StaticMethodId::parse().is_some()
   - arity 判定を Optional 対応(None も許容)

3. **known.rs split_once 置き換え** (Phase 3.3)
   - 2箇所の split_once('.') → StaticMethodId::parse()
   - box_name 取得を構造化表現経由に統一
   - コード削減: 8行 → 4行(50%削減)

4. **テスト実行・確認** (Phase 3.4)
   - json_lint_stringutils_min_vm: PASS 
   - namingbox_static_method_id: 13/13 PASS 
   - ビルド成功、警告のみ(既存問題)

### 📊 技術的効果
- **素手 split 根絶**: 全箇所を StaticMethodId 経由に統一
- **コード品質向上**: 構造化表現で型安全化
- **保守性向上**: 名前パース処理が SSOT に集約
- **後方互換**: 既存機能に影響なし

### 🎯 Phase 4 への準備完了
- Builder/VM 両方が StaticMethodId SSOT 準拠
- ドキュメント整備のみ残存(2-3時間)

---

**Phase 0**:  完了 (Silent Failure 根絶)
**Phase 1**:  完了 (SSOT 基盤確立)
**Phase 2**:  完了 (VM 統一)
**Phase 3**:  完了 (Builder 統一)
**Phase 4**: 次のタスク (ドキュメント化)

🧮 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-22 02:43:45 +09:00
1b413da51e feat(naming): Phase 21.7++ Phase 2 完全達成 - VM StaticMethodId SSOT 統一
## 🎊 成果概要
**Phase 2: VM 統一** - arity バグ根治、VM 名前解決が SSOT 準拠!

###  実装完了項目(全4タスク)
1. **global.rs を StaticMethodId ベース化** (handlers/calls/global.rs:10-27)
   - Hotfix(normalize + arity 補完)→ 正式実装(StaticMethodId ベース)
   - パース成功: StaticMethodId::parse() → with_arity() → format()
   - パース失敗: 従来の normalize(builtin 互換)

2. **デバッグログ強化** (global.rs:33-47)
   - NYASH_DEBUG_FUNCTION_LOOKUP=1 でパース情報表示
   - box_name, method, arity を明示的に出力

3. **VM テスト拡張**  既存テストで十分
   - json_lint_stringutils_min_vm テスト完全通過

4. **テスト実行・確認**
   -  json_lint_stringutils_min_vm: PASS
   -  namingbox_static_method_id: 13/13 PASS
   -  全体テスト: 349 passed; 17 failed (Phase 0時と同様、退行なし)

### 📊 技術的効果
- **arity バグ根治**: "Box.method" → "Box.method/N" 補完が SSOT 経由
- **デバッグ向上**: 関数名パース情報が即座に確認可能
- **コード品質**: Hotfix → 正式実装へ移行完了
- **後方互換**: builtin 関数(print, panic 等)も正常動作

### 🎯 Phase 3 への準備完了
- MIR Builder 側も StaticMethodId 統一(Phase 3 候補)
- 全体統一で 100-200 行削減見込み

---

**Phase 0**:  完了 (Silent Failure 根絶)
**Phase 1**:  完了 (SSOT 基盤確立)
**Phase 2**:  完了 (VM 統一)
**Phase 3-4**: 次のマイルストーン (全体統一・ドキュメント化)

🧮 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-22 02:31:35 +09:00
96c1345ec0 feat(naming): Phase 21.7++ Phase 1 完全達成 - StaticMethodId SSOT 基盤確立
## 🎉 成果概要
**Phase 1: 基盤整備** - NamingBox SSOT の構造化された基盤完成!

###  実装完了項目(全5タスク)
1. **StaticMethodId 構造体導入** (src/mir/naming.rs:86-248)
   - 構造化された関数名表現: box_name, method, arity
   - Optional arity でパース柔軟性確保

2. **ヘルパー関数追加**
   - `parse()`: "Box.method/N" or "Box.method" をパース
   - `format()`: 構造化 ID → 文字列変換
   - `with_arity()`: arity 補完用ビルダー
   - 互換性エイリアス: parse_global_name(), format_global_name()

3. **包括的テスト追加** (src/tests/namingbox_static_method_id.rs)
   - 13 テストケース全通過 
   - arity 有り/無し、normalize、format、round-trip、エラー処理
   - エッジケース: 複数ドット、大きな arity、不正入力

4. **テスト登録** (src/tests/mod.rs:21)
   - Phase 21.7++ コメント付きで登録

5. **動作確認**
   - `cargo test --release --lib namingbox_static_method_id`
   - 全 13 テスト PASS (0.00s)

### 📊 技術的効果
- **SSOT 確立**: 関数名パース/フォーマットを 1 箇所に集約
- **型安全**: 構造化表現で誤用防止
- **テスト保証**: 13 ケースで安全性確保
- **後方互換**: エイリアス関数で段階移行可能

### 🎯 Phase 2 への準備完了
- VM 側の関数ルックアップを StaticMethodId ベース化
- arity バグ根治への基盤確立

---

**Phase 0**:  完了 (Silent Failure 根絶)
**Phase 1**:  完了 (SSOT 基盤確立)
**Phase 2**: 次のタスク (VM 統一)

🧮 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-22 02:25:22 +09:00
ce7517dc21 docs(phase-21.7): NamingBox SSOT 統一化チェックリスト作成
Phase 21.7++ の詳細実装計画を文書化

## 作成ファイル
- docs/development/current/main/phase-21.7-naming-ssot-checklist.md
  - Phase 0-4 の詳細タスクリスト(チェックボックス付き)
  - 各タスクの具体的な実装コード例
  - テストケース
  - 工数見積もり・優先順位
  - 完了条件

## CURRENT_TASK.md 更新
- Phase 21.7 セクションにチェックリストへのリンク追加

## 実装優先順位
1. Phase 0: 観測ライン緊急構築(最優先、2-3時間)
2. Phase 1: 基盤整備(4-6時間)
3. Phase 2: VM 統一(3-4時間)
4. Phase 3-4: 全体統一・ドキュメント(Phase 22+)

次のステップ: Phase 0 実装開始
2025-11-22 01:59:27 +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
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
d99b941218 docs: add MIR13 mode doc and set PHI-off as default; bridge lowering split (if/loop/try); llvmlite resolver stabilization; curated runner default PHI-off; refresh CURRENT_TASK.md 2025-09-17 10:58:12 +09:00