020fbc6740
refactor(phi_core): Phase 193 - Complete loopform modularization with 4-pass architecture
...
Phase 193: loopform_builder.rs modularization (1,166 → 102 lines, 91% reduction)
## Module Structure Created
```
src/mir/phi_core/loopform/
├── mod.rs (102 lines) - Public API coordinator
├── context.rs (148 lines) - ValueId management
├── variable_models.rs (101 lines) - Variable types
├── utils.rs (112 lines) - Utilities
├── exit_phi.rs (96 lines) - Exit PHI builder
├── builder_core.rs (411 lines) - Core builder logic
├── passes/
│ ├── mod.rs (67 lines) - Pass coordinator
│ ├── pass1_discovery.rs (156 lines) - Variable discovery
│ ├── pass2_preheader.rs (70 lines) - Preheader copies
│ ├── pass3_header_phi.rs (106 lines) - Header PHI construction
│ └── pass4_seal.rs (276 lines) - PHI completion
```
## 4-Pass Architecture Explicit
### Pass 1: Variable Discovery (pass1_discovery.rs)
- Classify variables as carriers or pinned
- Allocate all ValueIds upfront
- GUARD protection for invalid ValueIds
### Pass 2: Preheader Copy (pass2_preheader.rs)
- Emit deterministic copy instructions
- Order: pinned first, carriers second
### Pass 3: Header PHI Construction (pass3_header_phi.rs)
- Generate incomplete PHI nodes
- First input: preheader_copy (known)
- Second input: latch value (unknown)
### Pass 4: PHI Sealing (pass4_seal.rs)
- Complete PHI nodes with latch values
- Separate pinned/carrier handling
- PHI optimization (same-value detection)
## Size Comparison
Before:
- loopform_builder.rs: 1,166 lines (monolithic)
- loopform_passes.rs: 133 lines (documentation stub)
- Total: 1,299 lines in 2 files
After:
- 11 focused modules: 1,645 lines total
- Main file (mod.rs): 102 lines (91% reduction)
- Largest module: builder_core (411 lines)
- Average module size: 150 lines
- 4 pass modules: 608 lines (explicit structure)
## Success Criteria Met
✅ Directory structure created with 11 focused modules
✅ 4-pass architecture explicit and clear
✅ cargo build --release succeeds
✅ Loop programs execute correctly
✅ Zero breaking changes (all APIs compatible)
✅ Module documentation comprehensive
✅ All visibility correct (pub/pub(crate) appropriate)
## Files Modified
- NEW: src/mir/phi_core/loopform/mod.rs (public API)
- NEW: src/mir/phi_core/loopform/builder_core.rs (core builder)
- NEW: src/mir/phi_core/loopform/passes/*.rs (4 pass modules)
- MOVED: loopform_*.rs → loopform/*.rs (5 files)
- DELETED: loopform_builder.rs, loopform_passes.rs
- UPDATED: phi_core/mod.rs (import structure)
- UPDATED: json_v0_bridge/lowering/loop_.rs (import path)
## Impact
- **Maintainability**: Each pass has clear responsibilities
- **Testability**: Individual passes can be tested independently
- **Documentation**: Comprehensive module and pass documentation
- **Modularity**: Clean separation of concerns
- **Readability**: No file exceeds 411 lines
Phase 1-3 modularization complete. Ready for new feature development.
2025-12-05 21:58:54 +09:00
397bc77eb3
refactor(vm): StaticBoxRegistry unifies static box management
...
箱化モジュール化: Phase 173-B の散在した static box 管理を一元化
Before (4箇所に散在):
- static_box_decls: HashMap (AST経由のBox宣言)
- static_boxes: HashMap (実行時シングルトン)
- vm.rs Phase 173-B手動検出コード (~60行)
- method.rs static_box_decls.contains_key() 直接参照
After (StaticBoxRegistry箱に統一):
- declarations: AST経由のBox宣言を登録
- detected_boxes: MIR関数名から自動検出 (using import対応)
- instances: 遅延作成シングルトン
- naming utilities: parse/format関数
Benefits:
- vm.rs: 63行削減 (Phase 173-B手動コード削除)
- 自動検出: using import した static box も対応
- 単一責務: static box lifecycle を1箱に集約
- Fail-Fast: 存在しないBoxへのアクセスは即エラー
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-04 18:56:23 +09:00
9d29718f03
fix(vm): Phase 173-B using-imported static box method calls
...
Enable static box method calls for boxes imported via `using` statement.
Root cause: 3 interrelated issues
1. Cross-function ValueId: methodize created singleton with ValueId that
can't be used across MIR function boundaries
2. Missing registration: using-imported static boxes weren't in
static_box_decls (only AST-based boxes were registered)
3. Wrong dispatch: method.rs tried InstanceBox dispatch instead of
MIR function table lookup for static boxes
Fixes:
- unified_emitter.rs: Use receiver=None for StaticCompiler boxes
- vm.rs: Auto-detect and register static boxes from MIR function names
- mod.rs: Add has_static_box_decl() helper
- method.rs: Add MIR function table lookup path for static boxes
- guard.rs: Trust methodize for StaticCompiler boxes without type info
Test: JsonParserBox.toString() via using import now works correctly
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-04 18:49:10 +09:00
46922e5074
feat(hako_check): Phase 155 MIR CFG data bridge (MVP)
...
🌉 CFG データブリッジ MVP 完成!
🔗 実装内容:
- MIR JSON 出力時に CFG を自動抽出 (mir_json_emit.rs)
- Analysis IR に CFG フィールド追加 (analysis_consumer.hako)
- DeadBlockAnalyzerBox が ir.get("cfg") でアクセス可能
📊 技術詳細:
- extract_cfg_info() を MIR JSON 出力に統合
- v0/v1 両 JSON フォーマット対応
- CFG: functions[].blocks[]{id, successors, terminator, reachable}
⚠️ MVP 制限事項:
- CFG は MIR JSON に含まれるが、hako_check は未読み込み
- Analysis IR の CFG は空構造体(ブロック情報なし)
- HC020 は実行されるが検出結果 0 件(期待通り)
🎯 Phase 154 + 155 で HC020 基盤完成!
🔧 次のステップ (Phase 156 or 155.5):
- Option A: hako_check に MIR パイプライン統合
- Option B: extract_mir_cfg() builtin 関数実装
- 推奨: Option A (既存の hakorune_emit_mir.sh 活用)
📝 Modified files:
- src/runner/mir_json_emit.rs (+15 lines)
- tools/hako_check/analysis_consumer.hako (+7 lines)
- docs/development/current/main/phase155_mir_cfg_bridge.md (+130 lines)
- CURRENT_TASK.md (Phase 155 section added)
Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-04 15:23:43 +09:00
04f476d6b4
feat(phase112): Ring0 Service Registry統一化実装完了
...
Ring0 初期化を Ring0Registry::build(profile) に集約し、プロファイル対応を統一化
【実装内容】
- Task 2: Ring0Registry struct + build(profile) メソッド実装
- RuntimeProfile::Default → StdFs を使用
- RuntimeProfile::NoFs → NoFsApi を使用
- build_default()/build_no_fs() の内部メソッド分離
- Task 3: NoFsApi struct 実装(FsApi trait)
- すべてのファイルシステム操作を「disabled」として失敗させる
- read/write/append/metadata/canonicalize が IoError を返す
- exists() は false を返す
- 49行の新規実装
- Task 4: initialize_runtime() SSOT パターン確認
- env 読み込み → RuntimeProfile::from_env()
- Ring0Context 構築 → Ring0Registry::build(profile)
- グローバル登録 → init_global_ring0()
- 唯一の責務分離を確立
- Task 5: PluginHost/FileBox/FileHandleBox からの Ring0 統合
- Ring0.fs = NoFsApi の場合、すべての上位層が自動的に disabled
- 特別なロジック不要(カスケード disabled パターン)
- Task 6: ドキュメント更新
- core_boxes_design.md: Section 17 追加(88行)
- ring0-inventory.md: Phase 112 エントリ追加(16行)
- CURRENT_TASK.md: Phase 106-112 完了表更新
- phase112_ring0_registry_design.md: 完全設計書(426行)
【統計】
- 8ファイル修正(+261行, -30行)
- 3つの新テスト追加(Ring0Registry関連)
- test_ring0_registry_default_profile
- test_ring0_registry_nofs_profile
- test_default_ring0_uses_registry
- cargo build --release: SUCCESS
- 全テスト PASS
【設計原則確立】
- Ring0Registry factory pattern で profile-aware 実装選択を一本化
- NoFsApi による自動 disabled により、上位層の特別処理を排除
- initialize_runtime() が唯一の env 読み込み入口として SSOT 確立
- 将来の profile 追加(TestMock/Sandbox/ReadOnly/Embedded等)が容易に
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-03 22:19:24 +09:00
66479f921d
feat(phase106): FileBox provider_lock整理 & Fail-Fast強化(案B統一版)
...
Task 1: CoreBoxId.category() 修正
- File を CoreRequired 側に移動(L126)
- テスト期待値修正(L371)
- Phase 106 intent コメント更新(L107-115)
Task 2: provider_lock API 確認
- 変更なし(既存の set/get API をそのまま使用)
- get_filebox_provider_strict() は追加しない(シンプルに保つ)
Task 3: FileBox SSOT コメント追加
- L5-7 に責務明示コメント追加
Task 4: PluginHost に FileBox provider チェック追加
- with_core_from_registry_optional() に Phase 106 チェック追加(L158-167)
- test_with_core_from_registry_filebox_required() 追加(L413-445)
- 既存テスト2件を FileBox provider 初期化対応(L301-321, L323-351)
- test_with_core_from_registry_missing_box() をエラーメッセージ拡張(L386-410)
Task 5: ドキュメント更新
- core_boxes_design.md に Phase 106 セクション追加(L248-265)
- 責務分離原則・Ring0.FsApi 延期を明記
完了条件:
✅ ビルド成功(cargo build --release)
✅ テスト全PASS(cargo test --lib runtime: 64 passed; 0 failed)
✅ 指示書の実装チェックリスト全て completed
2025-12-03 17:55:26 +09:00
ea4c164dae
refactor(runner): Phase 105.5 Console出力のmacro統一化
...
- Replace direct console.println() calls with console_println! macro
- Simplify error handling in vm.rs (RC output)
- Simplify success logging in selfhost.rs (PluginHost init)
- Remove redundant nested if-let structures for Option handling
- Macro already handles all fallback scenarios (eprintln!)
This reduces code duplication and improves consistency. The macro
centralizes the fallback logic, making it easier to maintain.
Files modified:
- src/runner/modes/vm.rs (simplified RC output)
- src/runner/selfhost.rs (simplified PluginHost init message)
Line reduction: ~13 lines (nested if-let structures removed)
2025-12-03 14:25:28 +09:00
6ecd8f7f52
feat(runtime): Phase 103 CoreServices Optional化 - Memory Constraints対応
...
- Add CoreServicesConfig struct (from_env, minimal, all_enabled)
- Implement with_core_from_registry_optional() for selective initialization
- Update CoreBoxesImpl fields to Option<Arc<dyn XyzService>>
- Maintain backward compatibility (with_core_from_registry calls all_enabled)
- Add NYASH_CORE_DISABLE_* environment variable support
- ConsoleBox remains mandatory (Graceful Degradation principle)
- Add unit tests for optional initialization
- Update console_println! macro to handle Option type
- Fix direct console.println() calls in vm.rs and selfhost.rs
- Create core_optional_design.md documentation
Note: Phase 104 will extend ConsoleService to be optional as well with
graceful fallback in console_println! macro.
Files modified:
- src/runtime/plugin_host.rs (CoreServicesConfig, with_core_from_registry_optional, tests)
- src/runtime/core_services.rs (CoreBoxesImpl fields → Option type)
- src/runtime/mod.rs (console_println! macro updated)
- src/runner/modes/vm.rs (handle Option console)
- src/runner/selfhost.rs (handle Option console)
- docs/development/current/main/core_optional_design.md (new)
- docs/development/current/main/ring0-inventory.md (Phase 103 entry)
Test results:
- Build: ✅ Success (0 errors, 7 warnings)
- Unit tests: ✅ 3/3 passed (optional_core_tests)
- Runtime tests: ✅ 63/63 passed
- Smoke tests: ✅ 30/31 passed (1 pre-existing timeout)
2025-12-03 13:59:06 +09:00
0c527dcd22
feat(runtime): Phase 101-A dev-debug ログの Ring0.log 統一 - 34箇所完了
...
## Phase 101-A 完了項目
- ✅ llvm.rs: 13箇所([joinir/llvm], [parse/context]) → Ring0.log
- ✅ loop_form.rs: [loopform] 系ログ → Ring0.log
- ✅ loopform_builder.rs: 16箇所([loopform/prepare], [loopform/seal_phis]) → Ring0.log
- ✅ loop_snapshot_merge.rs: 5箇所([Option C]) → Ring0.log
- ✅ 全テストPASS(ビルド成功)
## 置き換え箇所(34箇所)
**llvm.rs**(13箇所):
- [joinir/llvm] JoinIR 実験パスログ(12箇所)
- [parse/context] プリロードファイルリスト(1箇所)
**loop_form.rs**(複数箇所):
- [loopform] 基本ログ
- [loopform/condition] 条件式処理
- [loopform/writes] 変数書き込み収集
**loopform_builder.rs**(16箇所):
- [loopform/prepare] 構造準備
- [loopform/seal_phis] PHI シーリング処理
**loop_snapshot_merge.rs**(5箇所):
- [Option C] Exit PHI 分類
- [Option C] 変数解析
## 技術的成果
- Ring0.log で dev-debug ログを一元管理
- stderr の cleanness 向上(ユーザー向けメッセージのみ)
- 環境に応じた出力制御が可能(NYASH_LOOPFORM_DEBUG等)
- Phase 99-100 で確立した 3層設計を実装レベルで完成
## 実装パターン
```rust
// Before
eprintln!("[loopform] variable_map: {:?}", map);
// After
crate::runtime::get_global_ring0().log.debug(&format!(
"[loopform] variable_map: {:?}", map
));
```
## 統計
- Phase 98: 7箇所(ConsoleService)
- Phase 100: 29箇所(ConsoleService)
- Phase 101-A: 34箇所(Ring0.log)
- **合計**: 70箇所で統一(ConsoleService/Ring0.log)
- 残り: ~905箇所(test含む)
## ドキュメント更新
- logging_policy.md: Section 7-A 追加(Phase 101-A 実装記録)
- ring0-inventory.md: Category 2 更新(dev-debug 進捗反映)
- CURRENT_TASK.md: Phase 85 セクション追記
## Phase 85-101-A 総括
- Phase 95.5-97: CoreServices 6個完全実装(String/Integer/Bool/Array/Map/Console)
- Phase 98-98.5: ConsoleService 代表パス拡張(7箇所)
- Phase 99: ログ/出力ポリシー確定(3層設計文書化)
- Phase 100: user-facing 出力の ConsoleService 化(29箇所)
- Phase 101-A: dev-debug ログの Ring0.log 統一(34箇所) ✅
次: Phase 101-B(internal/test ログの整理、別検討)
🎊 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-03 12:25:32 +09:00
7cf11fbc5c
feat(runtime): Phase 100 user-facing 出力の ConsoleService 完全統一 - 29箇所完了
...
## Phase 100 完了項目
- ✅ selfhost.rs: 6箇所 → console_println!
- ✅ llvm.rs: 23箇所(主要メッセージ) → console_println!
- ✅ 全テストPASS(core_services: 11, plugin_host: 7)
- ✅ ドキュメント更新完了
## 置き換え箇所(29箇所)
**selfhost.rs**(6箇所):
- Line 57: CoreInitError 出力
- Lines 194/363/418/519/570: Result 出力
**llvm.rs**(23箇所、ユーザー向けメッセージのみ):
- エラーメッセージ(❌ ): ファイル読み込み、using/parse エラー
- 成功メッセージ(📊 ): MIR コンパイル成功
- LLVM/harness 関連エラー
- 実行結果出力
- Mock LLVM メッセージ
## 意図的に除外(Phase 101 対象)
- llvm.rs の `[joinir/llvm]`, `[parse/context]` デバッグログ
- hack_check: .hako アプリ(Nyash言語の ConsoleBox 経由)
- bench.rs: テスト・性能表示(dev-debug)
- mir.rs: 内部 MIR ダンプ(dev-debug)
## 技術的成果
- selfhost/LLVM runner のユーザー向けメッセージを ConsoleService に統一
- Phase 99 で確立したログ/出力ポリシーを実装レベルで実現
- デバッグログとユーザー向け出力の明確な分離
- Graceful Degradation パターンの実用確認
## 統計
- Phase 98: 7箇所
- Phase 100: 29箇所
- **合計**: 36箇所で ConsoleService 経由に移行完了
- 残り user-facing: ~330箇所(Phase 101-102 で段階的拡張)
## ドキュメント更新
- logging_policy.md: Section 7 追加(Phase 100 実装完了記録)
- ring0-inventory.md: Category 1 更新(Phase 100 進捗反映)
- CURRENT_TASK.md: Phase 85 セクション追記
## Phase 85-100 総括
- Phase 95.5-97: CoreServices 6個完全実装(String/Integer/Bool/Array/Map/Console)
- Phase 98-98.5: ConsoleService 代表パス拡張(7箇所)
- Phase 99: ログ/出力ポリシー確定(3層設計文書化)
- Phase 100: user-facing 出力の ConsoleService 化(29箇所) ✅
次: Phase 101(dev-debug/test/internal 出力の整理、Ring0.log 活用)
🎊 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-03 11:55:14 +09:00
44c6ca9585
chore(runtime): Phase 98.5 Arc 完全修飾パス簡略化 & コメント統一
...
## 修正内容
**src/runtime/mod.rs** (4箇所):
- use文: std::sync::OnceLock → std::sync::{Arc, OnceLock}
- Line 64: OnceLock<std::sync::Arc<...>> → OnceLock<Arc<...>>
- Line 68: std::sync::Arc::new(...) → Arc::new(...)
- Line 72/80: 戻り値型で std::sync::Arc → Arc に統一
**src/runner/modes/vm.rs** (1箇所):
- Line 589: コメント統一 "println" → "eprintln"(実装に合わせる)
## 効果
- 可読性向上: std::sync:: プレフィックス4箇所削除
- 一貫性向上: console_println! マクロの説明と実装を統一
- 追加依存なし、機能変更なし
## テスト結果
✅ cargo build --release: 成功
✅ cargo test --lib runtime::core_services: 11 passed
🧹 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-03 11:17:41 +09:00
7bcb7ec596
feat(runtime): Phase 98 ConsoleService 代表パス拡張 - 7箇所置き換え完了
...
## Phase 98 完了項目
- ✅ println!/eprintln! 7箇所 → ConsoleService 経由に移行
- ✅ console_println! マクロ追加(Graceful Degradation パターン)
- ✅ try_get_core_plugin_host() 追加(安全なアクセサー)
- ✅ 全テストPASS(core_services: 11, plugin_host: 7)
## 置き換え箇所(7箇所)
**selfhost/child.rs** (3箇所):
- spawn失敗エラー
- タイムアウトメッセージ(stdout/stderr)
**core_bridge.rs** (2箇所):
- DUMP書き込みエラー
- DUMP_MUT書き込みエラー
**vm.rs** (1箇所):
- RC(return code)出力
**selfhost/json.rs** (2箇所, オプション達成):
- PyVM MIR JSON emit エラー
- PyVM 使用ログ(verbose時)
## 技術的成果
**Graceful Degradation パターン確立**:
- PluginHost 初期化前: eprintln! フォールバック
- PluginHost 初期化後: ConsoleService 使用(Ring0直結)
- Fail-Fast原則との整合性: 出力先選択のみ動的
**実装インフラ**:
- src/runtime/mod.rs: console_println! マクロ & try_get_core_plugin_host()
- 既存の get_core_plugin_host() は panic! 保持(Fail-Fast)
## 統計
- 置き換え完了: 7箇所(全体の約2%)
- 残り候補: 約359箇所(Phase 99以降)
- テスト: ビルド成功、全ユニットテストPASS
## ドキュメント
- docs/development/current/main/core_boxes_design.md: Section 15 追加(128行)
- 実装パターン、設計判断、テスト結果を完全記録
## Phase 85-98 総括
- Phase 85-94: 構造設計 & 箱化モジュール化
- Phase 95.5: StringService/ConsoleService(Ring0直結型・純粋関数型)
- Phase 96-96.5: ArrayService/MapService(downcast型)& コード整理
- Phase 97: IntegerService/BoolService(純粋関数型、#[allow(dead_code)] 根絶)
- Phase 98: ConsoleService 実用拡大(7箇所)✅ 完了
次: Phase 99(CoreServices 完全統合、残り約359箇所の段階的移行)
🎊 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-03 11:04:58 +09:00
e74694d08b
feat(phase95): CoreServices実用化 - Console/String Service実装完了
...
Phase 95完全達成 - Ring1-Core層の実際のService実装
### 実装成果
- ✅ ConsoleService::println/print 実装
- ✅ StringService::len 実装(UTF-8文字数対応)
- ✅ global accessor 実装(get_core_plugin_host)
- ✅ 代表パス切り替え(selfhost.rs)
- ✅ テスト13/13 PASS(100%)
### 変更ファイル
- src/runtime/core_services.rs: Service API定義、Adapter実装、テスト追加(+79行)
- src/runtime/mod.rs: global accessor実装(+18行)
- src/runtime/plugin_host.rs: Debug impl追加(+3行)
- src/runner/selfhost.rs: ConsoleService経由に切り替え(+5行)
- docs/development/current/main/core_boxes_design.md: Phase 95文書化(+118行)
### 技術的成果
- Ring0 → Ring1-Core → 実行パス の三層構造確立
- 型安全なService経由アクセス実現
- UTF-8完全対応(文字数カウント)
- global accessorパターン統一(Ring0と同じOnceLock)
### Bug修正
- PluginHost Debug impl追加
- PluginHost.optional型修正(Send + Sync追加)
- CoreServices Debug impl実装
### 次のステップ
Phase 95.5: Ring0統合とAdapter整理(#[allow(dead_code)]削除)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-03 09:57:38 +09:00
b3de4cac4b
feat(phase93): with_core_from_registry implementation complete
...
Phase 93 完了: UnifiedBoxRegistry 統合実装 & 起動パス統合
**実装内容**:
- with_core_from_registry() 実装
- UnifiedBoxRegistry.has_type() で core Box の存在確認
- 不足時は CoreInitError::MissingService を返す
- ダミー Service 実装で CoreServices を構築
- ダミー Service 実装を pub に
- DummyStringService, DummyIntegerService 等を公開
- Phase 94 の実変換までの橋渡し
- CoreServices::dummy() ヘルパー追加
- フォールバック用ダミー実装
- initialize_runtime() 実装(環境変数制御)
- NYASH_USE_PLUGIN_HOST=1 で PluginHost 有効化
- 環境変数なしで従来通り動作(後方互換性)
- selfhost に PluginHost 初期化追加
- CoreInitError 発生時は fail-fast
- 既存ロジックは変更なし
**Fail-Fast 設計**:
- 起動時に core Box 不足を即座に検出
- CoreInitError で明示的なエラーメッセージ
- デバッグ容易(ランタイムエラーではなく起動時エラー)
**テスト結果**:
- test_with_core_from_registry_missing_box 追加
- 7件全て成功
- ビルド成功(1分4秒)
- 526 passed(既存36失敗は Phase 93 と無関係)
**動作確認**:
- 環境変数なし: 従来通り動作 ✅
- NYASH_USE_PLUGIN_HOST=1: PluginHost 初期化成功 ✅
- selfhost: fail-fast 動作確認済み ✅
**ドキュメント更新**:
- Section 10 追加(77行)
- 段階的展開戦略、Fail-Fast 設計を文書化
**次のステップ**: Phase 94 (実際の Box → Service 変換)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-03 08:42:45 +09:00
4e2e45a79d
feat(phase90): Ring0Context fs/time/thread migration complete
...
Phase 90 完了: IO/fs/time/thread 系の Ring0 移行
**Phase 90-A: fs 系移行(7箇所)**
- FsApi trait 追加(6メソッド)
- StdFs 実装(std::fs ベース)
- IoError 拡張(4バリアント追加)
- 移行: strip.rs(4), dispatch.rs(1), mod.rs(3)
**Phase 90-B: io 系移行**
- Phase 88 完了済み(スキップ)
**Phase 90-C: time 系移行(3箇所)**
- TimeApi に elapsed() 追加
- 移行: selfhost_exe.rs(1), io.rs(1), plugin_loader_unified.rs(1)
**Phase 90-D: thread 系移行(2箇所)**
- ThreadApi trait 追加(sleep メソッド)
- StdThread 実装
- 移行: global_hooks.rs(1), plugin_loader_unified.rs(1)
**Phase 90-E: 統合テスト**
- ビルド成功(6 warnings, 0 errors)
- テスト: 522/554 passed (94.2%)
- 退行なし
**実装成果**:
- Ring0Context 拡張: fs, thread フィールド追加
- 総移行: 12箇所(fs: 7, time: 3, thread: 2)
- 移行率: fs(2.9%), time(2.1%), thread(5.4%)
**次のステップ**: Phase 91 (PluginHost/CoreServices skeleton)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-03 06:14:57 +09:00
a01110e791
feat(phase89-a): Ring0Context logs migration - 56 locations
...
Phase 89-A 完了: println!/eprintln! → ring0.log.* 移行
**実装内容**:
- 環境変数制御: NYASH_RING0_LOG_LEVEL (DEBUG/INFO/WARN/ERROR)
- selfhost.rs: 24箇所移行 (error:14, warn:2, info:5, debug:3)
- vm.rs: 32箇所移行 (error:5, warn:4, info:2, debug:21)
**実装効果**:
- 総移行箇所: 56箇所 (目標: 10-15箇所 → 373%達成)
- 累計進捗: 58/3,955箇所 (1.47%)
- テスト結果: 521 passed; 33 failed (変化なし)
**次のステップ**: Phase 89-B (IO/time 棚卸し)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-02 23:27:41 +09:00
42b09b3c1c
feat(phase88): Ring0Context Skeleton implementation
...
Phase 88: OS API abstraction layer implementation
**Implementation**:
- Ring0Context module added (4 files)
- mod.rs: Public API, global initialization (OnceLock)
- traits.rs: MemApi, IoApi, TimeApi, LogApi trait definitions
- std_impls.rs: std-based default implementations
- errors.rs: IoError, TimeError type definitions
**Design Principles**:
- Ring0 knows nothing about Box
- Ring0 knows nothing about Nyash
- Pure OS API abstraction
**Global Initialization**:
- NyashRunner::new() initializes Ring0Context globally
- OnceLock ensures safe initialization (idempotent)
**Migration (2 paths)**:
- src/runner/selfhost.rs:27: eprintln! → ring0.log.error() (OOB strict)
- src/runner/selfhost.rs:177: eprintln! → ring0.log.error() (PyVM error)
**Tests**:
- 4 unit tests added (ring0 module)
- All tests passed
- Build successful (0 errors)
**Migration Status**:
- Migrated: 2/3,955 (0.05%)
- Remaining: 3,953 paths (Phase 89+)
**Files Changed**:
- src/runtime/ring0/mod.rs (new, 100 lines)
- src/runtime/ring0/traits.rs (new, 93 lines)
- src/runtime/ring0/std_impls.rs (new, 77 lines)
- src/runtime/ring0/errors.rs (new, 26 lines)
- src/runtime/mod.rs (Ring0Context export)
- src/runner/mod.rs (global initialization)
- src/runner/selfhost.rs (2 paths migrated)
- docs/development/current/main/ring0-inventory.md (Phase 88 status)
Phase 88 complete. Ready for Phase 89 (gradual migration).
🐱 ✨
2025-12-02 22:38:27 +09:00
8633224061
JoinIR/SSA/Stage-3: sync CURRENT_TASK and dev env
2025-12-01 11:10:46 +09:00
a3d5bacc55
Phase 30.1 & 73: Stage-3 features env and JoinIR flag cleanup
2025-11-30 14:30:28 +09:00
7de192aa6b
feat(mir): Phase 69-3 Fix MIR non-determinism with BTreeSet
...
Replace HashSet with BTreeSet for CFG predecessors/successors:
- BasicBlock.predecessors: HashSet → BTreeSet
- BasicBlock.successors: HashSet → BTreeSet
- LoopFormOps.get_block_predecessors(): returns BTreeSet
- BasicBlock.dominates(): takes &[BTreeSet<BasicBlockId>]
This ensures deterministic PHI generation and test stability.
Test results:
- loop_with_continue_and_break tests: now deterministic (3/3 same output)
- loopform tests: 14/14 PASS (no regressions)
- merge_exit_with_classification tests: 3/3 PASS
Technical changes (6 files):
- basic_block.rs: BTreeSet types + new() initialization
- loopform_builder.rs: trait signature + 2 mock implementations
- phi_ops.rs: return type
- json_v0_bridge/loop_.rs: return type
Same pattern as Phase 25.1 (MirFunction.blocks HashMap → BTreeMap).
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-30 09:38:28 +09:00
3387d9c1dc
feat(phi): Phase 69-2 Remove inspector argument from merge_exit_with_classification
...
Remove LocalScopeInspectorBox parameter from merge_exit_with_classification:
- Inspector is now constructed internally from exit_snapshots and header_vals
- Simplifies call sites (loopform_builder.rs, json_v0_bridge/loop_.rs)
- Removes 35+ lines of external inspector setup code
- Tests adjusted to match new signature (3 tests PASS)
This is a step toward Phase 69-3 (complete Trio deletion) where
LocalScopeInspectorBox will be fully removed.
Technical changes:
- loop_snapshot_merge.rs: Build inspector from exit_snapshots internally
- loopform_builder.rs: Remove inspector argument from build_exit_phis
- json_v0_bridge/loop_.rs: Remove inspector creation and argument
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-30 09:17:10 +09:00
c6edbaaf3a
feat(mir): Phase 63-6-1/2 MIR Phi type_hint field & JoinIR propagation
...
Phase 63-6-1: MirInstruction::Phi に type_hint フィールド追加
- Added `type_hint: Option<MirType>` field to Phi instruction
- Updated 21 files with type_hint initialization (all set to None for legacy paths)
- Pattern matching updated across codebase (11 files)
- Test code updated (basic_block.rs)
Phase 63-6-2: JoinIR→MIR Bridge で型ヒント伝播実装
- Modified convert.rs: Select → MIR now creates PHI with type_hint
- Removed Copy instructions from then/else blocks
- PHI instruction at merge block receives type_hint from JoinIR Select
- Test verification: ✅ Type hint propagation successful (Some(Integer))
Modified files:
- instruction.rs: Added type_hint field definition
- join_ir_vm_bridge/convert.rs: Select lowering with PHI + type_hint
- 19 other files: type_hint field initialization
Test results:
- ✅ test_type_hint_propagation_simple: Type hint = Some(Integer) confirmed
- ✅ 7/8 if_select tests passing (1 race condition, passes individually)
Next: Phase 63-6-3 (lifecycle.rs で型ヒント使用)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-30 04:35:40 +09:00
f4044c56cb
refactor(phase62): Delete phi_input_collector.rs (-384 lines)
...
Phase 62前倒し: PhiInputCollectorの物理削除
Changes:
- Delete src/mir/phi_core/phi_input_collector.rs (-384 lines)
- Inline PhiInputCollector logic in json_v0_bridge/lowering/loop_.rs
- sanitize: BTreeMap dedup + sort
- optimize_same_value: check all inputs for same value
- Remove mod declaration in phi_core/mod.rs
Rationale:
- PhiInputCollector already inlined in Phase 59 (loopform_builder.rs)
- Last remaining usage was in JSON v0 Bridge
- Simple inline preserves exact behavior
Impact:
- -384 lines (Box + tests)
- No behavior change (inline equivalent)
- Build & test pass ✅
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-29 15:42:30 +09:00
447bbec998
refactor(joinir): Split ast_lowerer and join_ir_vm_bridge into modules
...
ast_lowerer.rs → ast_lowerer/ (10 files):
- mod.rs: public surface + entry dispatch
- context.rs: ExtractCtx helpers
- expr.rs: expression-to-JoinIR extraction
- if_return.rs: simple if→Select lowering
- loop_patterns.rs: loop variants (simple/break/continue)
- read_quoted.rs: read_quoted_from lowering (Phase 45-46)
- nested_if.rs: NestedIfMerge lowering
- analysis.rs: loop if-var analysis + metadata helpers
- tests.rs: frontend lowering tests
- README.md: module documentation
join_ir_vm_bridge.rs → join_ir_vm_bridge/ (5 files):
- mod.rs: public surface + shared helpers
- convert.rs: JoinIR→MIR lowering
- runner.rs: VM execution entry (run_joinir_via_vm)
- meta.rs: experimental metadata-aware hooks
- tests.rs: bridge-specific unit tests
- README.md: module documentation
Benefits:
- Clear separation of concerns per pattern
- Easier navigation and maintenance
- Each file has single responsibility
- README documents module boundaries
Co-authored-by: ChatGPT <noreply@openai.com >
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-28 17:42:19 +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
35cd93a37a
Phase 33-2: JoinInst::Select implementation + minimal If JoinIR lowering
...
Implementation:
- Add JoinInst::Select variant to JoinIR schema
- Implement Select execution in JoinIR Runner (Bool/Int cond support)
- Add Select handling in JoinIR→MIR Bridge (4-block structure)
- Create test cases (joinir_if_select_simple/local.hako)
- Add dev toggle NYASH_JOINIR_IF_SELECT=1
- Create lowering infrastructure (if_select.rs, stub for Phase 33-3)
Tests:
- 3/3 unit tests pass (test_select_true/false/int_cond)
- Integration tests pass (RC: 0)
- A/B execution verified (existing if_phi vs JoinIR Select)
Files changed:
- New: apps/tests/joinir_if_select_{simple,local}.hako
- New: src/mir/join_ir/lowering/if_select.rs
- Modified: src/mir/join_ir/{mod,json,runner,vm_bridge}.rs
- Modified: src/config/env.rs (joinir_if_select_enabled)
- Modified: docs/reference/environment-variables.md
Phase 33-3 ready: MIR pattern recognition + auto-lowering pending
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-27 02:58:38 +09:00
51ff558904
feat(phase32): L-2.1 Stage-1 UsingResolver JoinIR integration + cleanup
...
Phase 32 L-2.1 complete implementation:
1. Stage-1 UsingResolver main line JoinIR connection
- CFG-based LoopForm construction for resolve_for_source/5
- LoopToJoinLowerer integration with handwritten fallback
- JSON snapshot tests 6/6 PASS
2. JoinIR/VM Bridge improvements
- Simplified join_ir_vm_bridge.rs dispatch logic
- Enhanced json.rs serialization
- PHI core boxes cleanup (local_scope_inspector, loop_exit_liveness, loop_var_classifier)
3. Stage-1 CLI enhancements
- Extended args.rs, groups.rs, mod.rs for new options
- Improved stage1_bridge module (args, env, mod)
- Updated stage1_cli.hako
4. MIR builder cleanup
- Simplified if_form.rs control flow
- Removed dead code from loop_builder.rs
- Enhanced phi_merge.rs
5. Runner module updates
- json_v0_bridge/lowering.rs improvements
- dispatch.rs, selfhost.rs, modes/vm.rs cleanup
6. Documentation updates
- CURRENT_TASK.md, AGENTS.md
- Various docs/ updates
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-26 10:17:37 +09:00
29ae922a57
feat(joinir): Stage-1 UsingResolver JoinIR VM Bridge A/B test
...
Phase 30.x: Stage-1 ループでも PHI バグが発生することを確認・JoinIR で設計根絶可能を実証
変更内容:
- src/tests/joinir_vm_bridge_stage1_usingresolver.rs: 新規作成(モジュール化・削除容易)
- empty_entries: VM → "void" (PHI bug, expected "init")
- with_entries: VM → "void" (PHI bug, expected "ABC")
- lowering_sanity: 常時実行の構造検証
- src/runner/modes/vm.rs: Stage1UsingResolverBox.resolve_for_source/5 検出・JoinIR lowering 確認
- src/tests/mod.rs: モジュール追加(1行で削除可能)
- docs: Phase 30 TASKS.md に L-0.5 追加
発見:
Stage-1 ループでも PHI バグが発生 → JoinIR で設計根絶可能を確認
(ArrayBox/MapBox 引数対応は TODO)
テスト結果:
✅ empty_entries ... ok (VM="void", expected="init", PHI bug detected)
✅ with_entries ... ok (VM="void", expected="ABC", PHI bug detected)
✅ lowering_sanity ... ok (JoinIR structure: 2 functions)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-25 12:34:20 +09:00
ee2b3115ee
feat(joinir): FuncScannerBox.trim/1 JoinIR VM Bridge A/B test
...
Phase 30.x: JoinIR VM Bridge でPHI問題を設計で解決できることを実証
変更内容:
- src/runner/modes/vm.rs: FuncScannerBox.trim/1 検出時にJoinIR経由実行
- src/mir/join_ir_vm_bridge.rs: Non-tail call サポート追加
- dst=Some(id) の場合、結果を格納して次の命令へ継続
- src/tests/joinir_vm_bridge_trim.rs: A/Bテスト新規作成
- メインテスト: Route A (VM) → "void" (PHI bug), Route C (JoinIR) → "abc" ✅
- エッジケース: 5パターン全てPASS
- src/config/env.rs: joinir_vm_bridge_debug() 追加
- docs: Phase 30 TASKS.md に L-0.4 追加
テスト結果:
Route A (MIR→VM直接): "void" ← PHI バグ
Route C (MIR→JoinIR→VM): "abc" ← 正解 ✅
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-25 12:22:08 +09:00
c479e5f527
fix(dx): Quick Win 1-3 for better error messages and API simplification
...
Quick Win 1: Show available boxes on "Unknown Box type" error
- vm.rs, vm_fallback.rs: Display sorted list of available user-defined boxes
- Before: "Unknown Box type: Foo"
- After: "Unknown Box type: Foo. Available: Bar, Baz, Main"
Quick Win 2: Show stderr on child process timeout
- child.rs, selfhost_exe.rs: Capture and display stderr (up to 500 chars)
- Helps diagnose what went wrong in selfhost compiler child process
Quick Win 3: Simplify Stage-B compiler API (SSOT)
- compiler_stageb.hako: Add StageBDriverBox.compile() as single entry point
- compiler_stageb.hako: Remove StageBMain compatibility wrapper
- compiler.hako: Change from `using ... as StageBMain` to direct import
- compiler.hako: Call StageBDriverBox.compile() directly
Also includes child_env.rs NYASH_MODULES env var for module mapping.
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-25 08:44:31 +09:00
6726ee246d
fix(selfhost): Phase 28.2 Ny compiler child process fixes
...
- Use --stage-b flag for file-based compilation (Stage-A expects source
content, not path; Stage-B uses FileBox to read files)
- Remove redundant env overrides that conflicted with
apply_selfhost_compiler_env() settings
- Re-enable plugins in selfhost compiler env (NYASH_DISABLE_PLUGINS=0)
so compiler.hako can use FileBox to read source files
Note: Pipeline infrastructure now works, but compiler.hako has a MIR
SSA bug (undefined ValueId(374)) that needs separate investigation.
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-25 07:49:47 +09:00
22575aa1db
refactor(selfhost): clean up selfhost.rs - remove duplicates, unify env access
...
## Changes
### Duplicate code removal
- Remove nested double cli_verbose() checks (2 places)
- Remove duplicate pre_run_reset_oob_if_strict() calls
- Remove duplicate OOB strict check blocks
### Environment variable access unification
- All raw std::env::var() calls replaced with config::env functions
- Added new config::env functions:
- ny_compiler_use_py()
- macro_selfhost_pre_expand()
- scopebox_enable()
- loopform_normalize()
- selfhost_inline_force()
### Common helper extraction
- maybe_dump_mir_verbose(): MIR dump with verbose check
- check_oob_strict_exit(): OOB strict mode check and exit
- execute_with_oob_check(): Combined run + OOB check
## Result
- Net ~11 lines reduction
- Much better code structure and maintainability
- Consistent environment variable access through config::env
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-25 07:18:29 +09:00
94b2bd2799
feat(selfhost): add observation logs for Ny compiler path diagnosis
...
Add NYASH_CLI_VERBOSE>=2 observation logs to trace the Ny compiler
child process path (NYASH_USE_NY_COMPILER=1):
- Log when spawning child process
- Log when receiving Program(JSON v0)
- Log before/after maybe_dump_mir with dump path info
- Report whether MIR dump file was created
Key finding: apps/selfhost/compiler/compiler.hako doesn't exist,
so the preferred child process route never fires. This explains
why RUST_MIR_DUMP_PATH doesn't create files in Ny compiler path.
Also update environment-variables.md with:
- NYASH_CLI_VERBOSE=2 level documentation
- Ny compiler observation template for Phase 29
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-25 07:08:32 +09:00
c6c5653ae0
fix(parser): Stage-1 CLI infinite loop - MirBuilder-friendly refactoring (Part 1/3)
...
**Problem**: Stage-1 CLI hits VM step budget (infinite loops) in multiple functions
- ParserBox.parse_program2: bb2853→bb2854 loop
- StringHelpers.skip_ws: bb488→bb491 loop
**Root Cause**: MirBuilder bug with `loop(cont==1)` + nested `if-else` pattern
- PHI instructions with self-references
- Loop exit blocks jumping back to header instead of continuation
**Solution**: Refactor to MirBuilder-friendly pattern
```hako
// Before (causes infinite loop):
loop(cont == 1) {
if guard > max { return j } else { guard++ }
if condition { action } else { cont = 0 }
}
// After (MirBuilder-friendly):
loop(j < n) {
if condition { j++; continue }
break
}
```
**Changes**:
1. parser_box.hako: parse_program2 main loop refactored
- 7 sections: ws→EOF/guard→parse_stmt2→progress guard→trace→semicolons→emit
- Unconditional parse_stmt2 execution (no nested if-else)
- Explicit `break` for loop exits
2. string_helpers.hako: StringHelpers.skip_ws simplified
- Removed `cont` flag and guard counter
- Direct `loop(j < n)` with `continue/break`
3. vm.rs, vm_fallback.rs: RUST_MIR_DUMP_PATH support
- Enables offline MIR analysis for debugging
**Progress**:
- ✅ parse_program2: infinite loop fixed
- ✅ StringHelpers.skip_ws: infinite loop fixed
- ⏳ ParserIdentScanBox.scan_ident: next target (bb985 loop)
**Testing**:
- MIR dumps generated successfully (116K+ lines)
- ws_init loop completes
- parse_program2 progresses further
- Still hits infinite loop in scan_ident (Part 2 needed)
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-24 18:19:31 +09:00
6885235145
Factor JSON v0 bridge globals/throw into small helpers
2025-11-24 15:21:49 +09:00
da1a5558e5
Normalize passes keep spans and clean warnings
2025-11-24 15:02:51 +09:00
466e636af6
Span trace utilities and runner source hint
2025-11-24 14:17:02 +09:00
3d5979c78e
refactor(joinir): Phase 27.9 - Modular separation of join_ir.rs into directory structure
...
Phase 27.9 で join_ir.rs (~1,336行) を以下のモジュール構造に分離:
## 新規ディレクトリ構造:
```
src/mir/join_ir/
├── mod.rs # 型定義・共通ユーティリティ (~330行)
└── lowering/
├── mod.rs # lowering インターフェース
├── min_loop.rs # lower_min_loop_to_joinir (~140行)
├── skip_ws.rs # skip_ws lowering 3関数 (~390行)
└── funcscanner_trim.rs # trim lowering (~480行)
```
## 技術的変更:
- **型定義統一**: JoinFuncId, JoinInst, JoinModule 等を mod.rs に集約
- **lowering 分離**: 3つの lowering 関数を個別モジュールに移動
- **後方互換性**: pub use で lowering 関数を re-export(既存コード影響なし)
- **削除**: src/mir/join_ir.rs (旧単一ファイル)
## テスト結果:
- **385 passed** (+1 from 384)
- **9 failed** (-1 from 10)
- **ビルド成功**: 0 errors, 18 warnings (変化なし)
## 効果:
- **保守性向上**: 1,336行 → 4ファイル(各300-500行)で可読性向上
- **モジュール境界明確化**: 型定義 vs lowering 実装の責務分離
- **将来の拡張容易**: 新 lowering 関数追加が簡単に
Phase 27.8 で実装した MIR 自動解析 lowering の基盤整備完了。
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-11-23 16:49:49 +09:00
2692eafbbf
feat(mir): Phase 26-H JoinIR型定義実装完了 - ChatGPT設計
...
## 実装内容(Step 1-3 完全達成)
### Step 1: src/mir/join_ir.rs 型定義追加
- **JoinFuncId / JoinContId**: 関数・継続ID型
- **JoinFunction**: 関数(引数 = φノード)
- **JoinInst**: Call/Jump/Ret/Compute 最小命令セット
- **MirLikeInst**: 算術・比較命令ラッパー
- **JoinModule**: 複数関数保持コンテナ
- **単体テスト**: 型サニティチェック追加
### Step 2: テストケース追加
- **apps/tests/joinir_min_loop.hako**: 最小ループ+breakカナリア
- **src/tests/mir_joinir_min.rs**: 手書きJoinIR構築テスト
- MIR → JoinIR手動構築で型妥当性確認
- #[ignore] で手動実行専用化
- NYASH_JOINIR_EXPERIMENT=1 トグル制御
### Step 3: 環境変数トグル実装
- **NYASH_JOINIR_EXPERIMENT=1**: 実験モード有効化
- **デフォルト挙動**: 既存MIR/LoopForm経路のみ(破壊的変更なし)
- **トグルON時**: JoinIR手書き構築テスト実行
## Phase 26-H スコープ遵守
✅ 型定義のみ(変換ロジックは未実装)
✅ 最小限の命令セット
✅ Debug 出力で妥当性確認
✅ 既存パイプライン無影響
## テスト結果
```
$ NYASH_JOINIR_EXPERIMENT=1 cargo test --release mir_joinir_min_manual_construction -- --ignored --nocapture
[joinir/min] MIR module compiled, 3 functions
[joinir/min] JoinIR module constructed:
[joinir/min] ✅ JoinIR型定義は妥当(Phase 26-H)
test result: ok. 1 passed; 0 failed
```
## JoinIR理論の実証
- **φノード = 関数引数**: `fn loop_step(i, k_exit)`
- **merge = join関数**: 分岐後の合流点
- **ループ = 再帰関数**: `loop_step` 自己呼び出し
- **break = 継続呼び出し**: `k_exit(i)`
## 次フェーズ (Phase 27.x)
- LoopForm v2 → JoinIR 自動変換実装
- break/continue ハンドリング
- Exit PHI の JoinIR 引数化
🌟 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
Co-Authored-By: ChatGPT <noreply@openai.com >
2025-11-23 04:10:12 +09:00
7812c3d4c1
feat(phi): Phase 25.1 - BTreeMap移行 (21ファイル、80%決定性達成)
...
## 修正内容
### Core MIR/PHI (5ファイル)
- builder.rs: variable_map, value_types, value_origin_newbox
- context.rs: 3つのマップ
- loop_builder.rs: 3箇所
- loop_snapshot_manager.rs: snapshot マップ
- loop_snapshot_merge.rs: 2箇所
### MIR関連 (4ファイル)
- function.rs: FunctionMetadata.value_types
- resolver.rs: CalleeResolverBox
- guard.rs: CalleeGuardBox
- loop_common.rs: apply_increment_before_continue
### JSON Bridge (5ファイル)
- json_v0_bridge/lowering.rs
- json_v0_bridge/lowering/expr.rs
- json_v0_bridge/lowering/if_else.rs
- json_v0_bridge/lowering/merge.rs
- json_v0_bridge/lowering/try_catch.rs
- json_v0_bridge/mod.rs
### Printer & Providers (4ファイル)
- printer.rs, printer_helpers.rs
- host_providers/mir_builder.rs
- backend/mir_interpreter/handlers/extern_provider.rs
### Tests (3ファイル)
- phi_core/conservative.rs
- tests/json_program_loop.rs
- tests/mir_stage1_using_resolver_verify.rs (2テスト有効化)
## テスト結果
- mir_stage1_using_resolver_resolve_with_modules_map_verifies: 80%成功率
- 完全な決定性は未達成 (HashMap 86箇所、HashSet 63箇所が残存)
🐱 Generated with Claude Code
2025-11-22 05:33:40 +09:00
63012932eb
feat(phase-0): 観測ライン緊急構築完了 - Silent Failure 根絶
...
Phase 21.7++ Phase 0: 開発者体験を劇的に向上させる3つの改善
## 🎯 実装内容
### ✅ Phase 0.1: populate_from_toml エラー即座表示
**ファイル**: src/runner/pipeline.rs:57-65
**Before**: TOML parse エラーが silent failure
**After**: エラーを即座に警告表示 + デバッグ方法提示
```
⚠️ [using/workspace] Failed to load TOML modules:
Error: TOML parse error at line 18...
→ All 'using' aliases will be unavailable
→ Fix TOML syntax errors in workspace modules
💡 Debug: NYASH_DEBUG_USING=1 for detailed logs
```
**効果**: 今回の StringUtils バグなら即発見できた!
### ✅ Phase 0.2: VM 関数ルックアップ常時提案
**ファイル**: src/backend/mir_interpreter/handlers/calls/global.rs:179-206
**Before**: "Unknown: StringUtils.starts_with" だけ
**After**: 類似関数を自動提案 + デバッグ方法提示
```
Function not found: StringUtils.starts_with
💡 Did you mean:
- StringUtils.starts_with/2
- StringUtils.ends_with/2
🔍 Debug: NYASH_DEBUG_FUNCTION_LOOKUP=1 for full lookup trace
```
**効果**: arity 問題を即発見!環境変数不要で親切!
### ✅ Phase 0.3: using not found 詳細化
**ファイル**: src/runner/modes/common_util/resolve/strip.rs:354-389
**Before**: "'StringUtils' not found" だけ
**After**: 類似モジュール提案 + 利用可能数 + 修正方法提示
```
using: 'StringUtil' not found in nyash.toml [using]/[modules]
💡 Did you mean:
- StringUtils
- JsonUtils
Available modules: 4 aliases
📝 Suggestions:
- Add an alias in nyash.toml: [using.aliases] YourModule = "path/to/module"
- Use the alias: using YourModule as YourModule
- Dev/test mode: NYASH_PREINCLUDE=1
🔍 Debug: NYASH_DEBUG_USING=1 for detailed logs
```
**効果**: タイポを即発見!TOML エラーとの因果関係も提示!
## 📊 Phase 0 成果まとめ
**工数**: 約2.5時間(予想: 2-3時間)✅
**効果**: Silent Failure 完全根絶 🎉
### Before Phase 0
- TOML エラー: 無言で失敗
- 関数が見つからない: "Unknown" だけ
- using が見つからない: "not found" だけ
- デバッグ方法: 環境変数を知ってる人だけ
### After Phase 0
- TOML エラー: 即座に警告 + 影響範囲説明
- 関数が見つからない: 類似関数提案 + デバッグ方法
- using が見つからない: 類似モジュール提案 + 修正方法 + デバッグ方法
- すべてのエラーが親切 🎊
## ✅ テスト結果
- StringUtils テスト: ✅ PASS
- 既存テスト: ✅ 337 passed(16 failed は元々の失敗)
- ビルド: ✅ SUCCESS
- 退行: ❌ なし
## 🎉 開発者体験の改善
今回のような StringUtils using バグが起きても:
1. **TOML エラー**: 即発見(数秒)
2. **arity 問題**: 提案から即解決(数分)
3. **タイポ**: 提案から即修正(数秒)
**Before**: 数時間のデバッグ
**After**: 数分で解決 🚀
次のステップ: Phase 1(基盤整備)に進む準備完了!
2025-11-22 02:13:10 +09:00
f4ae144559
fix(using): StringUtils using resolution - dual root cause fix
...
🎯 Phase 21.7++ - using StringUtils as StringUtils 完全動作化!
## Root Cause #1 : TOML Parse Error (lang/src/llvm_ir/hako_module.toml)
**Problem:**
```toml
line 18: aot_prep = "boxes/aot_prep.hako" # scalar
line 19: aot_prep.passes.strlen = "..." # table - CONFLICT!
```
→ TOML parse error prevented ALL aliases from loading
→ populate_from_toml() returned Err, aliases.len() = 0
**Fix:**
Commented out conflicting line 18:
```toml
# aot_prep = "boxes/aot_prep.hako" # Commented out: conflicts with aot_prep.passes.* below
aot_prep.passes.strlen = "boxes/aot_prep/passes/strlen.hako"
```
**Result:**
✅ populate_from_toml() succeeds
✅ 4 aliases loaded including StringUtils → string_utils
## Root Cause #2 : Missing Arity Suffix (src/backend/mir_interpreter/handlers/calls/global.rs)
**Problem:**
- MIR functions stored as "BoxName.method/arity"
- VM looked up "StringUtils.starts_with" (no arity)
- Function table had "StringUtils.starts_with/2" (with /2)
→ Lookup failed with "Unknown: StringUtils.starts_with"
**Fix:**
Auto-append arity from args.len() if missing:
```rust
let mut canonical = crate::mir::naming::normalize_static_global_name(func_name);
if !canonical.contains('/') {
canonical = format!("{}/{}", canonical, args.len());
}
```
**Result:**
✅ "StringUtils.starts_with" + args.len()=2 → "StringUtils.starts_with/2"
✅ VM function lookup succeeds
## Debug Infrastructure
**Added comprehensive debug logging:**
1. src/runner/pipeline.rs:36-55 - NYASH_DEBUG_USING=1 for alias loading
2. src/backend/mir_interpreter/handlers/calls/global.rs:17-42 - NYASH_DEBUG_FUNCTION_LOOKUP=1 for VM lookup
## Test Coverage
**src/tests/json_lint_stringutils_min_vm.rs:**
- Rewrote to test arity auto-completion (not using resolution)
- Inlined StringUtils implementation to avoid pipeline dependency
- Tests that VM can call "StringUtils.starts_with" without arity suffix
- ✅ Test passes
**CLI Verification:**
```bash
NYASH_PARSER_STAGE3=1 HAKO_PARSER_STAGE3=1 NYASH_DISABLE_PLUGINS=1 \
./target/release/hakorune apps/tests/json_lint_stringutils_min.hako
# Output: OK
# RC: 0
```
## Impact
- ✅ using StringUtils as StringUtils fully functional
- ✅ All using aliases load successfully
- ✅ VM can find functions with/without arity suffix
- ✅ No breaking changes to existing code
- ✅ Debug logging for future troubleshooting
## Files Modified
- lang/src/llvm_ir/hako_module.toml (TOML fix)
- src/runner/pipeline.rs (debug logging)
- src/backend/mir_interpreter/handlers/calls/global.rs (arity fix + logging)
- src/tests/json_lint_stringutils_min_vm.rs (rewrite + enable)
- src/tests/mod.rs (register test)
Co-authored-by: Task Agent <task@anthropic.com >
Co-authored-by: Claude Code <claude@anthropic.com >
2025-11-22 01:21:38 +09:00
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
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
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
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
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
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
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