tomoaki/hakorune
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

refactor(joinir): Phase 244 - ConditionLoweringBox trait unification

Browse Source 
Unify condition lowering logic across Pattern 2/4 with trait-based API.

New infrastructure:
- condition_lowering_box.rs: ConditionLoweringBox trait + ConditionContext (293 lines)
- ExprLowerer implements ConditionLoweringBox trait (+51 lines)

Pattern migrations:
- Pattern 2 (loop_with_break_minimal.rs): Use trait API
- Pattern 4 (loop_with_continue_minimal.rs): Use trait API

Benefits:
- Unified condition lowering interface
- Extensible for future lowering strategies
- Clean API boundary between patterns and lowering logic
- Zero code duplication

Test results: 911/911 PASS (+2 new tests)

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

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
nyash-codex
2025-12-11 02:35:31 +09:00
parent 2dfe363365
commit d4f90976da
131 changed files with 3123 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/archive/phases/phase-106-156/README.md Normal file
View File

@ -0,0 +1,5 @@
# Phase 106–156 Archive (Runtime / ConsoleBox / hako_check 初期ライン)
Status: Historical
Scope: FileBox/Runtime/ConsoleBox/LLVM/hako_check などの初期〜中期フェーズ（Phase 106–156）をまとめたアーカイブ。

355
docs/archive/phases/phase-106-156/phase106_filebox_design_revised.md Normal file
View File

@ -0,0 +1,355 @@
# Phase 106: FileBox provider_lock 整理 & Fail-Fast 強化（案B統合版）
## 0. ゴール
- FileBox を「selfhost/通常ランタイムでは事実上必須」として適切に扱う
- FileBox provider 未登録を起動時 or 最初の利用時に必ず検知して Fail-Fast する
- **「必須」概念は CoreBoxId に集約（案B採用）** - provider_lock はシンプルに保つ
- Ring0.FsApi との統合（案C）は Phase 107+ で実施
---
## 1. 現状整理（前提）
### 1.1 実装状況
| 層 | 位置 | 状態 |
|----|-----|------|
| Ring0 | src/runtime/ring0/traits.rs | FsApi trait：read/write/stat 定義済み |
| provider_lock | src/runtime/provider_lock.rs | OnceLock<Arc<dyn FileIo>>：シンプルな登録機構 |
| FileBox | src/boxes/file/mod.rs | provider_lock::get_filebox_provider() 直接呼び出し |
| CoreBoxId | src/runtime/core_box_ids.rs | **is_core_required() と category() が不一致** |
### 1.2 課題：概念の分散
現在「必須」概念が複数箇所に散在：
- `CoreBoxId.is_core_required()` → File を含める
- `CoreBoxId.category()` → File は CoreOptional のまま
- `provider_lock` → 「必須」概念を持たない
**問題**: 分散すると一貫性を保つのが難しい（設計がぼやける）
### 1.3 解決策（案B採用）
**原則**: 「必須」判定は CoreBoxId に一本化する
- provider_lock: 「FileBox provider を登録・読む」だけ（シンプル）
- CoreBoxId: 「File が必須かどうか」を決定する窓口に
- profile パターン: selfhost/default では必須、minimal/no-fs では optional
### 1.4 Phase 107 統合完了（2025-12-03）
**Ring0.FsApi 統合完了**:
- ✅ Ring0FsFileIo 実装追加（src/providers/ring1/file/ring0_fs_fileio.rs）
- ✅ provider_lock に init_default_filebox_provider() 追加
- ✅ PluginHost.with_core_from_registry_optional で自動登録
- ✅ Phase 106 の MissingService チェックは引き続き有効（Fail-Fast 維持）
**Phase 107 の効果**:
- 標準パスで FileBox provider が自動登録される
- MissingService エラーは基本的に起きない（プラグイン未登録時も default で補完）
- プラグイン優先原則は維持（プラグインが先に登録すれば default は使われない）
---
## 2. Task 1: CoreBoxId を修正（カテゴリ統一）
### 2.1 修正内容
ファイル: `src/runtime/core_box_ids.rs`
#### 現状の不整合
```rust
// L112-115
pub fn is_core_required(&self) -> bool {
matches!(self, String | Integer | Bool | Array | Map | Console | File) // ← File あり
}
// L118-125
pub fn category(&self) -> CoreBoxCategory {
match self {
String | Integer | Bool | Array | Map | Console => CoreBoxCategory::CoreRequired,
Float | Null | File | Path | ... => CoreBoxCategory::CoreOptional, // ← File がここに矛盾
}
}
```
#### 修正方針
`category()` の分岐を修正して両者を統一：
```rust
pub fn category(&self) -> CoreBoxCategory {
match self {
// Phase 106: File を CoreRequired 側に移動（selfhost/通常ランタイムでは必須）
String | Integer | Bool | Array | Map | Console | File => CoreBoxCategory::CoreRequired,
Float | Null | Path | Regex | Math | Time | Json | Toml => CoreBoxCategory::CoreOptional,
Function | Result | Method | Missing => CoreBoxCategory::Special,
}
}
```
#### テスト更新（existing test を修正）
L367 のテストで `CoreBoxId::File.category()` の期待値を修正：
```rust
#[test]
fn test_core_box_id_category() {
assert_eq!(CoreBoxId::String.category(), CoreBoxCategory::CoreRequired);
// Phase 106: File の分類を修正
assert_eq!(CoreBoxId::File.category(), CoreBoxCategory::CoreRequired); // ← 修正
assert_eq!(CoreBoxId::Function.category(), CoreBoxCategory::Special);
}
```
#### コメント追加（現在の intent を明示）
L108-115 のコメントを更新：
```rust
/// Phase 106: core_required チェック
///
/// FileBox は Phase 85 では core_optional として分類していたが、
/// selfhost/通常ランタイムでは事実上必須（ログ・ツール・ハコチェック等で常用）
/// であることが明確になったため、「core_required 相当」として扱う設計に統一した。
///
/// **設計原則**:
/// - 必須判定は CoreBoxId に一本化（provider_lock は「登録・読む」だけ）
/// - 将来 minimal/no-fs プロファイルを導入する場合は、ここで profile パラメータを追加可能
pub fn is_core_required(&self) -> bool {
matches!(self, String | Integer | Bool | Array | Map | Console | File)
}
```
---
## 3. Task 2: provider_lock を単純化（SSOT 原則）
### 3.1 API の状態
ファイル: `src/runtime/provider_lock.rs`
#### 現状（変更不要な部分）
```rust
pub fn set_filebox_provider(provider: Arc<dyn FileIo>) -> Result<(), String>
pub fn get_filebox_provider() -> Option<&'static Arc<dyn FileIo>>
pub fn get_filebox_caps() -> Option<FileCaps>
```
**Decision**: これらの API はそのまま保つ（シンプルで良い）
#### 削除しない理由
- provider_lock の責務は「登録・読む」だけ
- 「必須かどうか」の判定は CoreBoxId の責任
- 層分離が明確になる
### 3.2 get_filebox_provider_strict() は不要
**削除理由**:
- 「Provider 未登録時エラー」は provider_lock の責任ではない
- その判定は、CoreBoxId が「必須」と言ったあとで、呼び出し側が処理すべき
- provider_lock は Option を返すだけで十分
---
## 4. Task 3: FileBox 側から provider_lock を呼び出し（既存パターン継続）
### 4.1 修正内容
ファイル: `src/boxes/file/mod.rs`
#### 現状（OK、変更不要）
L47, L63 の呼び出しはそのまま：
```rust
pub fn new() -> Self {
FileBox {
provider: provider_lock::get_filebox_provider().cloned(),
path: String::new(),
base: BoxBase::new(),
}
}
pub fn open(path: &str) -> Result<Self, String> {
let provider = provider_lock::get_filebox_provider()
.ok_or("FileBox provider not initialized")?
.clone();
// ...
}
```
#### コメント追加（責務明示）
L5 付近にコメント追加：
```rust
// SSOT: FileBox は「FileIo provider を常に経由する」（provider_lock に一元化）。
// provider の有無・必須/optional の判定は provider_lock/CoreBoxId の責務で、
// FileBox 実装内では生の環境変数や静的状態を見ない設計。
```
---
## 5. Task 4: 起動時に FileBox provider 登録を必ず確保（Fail-Fast）
### 5.1 実装内容（概要）
ファイル: `src/runtime/plugin_host.rs`
- `CoreBoxId::is_core_required()` / `CoreServices::required_ids()` を用いて、「必須 Box は registry に型定義が存在すること」を起動時にチェック。
- FileBox については CoreRequired 側に寄せた上で、「FileBox provider が登録されていない場合は CoreInitError::MissingService で fail-fast」するロジックを追加。
- 具体的なコードは実装側に委ね、ここでは責務分離の方針のみを記録する。
#### テスト追加
```rust
#[test]
fn test_with_core_from_registry_filebox_required() {
// Phase 106: FileBox provider なし → エラー
let ring0 = Arc::new(default_ring0());
let registry = UnifiedBoxRegistry::with_env_policy();
// provider_lock を初期化せず（呼び出さず）
// provider が無い状態で with_core_from_registry() を呼ぶ
let result = PluginHost::with_core_from_registry(ring0, &registry);
assert!(result.is_err());
if let Err(CoreInitError::MissingService { box_id, .. }) = result {
assert_eq!(box_id, CoreBoxId::File);
} else {
panic!("Expected MissingService error for FileBox");
}
}
```
### 5.2 selfhost/代表ランナーでの provider 登録
ファイル: `src/runner/selfhost.rs` 等
#### パターン: 起動時に provider を登録
```rust
pub fn run_selfhost(config: &Config) -> Result<(), Error> {
// Ring0 初期化
let ring0 = get_global_ring0();
// FileBox provider 登録（必須なので start-up で必ず実施）
// 実装: builtin_factory::register_filebox_provider(&ring0)?;
// または plugin loader から自動ロード
// PluginHost 初期化（FileBox provider チェック含む）
let plugin_host = initialize_runtime(ring0)?;
plugin_host.ensure_core_initialized();
// 以降処理...
}
```
**Fail-Fast 保証**:
- provider が未登録 → `with_core_from_registry()` で即座にエラー
- CoreInitError::MissingService で明示的に失敗
- アプリケーションが不完全な状態で先に進まない
---
## 6. Task 5: ドキュメント更新（設計の最終確認）
### 6.1 core_boxes_design.md 更新
ファイル: `docs/development/current/main/core_boxes_design.md`
#### Section 5.3 修正（FileBox 再分類）
現在の記述（L230-246）は正しいが、一文を追加：
```markdown
### 5.3 Phase 85 との関係（FileBox 再分類）
[...]
現行の分類は次の通り：
- **core_required (7個)**: StringBox, IntegerBox, BoolBox, ArrayBox, MapBox, ConsoleBox, FileBox
- **core_optional (8個)**: FloatBox, NullBox, PathBox, RegexBox, MathBox, TimeBox, JsonBox, TomlBox
- **特殊型 (4個)**: FunctionBox, ResultBox, MethodBox, MissingBox
## Phase 106: 設計統一（案B）
### 責務分離原則
- **CoreBoxId**: 「必須かどうか」の判定（is_core_required() / category()）
- selfhost/default では File が必須
- 将来 minimal/no-fs プロファイルでは optional に変更可能
- **provider_lock**: 「FileBox provider を登録・読む」のみ（シンプルなロック機構）
- **PluginHost**: startup 時に CoreBoxId.is_core_required() で provider をチェック
- 未登録なら CoreInitError::MissingService で fail-fast
### Ring0.FsApi との関係（Phase 107 延期）
Ring0.FsApi（write 能力あり）と FileIo trait（read-only）の統合は、
Phase 107+ で実施予定。現在は概念を分離したまま。
（理由: Phase 106 は provider_lock 整理に専念し、FsApi 統合は別 phase で）
```
### 6.2 ring0-inventory.md 補足（Option）
理想的には ring0-inventory.md に以下を追加（但し省略可）：
```markdown
### FileBox provider registration
- Phase 106 で provider_lock の整理完了
- startup 時に CoreBoxId::File.is_core_required() でチェック
- 将来の Ring0.FsApi 統合（Phase 107）に向けて概念分離
```
---
## 7. 実装チェックリスト
Phase 106 完了とみなす条件：
- [ ] CoreBoxId::category() の File を CoreRequired 側に移動
- [ ] CoreBoxId テスト更新（L367 の期待値修正）
- [ ] CoreBoxId コメント更新（Phase 106 intent 明示）
- [ ] provider_lock API はそのまま保つ（get_filebox_provider_strict() 追加しない）
- [ ] FileBox コメント追加（SSOT 原則を明示）
- [ ] PluginHost.with_core_from_registry() に FileBox provider チェック追加
- [ ] PluginHost テスト追加（FileBox provider missing case）
- [ ] selfhost 等の起動パスで provider 登録確認
- [ ] core_boxes_design.md Section 5.3 + Phase 106 セクション追加
- [ ] ビルド成功・テスト全PASS確認
---
## 8. 設計原則（Phase 106 で確立）
### 責務分離が明確
```
層 責務 概念
─────────────────────────────────────────────────────────
CoreBoxId 「必須かどうか」判定 is_core_required()/category()
provider_lock 「登録・読む」のみ get_filebox_provider()
PluginHost startup チェック with_core_from_registry() で検証
FileBox provider を通す provider_lock 経由で呼び出し
```
### 将来への足がかり
**Phase 107 で Ring0.FsApi 統合 (案C)**:
- FileIo を FsApi wrapper に
- Ring0 レベルで read/write 能力を統一
- provider_lock からの参照を Ring0.fs に変更
**現在 Phase 106** では「概念をきれいに分離」し、Phase 107 の統合に備える。
---
**指示書作成日**: 2025-12-03（案B統一版）
Status: Historical

364
docs/archive/phases/phase-106-156/phase107_fsapi_fileio_bridge.md Normal file
View File

@ -0,0 +1,364 @@
# Phase 107: Ring0.FsApi ↔ FileIo 統合（FileBox の足場固め）
## 0. ゴール
- Ring0.FsApi（OS ファイル API）と FileIo（FileBox プラグイン用 I/O 抽象）の関係を明確に整理
- 自前 FileBox 実装の「OS への道」を一本のパイプにする：
```
FileBox → FileIo implementation → Ring0.FsApi → std::fs
```
- これにより以下を実現：
- FileBox まわりのハードコード削減
- 将来の no-fs プロファイル / mock Fs の差し替え容易化
- Ring0 と Ring1(FileBox) の依存関係の明確化
---
## 1. スコープと非スコープ
### スコープ（今回やること）
1. **設計＆ドキュメント**
- FsApi / FileIo / FileBox / provider_lock の関係を図と文章で整理
- FileIo を「Ring0.FsApi のラッパ（provider）」として位置づけ
2. **実装（段階的）**
- Ring0.FsApi を read/write の SSOT として確認・微調整
- Ring0 ベースの FileIo 実装追加（Ring0FsFileIo）
- selfhost/通常ランタイムでこれをデフォルト provider として登録
3. **Fail-Fast との接続**
- Phase 106 の「FileBox provider 必須チェック」と矛盾しない仕様確認
- 標準パスで必ず Ring0FsFileIo が入ることを保証
### 非スコープ（今回はやらない）
- FileBox の write/delete/copy 全実装（別 Phase）
- FileBox API 大幅変更（メソッド名変更等）
- minimal/no-fs プロファイル実装（Phase 108 候補）
---
## 2. Task 1: FsApi を SSOT として整理（docs + 確認）✅
### 2.1 実装内容
**ファイル**:
- `src/runtime/ring0/traits.rs`
- `docs/development/current/main/core_boxes_design.md`
- **新規**: `docs/development/current/main/phase107_fsapi_fileio_bridge.md` (このファイル)
### 2.2 やること
1. **traits.rs で FsApi の公開インターフェースを確認**：✅
```rust
pub trait FsApi: Send + Sync {
fn read_to_string(&self, path: &Path) -> Result<String, IoError>;
fn read(&self, path: &Path) -> Result<Vec<u8>, IoError>;
fn write_all(&self, path: &Path, data: &[u8]) -> Result<(), IoError>;
fn exists(&self, path: &Path) -> bool;
fn metadata(&self, path: &Path) -> Result<FsMetadata, IoError>;
fn canonicalize(&self, path: &Path) -> Result<PathBuf, IoError>;
}
```
**確認結果**:
- ✅ read_to_string: String 直接読み込み（UTF-8変換済み）
- ✅ read: バイト列読み込み
- ✅ write_all: バイト列書き込み
- ✅ exists: 存在確認
- ✅ metadata: ファイルメタデータ取得（is_file/is_dir/len）
- ✅ canonicalize: パス正規化
2. **このドキュメント（phase107_fsapi_fileio_bridge.md）に記載**：✅
- 「FsApi = OS ファイル I/O の SSOT（Rust ローカル）」
- 「FileIo = FileBox 用 provider interface。実装の 1 つとして FsApi を内部で使う」という関係
- Ring0 → Ring1 の一方向依存の図
**層の関係**:
```
[FileBox (Ring1)]
↓ provider 経由
[Ring0FsFileIo] (FileIo 実装)
↓ read/write 呼び出し
[Ring0.FsApi] (OS I/O 抽象)
↓
[std::fs]
```
3. **core_boxes_design.md に一文追加**：✅（Task 5で実施）
- FileBox セクションに「実体 I/O は FileIo → FsApi → OS」を記載
---
## 3. Task 2: FileIo を「FsApi ラッパ」として設計✅
### 3.1 実装内容
**ファイル**:
- `src/boxes/file/provider.rs` ✅
- `phase107_fsapi_fileio_bridge.md` ✅
### 3.2 やること
1. **FileIo trait の役割を明確化**：✅
```rust
pub trait FileIo: Send + Sync {
fn caps(&self) -> FileCaps;
fn open(&self, path: &str) -> FileResult<()>;
fn read(&self) -> FileResult<String>;
fn close(&self) -> FileResult<()>;
}
```
- **設計**: FileIo は「現在開いているファイルハンドル」に対する操作
- **FsApi** は stateless（Path → 読込/書込）
- **FileIo** は stateful（open → read/close）
2. **実装設計を docs に記載**（擬似コード）：
```rust
pub struct Ring0FsFileIo {
ring0: Arc<Ring0Context>,
path: String,
caps: FileCaps,
}
impl FileIo for Ring0FsFileIo {
fn caps(&self) -> FileCaps { self.caps }
fn open(&self, path: &str) -> FileResult<()> {
// FsApi 経由で存在確認など
Ok(())
}
fn read(&self) -> FileResult<String> {
self.ring0.fs.read_file(Path::new(&self.path))
.map(|bytes| String::from_utf8_lossy(&bytes).to_string())
.map_err(FileError::Io)
}
fn close(&self) -> FileResult<()> { Ok(()) }
}
```
3. **実装時の検討事項を明示**（以下のセクション参照）
---
## 3.3 実装時の検討事項（重要）
### ① Byte → String 変換のポリシー
**問題**: Ring0FsFileIo の read() で `String::from_utf8_lossy()` を使うと、バイナリファイルの無効な UTF-8 を置換してしまう。
**検討事項**:
- **Option A**: 現状通り `from_utf8_lossy()` で置換
- 利点: Nyash が文字列中心だから OK
- 欠点: バイナリ情報が失われる
- **Option B**: `String::from_utf8()` で Err を返す
- 利点: エラーが明示的
- 欠点: FileIo trait を `Result<String, Utf8Error>` に変更する必要あり（破壊的）
**推奨**: **Option A（from_utf8_lossy）を採用**
- 理由: Nyash は言語実装として「テキストファイル」が主用途
- バイナリ対応は「将来の拡張」として Phase 108+ で検討
- docs に「FileBox は UTF-8 テキストファイル向け」と明記
### ② FileBox の open 状態での二重 open
**問題**: FileBox.open() が呼ばれるたびに provider.open() が呼ばれる。
- 既存の FileBox.open() → provider.open() の流れで、close() なしに再度 open() が呼ばれるケース
**検討事項**:
- **Option A**: close() を呼び出し側に強制する
- FileBox.open() 前に明示的に close() 呼び出し
- **Option B**: Ring0FsFileIo 内で自動管理
- 新しい open() が来たら前回の close を自動実行
- **Option C**: セマンティクスを明記
- 「一度 open したら close() まで新しい open は受け付けない」
**推奨**: **Option C（セマンティクス明記）** + docs 追記
- Ring0FsFileIo.open() は「既に path が set されていたら Err を返す」
- FileBox.open() の docs に「FileBox は同時に 1 ファイルのみ開く」と明記
- 複数ファイル同時アクセスは「将来の FileHandleBox」で対応
### ③ プラグイン優先ロジックでの Err ハンドリング
**問題**: `provider_lock::set_filebox_provider()` は OnceLock なので 1 回のみ可能。
- プラグインが先に登録 → init_default_filebox_provider() が Err を返す
**検討事項**:
- **Option A**: Err を単に無視する
- 呼び出し側で Err を無視（silent）
- **Option B**: Warning をログに出す
- ring0.log.info() / warn() で「プラグイン provider が既に設定されています」と出力
- **Option C**: init_default_filebox_provider() を Option を返すように変更
- 呼び出し側で「設定済み」を区別可能
**推奨**: **Option B（Warning ログ出力）**
- 実装: `init_default_filebox_provider()` の戻り値を `Result<(), String>` にして、
- Ok(()) → デフォルト provider を登録した
- Err(msg) → 既にプラグイン側で登録済み（msg = "Plugin provider already registered"）
- 呼び出し側で `ring0.log.debug()` で記録（verbose 時に可視）
- Fail-Fast は保たれる（MissingService は出ない）
---
## 4. Task 3: Ring0 ベースの FileIo 実装を追加✅
### 4.1 実装内容
**実装ファイル**:
- `src/providers/ring1/file/ring0_fs_fileio.rs` ✅（新規作成）
- `src/runtime/provider_lock.rs` ✅（ヘルパー関数追加）
- `src/runtime/plugin_host.rs` ✅（起動時初期化統合）
### 4.2 やること
1. **Ring0FsFileIo 実装を追加**：✅
- フィールド: `Arc<Ring0Context>`, `String path`
- open(path): path を保持、FsApi 経由で存在確認（読み取り向け）
- read(): FsApi.read_file → String 変換（from_utf8_lossy ポリシー採用）
- close(): 単に Ok(())（実質 noop、ハンドル管理なし）
- caps: `FileCaps { read: true, write: false }` (Phase 107 では read-only)
2. **provider_lock 側にヘルパー追加**：
```rust
pub fn init_default_filebox_provider(
ring0: &Arc<Ring0Context>
) -> Result<(), String> {
// Ring0 ベースの FileIo を登録
let provider = Arc::new(Ring0FsFileIo::new(ring0.clone()));
set_filebox_provider(provider)
.map_err(|_| "Plugin FileBox provider already registered".to_string())
}
```
3. **PluginHost/initialize_runtime に統合**：
- CoreServices 初期化後に `init_default_filebox_provider(&ring0)` を呼ぶ
- 戻り値が Err の場合は debug ログを出力（プラグイン優先）
- Fail-Fast は影響なし（既にプラグイン provider が set されているだけ）
---
## 5. Task 4: Fail-Fast & プロファイルとの整合✅
### 5.1 実装内容
**ファイル**:
- `src/runtime/plugin_host.rs` ✅
- `docs/development/current/main/phase106_filebox_design_revised.md` ✅
### 5.2 やること
1. **Phase 106 との整合確認**：✅
- Phase 106: 「FileBox provider 未登録なら CoreInitError::MissingService」
- Phase 107: 「標準パスで Ring0FsFileIo が自動登録されるので MissingService は基本的に起きない」
- phase106 のドキュメントに追記: ✅「Phase 107 で自動登録機構が追加された」
**確認結果**:
- ✅ with_core_from_registry_optional() で自動登録実装済み
- ✅ Phase 106 の MissingService チェックは維持（二重防御）
- ✅ プラグイン優先原則も維持（debug ログで可視化）
2. **将来用フック（docs に記載）**：✅
- minimal/no-fs プロファイル導入時:
- `CoreBoxId::File.is_core_required(profile)` に拡張可能
- その profile では `init_default_filebox_provider()` を呼ばない
- これで「FileBox 無し環境」も可能に（Phase 108 以降）
---
## 6. Task 5: ドキュメント統合✅
### 6.1 実装内容
**ファイル**:
- `docs/development/current/main/core_boxes_design.md` ✅
- `docs/development/current/main/phase106_filebox_design_revised.md` ✅
- `phase107_fsapi_fileio_bridge.md` (このドキュメント) ✅
### 6.2 やること
1. **core_boxes_design.md に図と説明を追加**：✅
```
[FileBox (Ring1)]
↓ (provider経由)
[Ring0FsFileIo] (FileIo実装)
↓ (read_to_string/read呼び出し)
[Ring0.FsApi] (OS I/O抽象)
↓
[std::fs]
```
2. **phase106_filebox_design_revised.md の "Phase 107" セクション更新**：✅
- 「Phase 107 で FsApi 統合を行う予定」→「Phase 107 統合完了」に変更
- Ring0FsFileIo 実装、自動登録、Fail-Fast 維持を明記
3. **phase107_fsapi_fileio_bridge.md にまとめる**：✅
- FsApi / FileIo / FileBox / provider_lock / PluginHost の関係を 1 ドキュメントで整理
- 設計判断（UTF-8 handling, one-file-at-a-time, plugin priority）を明記
---
## 7. 実装チェックリスト（Phase 107）✅ 全項目完了
- ✅ FsApi / FileIo / FileBox / provider_lock / PluginHost の関係が図付きで整理されている
- ✅ Ring0 ベースの FileIo 実装（Ring0FsFileIo）が追加されている
- ✅ selfhost/通常ランタイム起動で、デフォルトとして Ring0FsFileIo が provider_lock に登録される
- ✅ UTF-8 ハンドリング ポリシー（read_to_string 使用）が実装されている
- ✅ FileBox の一度に1ファイルのみ open セマンティクスが実装されている（テスト済み）
- ✅ プラグイン優先時の Err ハンドリング（debug ログ出力）が実装されている
- ✅ Phase 106 との整合確認完了（MissingService は基本レア）
- ✅ 将来用フック（minimal/no-fs プロファイル）が docs に記載されている
- ✅ ビルド・テスト完全成功（FileBox/provider_lock/plugin_host 関連テスト全PASS）
---
## 8. Phase 108 以降の進展
### Phase 108 実装完了（2025-12-03）
**write 実装完了**:
- Ring0FsFileIo に write() メソッド実装
- FileBox.write() / write_all() が Ring0.FsApi.write_all() 経由で動作
- FileCaps.write = true（標準プロファイルで書き込み対応）
**設計決定**:
- **Write mode**: truncate（既存ファイル毎回上書き）
- **テキスト前提**: UTF-8 変換（from_utf8_lossy）
- **append mode**: Phase 109+ で予定
**テスト**:
- Round-trip テスト（write → read）✅
- Truncate mode 検証✅
- Read-only provider 拒否テスト✅
---
## 9. 設計原則（Phase 107 で確立）
### 層の棲み分けが完全化
```
層 役割 知識範囲
──────────────────────────────────────────────────────────────
Ring0.FsApi OS I/O 抽象化 Rust std::fs のみ
Ring0FsFileIo FileIo 実装 (1つの実装例) Ring0.FsApi 使用
FileIo trait FileBox 向け I/O 抽象 FsApi を知らない
provider_lock 登録・参照 OnceLock管理
FileBox ユーザーAPI provider 経由のみ
```
### 拡張ポイント（Phase 109+）
**将来の実装候補**:
- MockFileIo: FsApi の代わりに in-memory mock を使う（テスト専用）
- NetworkFileIo: FsApi の代わりに remote FS を使う（将来の分散 FS / リモートログ用途）
- minimal/no-fs: RuntimeProfile に応じて provider 登録をスキップし、FileBox を read-only / disabled として扱う
---
**Phase 107 指示書作成日**: 2025-12-03（検討事項追加版）
Status: Historical

363
docs/archive/phases/phase-106-156/phase108_filebox_write_semantics.md Normal file
View File

@ -0,0 +1,363 @@
# Phase 108: FileBox write/write_all 実装（Ring0 経由での書き込み有効化）
## 0. ゴール
- Phase 107 で作ったパイプライン：
```
FileBox → Ring0FsFileIo (FileIo) → Ring0.FsApi → std::fs
```
の **write 側を有効化** して、「FileBox でちゃんとファイルに書ける」状態を作る。
- 既存の Fail-Fast 方針（caps.write=false なら書けない）は維持しつつ、「標準プロファイルでは write が使える」ように する。
---
## 1. スコープと非スコープ
### スコープ（今回やること）
- FsApi / Ring0FsFileIo / FileBox の write/write_all 経路を実装
- FileCaps の write フラグを、標準プロバイダ（Ring0FsFileIo）では true にする
- 最小限のテキストログ用途（truncate mode）を実装・テスト
### 非スコープ（今回はやらない）
- 高度な機能（ローテーション、同時書き込みロック、append などの複数モード）
- FileBox API の破壊的変更（メソッド名や戻り値型の大きな変更）
- minimal/no-fs プロファイル本体（Phase 109 で扱う候補）
---
## 2. Task 1: 書き込みセマンティクスの設計（docs）
### 2.1 実装内容
**ファイル**:
- `docs/development/current/main/phase107_fsapi_fileio_bridge.md`（追記）
- **新規**: `phase108_filebox_write_semantics.md`（このドキュメント）
### 2.2 設計決定：write mode の明確化（重要）
**Phase 108 での write 挙動**:
```rust
pub fn write(&self, text: &str) -> FileResult<()> {
// truncate mode: 既存ファイルは毎回上書き
self.ring0.fs.write_all(Path::new(&self.path), text.as_bytes())
.map_err(FileError::Io)
}
```
**採用理由**:
- ✅ シンプル実装（append モードは Phase 109+ で追加）
- ✅ ログ出力向け用途に最適
- ✅ テスト容易
**今後の計画**:
- Phase 109+: append メソッド追加時に、write/append の選択を柔軟化予定
### 2.3 テキスト vs バイナリ
**方針**:
- FileBox は **UTF-8 テキストファイル前提**（Phase 107 と同じ）
- write_all: `&[u8]` → `String` に変換して、text として書く
- バイナリ対応は「将来の拡張」（後フェーズ）
### 2.4 エラー処理
- FsApi.write_all の Err → `FileError::Io(String)` にラップ
- FileBox.write 層では：
- 成功時: "OK" など固定 StringBox を返す
- 失敗時: "Error: ..." を StringBox で返す（既存スタイル維持）
---
## 3. Task 2: FsApi / Ring0FsFileIo の write 実装
### 3.1 実装内容
**ファイル**:
- `src/runtime/ring0/traits.rs`
- `src/runtime/ring0/std_impls.rs`（FsApi の std 実装）
- `src/providers/ring1/file/ring0_fs_fileio.rs`
### 3.2 やること
1. **FsApi の write_all を確認**：
```rust
pub trait FsApi: Send + Sync {
fn read_file(&self, path: &Path) -> Result<Vec<u8>, IoError>;
fn write_all(&self, path: &Path, content: &[u8]) -> Result<(), IoError>;
// ...
}
```
- 既に実装済みなら そのまま使用
- 無ければ `std::fs::write` に薄く委譲する実装を追加
2. **FileIo trait に write を追加**：
```rust
pub trait FileIo: Send + Sync {
fn caps(&self) -> FileCaps;
fn open(&self, path: &str) -> FileResult<()>;
fn read(&self) -> FileResult<String>;
fn write(&self, text: &str) -> FileResult<()>; // ← 新規追加
fn close(&self) -> FileResult<()>;
}
```
3. **Ring0FsFileIo に write メソッドを実装**：
```rust
impl FileIo for Ring0FsFileIo {
fn write(&self, text: &str) -> FileResult<()> {
self.ring0.fs.write_all(Path::new(&self.path), text.as_bytes())
.map_err(FileError::Io)
}
}
```
4. **FileCaps の write フラグを更新**：
- Ring0FsFileIo.caps(): `FileCaps { read: true, write: true }`
- read-only プロバイダや no-fs プロバイダでは `write: false` のままに（Fail-Fast と整合）
### 3.3 重要：FileIo trait 拡張時の互換性
write() を FileIo trait に追加することで、既存のテスト FileIo や mock も実装が必要になります。
**対応**:
1. Phase 107 tests の DummyFileIo を確認
2. 必要に応じて DummyFileIo に write stub 追加：
```rust
fn write(&self, _text: &str) -> FileResult<()> {
Err(FileError::Unsupported) // テスト用は write 非対応
}
```
3. すべてのテストが still pass することを確認
---
## 4. Task 3: FileBox の write/write_all を Ring0 経由に変更
### 4.1 実装内容
**ファイル**:
- `src/boxes/file/mod.rs`
### 4.2 やること
1. **FileBox.write_all(&self, buf: &[u8]) → Result<(), String>**：
```rust
pub fn write_all(&self, buf: &[u8]) -> Result<(), String> {
if let Some(ref provider) = self.provider {
let caps = provider.caps();
if !caps.write {
return Err("Write not supported by FileBox provider".to_string());
}
// UTF-8 変換してプロバイダに委譲
let text = String::from_utf8_lossy(buf).to_string();
provider.write(&text)
.map_err(|e| format!("Write failed: {:?}", e))
} else {
Err("No provider available".to_string())
}
}
```
2. **FileBox.write(&self, _content: Box<dyn NyashBox>) → Box<dyn NyashBox>**：
```rust
pub fn write(&self, content: Box<dyn NyashBox>) -> Box<dyn NyashBox> {
if let Some(ref provider) = self.provider {
let caps = provider.caps();
if !caps.write {
return Box::new(StringBox::new(
"Error: write not supported by provider (read-only)".to_string()
));
}
// content を StringBox にダウンキャストして text を取得
let text = if let Some(str_box) = content.as_any().downcast_ref::<StringBox>() {
str_box.to_string_box().value
} else {
content.to_string_box().value
};
match provider.write(&text) {
Ok(()) => Box::new(StringBox::new("OK".to_string())),
Err(e) => Box::new(StringBox::new(format!("Error: {:?}", e))),
}
} else {
Box::new(StringBox::new("Error: no provider available".to_string()))
}
}
```
3. **delete / copy は Phase 108 では stub のまま**：
- docs に「将来実装予定」と明記
- caps.write フラグ チェックは維持
### 4.3 戻り値の扱い
- write_all: `Result<(), String>` 維持（Rust API）
- write: `Box<dyn NyashBox>` 維持（.hako での使用パターン）
- 両者の使い分けは「Rust 側が使うか .hako 側が使うか」で判断
---
## 5. Task 4: テスト追加
### 5.1 実装内容
**ファイル候補**:
- `src/boxes/file/mod.rs` のテストモジュール
- `src/providers/ring1/file/ring0_fs_fileio.rs` のテスト
### 5.2 テストケース
**テスト 1: Round-trip（write → read）**
```rust
#[test]
fn test_filebox_write_read_roundtrip() {
// 一時ファイル（/tmp/phase108_test.txt）に書き込み
// その後同じ FileBox で read して内容一致確認
// テスト終了後は cleanup
}
```
**テスト 2: Read-only provider での write 拒否**
```rust
#[test]
fn test_filebox_write_readonly_provider() {
// caps.write=false な mock provider を使用
// write() が Error StringBox を返すことを確認
}
```
**テスト 3: Double-open の挙動確認**（既存テスト参照）
```rust
#[test]
fn test_filebox_double_open() {
// 同じ path で open 2回 → Err or overwrite
// Phase 107 で決めたセマンティクスと一致していることを確認
// (既存テスト test_ring0fs_fileio_double_open_error を参考に)
}
```
---
## 6. Task 5: docs 更新 & CURRENT_TASK 反映
### 6.1 実装内容
**ファイル**:
- `phase107_fsapi_fileio_bridge.md`（追記）
- **新規**: `phase108_filebox_write_semantics.md`（このドキュメント）
- `core_boxes_design.md`（FileBox セクション）
- `CURRENT_TASK.md`
### 6.2 やること
1. **phase107_fsapi_fileio_bridge.md に追記**：
- Section 8「Phase 108 以降の計画」に一文：
- 「Phase 108 で write 実装が完了し、FileBox は read/write 両対応になった」
2. **phase108_filebox_write_semantics.md を本ドキュメントとして保存**：
- write mode（truncate）の設計
- trait 拡張の互換性ポイント
- テスト設計
3. **core_boxes_design.md に追記**：
- FileBox セクションに：
- 「FileBox は Ring0FsFileIo 経由で read/write をサポート（Phase 108）」
- 「write は truncate mode（毎回上書き）」
- 「append モードは Phase 109+ で予定」
4. **CURRENT_TASK.md に反映**：
- Phase 108 完了行を追加
- 次候補（Phase 109 minimal/no-fs, Phase 110 FileHandleBox, Phase 111 append mode）をバックログに記載
---
## 7. 実装チェックリスト（Phase 108）
- [ ] FsApi.write_all() 実装と Ring0FsFileIo::write が接続されている
- [ ] FileIo trait に write() が追加され、すべての実装が対応している
- [ ] DummyFileIo などテスト用 FileIo も write() stub を実装している
- [ ] FileBox.write / write_all が provider 経由で実際にファイルを書ける
- [ ] FileCaps.write が Ring0FsFileIo では true になっている
- [ ] Round-trip テスト（write → read）が PASS
- [ ] Read-only provider 拒否テストが PASS
- [ ] Double-open テストが既存セマンティクスと一致
- [ ] core_boxes_design / phase108 docs / CURRENT_TASK が更新済み
- [ ] ビルド・テスト完全成功（特に FileBox 関連）
---
## 8. 設計原則（Phase 108 で確立）
### FileBox I/O の完全パイプライン
```
[FileBox.write(content)]
↓
[FileBox.write_all(buf)]
↓
[provider.write(text)] ← Ring0FsFileIo が実装
↓
[Ring0.FsApi.write_all()]
↓
[std::fs::write()]
```
### プロファイル戦略
**標準プロファイル**:
- Ring0FsFileIo（write: true）→ FileBox は read/write 両対応
**将来の minimal/no-fs**:
- DummyFileIo（write: false）→ FileBox は read-only に
### 拡張ポイント
- Phase 109: append モード追加
- Phase 110: FileHandleBox（複数ファイル同時）
- Phase 111: 権限・ロック機構
---
## 9. Phase 109 以降の計画
### Phase 109: RuntimeProfile 機構の追加
**Phase 109 完了により、FileBox は conditional required に変更されました**：
- **RuntimeProfile enum 導入**（Default/NoFs）
- **Default profile**: FileBox は required（Phase 107/108 の動作を維持）
- **NoFs profile**: FileBox は optional（NoFsFileIo stub で無効化）
**設計変更**:
```rust
// Phase 109 以前: FileBox は常に required
CoreBoxId::File.is_core_required() // → true
// Phase 109 以降: profile 依存の判定に
CoreBoxId::File.is_required_in(&RuntimeProfile::Default) // → true
CoreBoxId::File.is_required_in(&RuntimeProfile::NoFs) // → false
```
**プロファイル別動作**:
- **Default**: Ring0FsFileIo（read/write 両対応）自動登録
- **NoFs**: NoFsFileIo（全操作で Unsupported エラー）登録
**将来の拡張計画**（Phase 109 Modification 3）:
- TestMock: テスト用（全プラグインが mock に）
- Sandbox: サンドボックス（外部 I/O 禁止）
- ReadOnly: 読み取り専用（FileBox.write 禁止）
- Embedded: 組み込み（メモリ制限・GC あり）
**互換性**:
- Phase 107/108 の既存動作は Default profile で完全維持
- NoFs profile は完全に新規追加（既存コードに影響なし）
---
**Phase 108 指示書作成日**: 2025-12-03（微調整版）
**Phase 109 追記**: 2025-12-03（RuntimeProfile 統合完了）
Status: Historical

425
docs/archive/phases/phase-106-156/phase109_runtime_profiles.md Normal file
View File

@ -0,0 +1,425 @@
# Phase 109: minimal/no-fs プロファイル設計（FileBox optional モード）
## 0. ゴール
- Phase 107-108 で実装完了した FileBox/Ring0.FsApi パイプラインを、**RuntimeProfile システムで条件付き有効化** する
- selfhost/standard では FileBox が core_required、minimal/no-fs では optional に動的に切り替え可能にする
- **Fail-Fast 原則を維持**：required な場合は初期化時にエラー、optional な場合は黙って無効化
---
## 1. スコープと非スコープ
### スコープ（今回やること）
- RuntimeProfile enum 定義（Default, NoFs）+ phase 108 系 統合
- CoreBoxId に `is_required_in(profile: &RuntimeProfile) -> bool` ヘルパー追加
- PluginHost に profile-aware 初期化ロジック追加
- no-fs profile での FileBox provider チェック（missing OK、Err は "disabled for this profile"）
- ドキュメント + テスト追加
### 非スコープ（今回はやらない）
- 実際の TestMock/Sandbox/ReadOnly/Embedded プロファイル実装（Phase 110 以降で検討）
- profile ごとのプラグイン自動フィルタリング（手動制御に）
- Ring0 service registry 統一化（Phase 112 候補）
---
## 2. Task 1: RuntimeProfile enum + is_required_in() ヘルパー
### 2.1 実装内容
**ファイル**:
- `src/runtime/runtime_profile.rs`（新規）
- `src/runtime/core_box_ids.rs`（修正）
### 2.2 RuntimeProfile 定義
```rust
// src/runtime/runtime_profile.rs
/// Phase 109: RuntimeProfile
///
/// FileBox（およびその他オプションサービス）の有効/無効を制御する。
///
/// - Default: selfhost/standard - ほぼすべてのサービス有効
/// - NoFs: 最小ランタイム - FileBox/Regex/Time 等をスキップ
///
/// 拡張予定：TestMock（テスト用）, Sandbox（サンドボックス）, ReadOnly（読み取り専用）, Embedded（組み込み）
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum RuntimeProfile {
/// Standard runtime (selfhost/default)
Default,
/// Minimal runtime without FileSystem
NoFs,
}
impl RuntimeProfile {
/// str から RuntimeProfile を取得
pub fn from_env() -> Self {
match std::env::var("NYASH_RUNTIME_PROFILE").as_deref() {
Ok("no-fs") | Ok("nofs") => RuntimeProfile::NoFs,
_ => RuntimeProfile::Default,
}
}
/// デバッグ出力
pub fn name(&self) -> &'static str {
match self {
RuntimeProfile::Default => "Default",
RuntimeProfile::NoFs => "NoFs",
}
}
}
```
### 2.3 CoreBoxId に is_required_in() 追加
```rust
// src/runtime/core_box_ids.rs - impl CoreBoxId ブロック内に追加
/// Phase 109: profile-aware required チェック
///
/// - Default: Phase 106 の is_core_required() と同じ（FileBox required）
/// - NoFs: FileBox は optional に（その他 core_required は維持）
pub fn is_required_in(&self, profile: &RuntimeProfile) -> bool {
use CoreBoxId::*;
let core_required = matches!(self, String | Integer | Bool | Array | Map | Console);
match profile {
RuntimeProfile::Default => {
// Phase 106: File を実質必須扱い
self.is_core_required()
}
RuntimeProfile::NoFs => {
// File 以外は core_required と同じ
core_required
}
}
}
#[cfg(test)]
mod tests {
#[test]
fn test_core_box_id_is_required_in_default() {
let profile = RuntimeProfile::Default;
assert!(CoreBoxId::String.is_required_in(&profile));
assert!(CoreBoxId::File.is_required_in(&profile)); // Default では required
}
#[test]
fn test_core_box_id_is_required_in_nofs() {
let profile = RuntimeProfile::NoFs;
assert!(CoreBoxId::String.is_required_in(&profile));
assert!(!CoreBoxId::File.is_required_in(&profile)); // NoFs では optional
}
}
```
### 2.4 Profile 拡張予定（設計メモ）
```rust
// 将来の enum 拡張予定
//
// TestMock: テスト用（すべてのプラグインが mock に）
// Sandbox: サンドボックス（外部 I/O 禁止）
// ReadOnly: 読み取り専用（FileBox.write 禁止）
// Embedded: 組み込み（メモリ制限あり、GC あり）
```
---
## 3. Task 2: PluginHost profile-aware 初期化
### 3.1 実装内容
**ファイル**:
- `src/runtime/plugin_host.rs`（修正）
### 3.2 修正内容
```rust
// src/runtime/plugin_host.rs
impl PluginHost {
/// Phase 109: profile-aware with_core_from_registry
pub fn with_core_from_registry(
ring0: Arc<Ring0Context>,
registry: &UnifiedBoxRegistry,
profile: &RuntimeProfile, // ← 新規引数
) -> Result<Self, CoreInitError> {
// Phase 106: 必須 Box の registered 状態を確認
for box_id in CoreBoxId::iter() {
if box_id.is_required_in(profile) && !registry.contains(box_id.name()) {
return Err(CoreInitError::MissingService {
box_id,
hint: format!(
"Core Box {} is required in {:?} profile",
box_id.name(),
profile.name()
),
});
}
}
// FileBox provider チェック（Phase 107）
match profile {
RuntimeProfile::Default => {
// Phase 108: FileBox provider 必須
if provider_lock::get_filebox_provider().is_none() {
return Err(CoreInitError::MissingService {
box_id: CoreBoxId::File,
hint: "FileBox provider not initialized in Default profile".to_string(),
});
}
}
RuntimeProfile::NoFs => {
// Phase 109: FileBox provider 無くても OK（optional profile）
// provider_lock は無視、下記 Task 3 の disable_filebox() で対応
}
}
// ... 以下既存処理
Ok(self)
}
}
#[test]
fn test_with_core_from_registry_nofs_filebox_optional() {
// Phase 109: NoFs profile では FileBox provider なしで OK
let ring0 = Arc::new(default_ring0());
let registry = UnifiedBoxRegistry::with_env_policy();
let profile = RuntimeProfile::NoFs;
// provider_lock をクリア（PluginHost が無視するはず）
// → 実装時に適切なクリーンアップロジック追加
let result = PluginHost::with_core_from_registry(ring0, &registry, &profile);
assert!(result.is_ok()); // ✅ 必須でないので OK
}
```
---
## 4. Task 3: initialize_runtime() に profile 読み込み機構
### 4.1 実装内容
**ファイル**:
- `src/runner/initialize_runtime.rs`（新規 or 修正）
- `src/runner/modes/vm.rs`（修正）
### 4.2 修正内容：profile 読み込み層の責務分離
**修正1（Task 3 責務明示）**:
```rust
// src/runner/initialize_runtime.rs
/// Phase 109: profile-aware runtime 初期化
///
/// **責務分離**:
/// - initialize_runtime: 環境変数から profile を読む（唯一の env reader）
/// - PluginHost: profile を引数として受け取る（env に依存しない）
pub fn initialize_runtime(ring0: &Arc<Ring0Context>) -> Result<PluginHost, InitError> {
// 1. Profile を環境変数から読む（この層のみで実施）
let profile = RuntimeProfile::from_env();
// 2. No-FS profile の場合、FileBox provider を明示的に disabled に
if profile == RuntimeProfile::NoFs {
disable_filebox_provider();
}
// 3. PluginHost に profile を渡す
let registry = UnifiedBoxRegistry::with_env_policy();
PluginHost::with_core_from_registry(ring0, &registry, &profile)
}
/// Phase 109: no-fs profile 用 FileBox 無効化
fn disable_filebox_provider() {
// provider_lock に特別な "disabled" マーカーを設定
// または、Task 4 の ReadOnlyFileIo で Err を返すようにする
}
```
---
## 5. Task 4: no-fs profile での FileBox 無効化実装
### 5.1 実装内容
**ファイル**:
- `src/providers/ring1/file/nofs_fileio.rs`（新規）
- `src/runtime/provider_lock.rs`（修正）
- `src/runtime/plugin_host.rs`（修正）
### 5.2 NoFsFileIo（スタブ実装）
```rust
// src/providers/ring1/file/nofs_fileio.rs
/// Phase 109: no-fs profile 用 FileBox stub
///
/// すべてのメソッドが Err を返す。
pub struct NoFsFileIo;
impl FileIo for NoFsFileIo {
fn caps(&self) -> FileCaps {
FileCaps { read: false, write: false }
}
fn open(&self, path: &str) -> FileResult<()> {
Err(FileError::Unsupported(
"FileBox is disabled in no-fs profile".to_string()
))
}
fn read(&self) -> FileResult<String> {
Err(FileError::Unsupported(
"FileBox is disabled in no-fs profile".to_string()
))
}
fn write(&self, _text: &str) -> FileResult<()> {
Err(FileError::Unsupported(
"FileBox is disabled in no-fs profile".to_string()
))
}
fn close(&self) -> FileResult<()> {
Err(FileError::Unsupported(
"FileBox is disabled in no-fs profile".to_string()
))
}
}
```
### 5.3 provider_lock の profile-aware init
```rust
// src/runtime/provider_lock.rs
/// Phase 109: profile を考慮した provider 初期化
pub fn init_filebox_provider_for_profile(
ring0: &Arc<Ring0Context>,
profile: &RuntimeProfile,
) -> Result<(), String> {
match profile {
RuntimeProfile::Default => {
// Phase 107: 標準プロファイルでは Ring0FsFileIo を使用
init_default_filebox_provider(ring0)
}
RuntimeProfile::NoFs => {
// Phase 109: no-fs プロファイルでは NoFsFileIo を使用
set_filebox_provider(Arc::new(NoFsFileIo))
}
}
}
```
### 5.4 Logger/ConsoleService はそのまま有効（修正2: Logger関係）
**修正2（Task 4 Logger関係）**:
```rust
// docs/comment
/// Phase 109: no-fs プロファイルでのサービス有効性
///
/// ✅ 有効（no-fs でも必須）:
/// - Ring0.log（OS抽象化層 - panic/exit 時の最終出力）
/// - ConsoleBox（言語レベル console - stdout/stderr）
/// - その他 core_required（String/Integer/Array 等）
///
/// ❌ 無効（no-fs では disabled）:
/// - FileBox（ファイルシステム依存）
/// - Regex/Time/JSON等のオプショナル boxes（将来：profile ごとに制御可能）
```
---
## 6. Task 5: docs 更新 & CURRENT_TASK 反映
### 6.1 実装内容
**ファイル**:
- `phase108_filebox_write_semantics.md`（追記）
- **新規**: `phase109_runtime_profiles.md`（このドキュメント）
- `core_boxes_design.md`（更新）
- `CURRENT_TASK.md`
### 6.2 やること
1. **phase108_filebox_write_semantics.md に追記**：
- Section 9「Phase 109 以降の計画」に：
- 「Phase 109 で RuntimeProfile 機構が追加され、FileBox は conditional required に」
2. **phase109_runtime_profiles.md を本ドキュメントとして保存**：
- RuntimeProfile enum + is_required_in() 設計
- profile 読み込み層の責務分離（修正1）
- Logger/ConsoleService の有効性（修正2）
- 将来 Profile 拡張予定（修正3）
3. **core_boxes_design.md に追記**：
- Section 5.4「Phase 109 - RuntimeProfile」に：
- 「Default では FileBox required、NoFs では optional」
- 「profile = env var 読み込み（initialize_runtime 層のみ）」
- 「将来 TestMock/Sandbox/ReadOnly/Embedded への拡張計画」
4. **CURRENT_TASK.md に反映**：
- Phase 109 完了行を追加
- 次候補（Phase 110 FileHandleBox, Phase 111 append mode）をバックログに記載
---
## 7. 実装チェックリスト（Phase 109）
- [ ] RuntimeProfile enum + RuntimeProfile::from_env() 実装
- [ ] CoreBoxId.is_required_in(profile) ヘルパー実装
- [ ] NoFsFileIo スタブ実装
- [ ] PluginHost.with_core_from_registry(profile 引数追加) に profile-aware チェック
- [ ] initialize_runtime に profile 読み込み責務（修正1）
- [ ] initialize_runtime が disable_filebox_provider() 呼び出し（no-fs 時）
- [ ] Logger/ConsoleService の有効性を文書化（修正2）
- [ ] Profile 拡張予定を列挙（修正3）
- [ ] PluginHost.test_with_core_from_registry_nofs_filebox_optional() パス
- [ ] core_boxes_design / phase109 docs / CURRENT_TASK 更新済み
- [ ] ビルド・テスト完全成功
---
## 8. 設計原則（Phase 109 で確立）
### RuntimeProfile の位置づけ
```
【Layer】 【責務】 【Example】
────────────────────────────────────────────────────────
env User configuration NYASH_RUNTIME_PROFILE=no-fs
initialize_runtime() env → RuntimeProfile profile = RuntimeProfile::from_env()
PluginHost profile-aware checks is_required_in(&profile)
CoreBoxId 条件付き required 判定 is_required_in(&profile)
provider_lock provider 登録（Profile 後）set_filebox_provider()
FileBox provider 経由 read/write 実装
```
### Fail-Fast の段階的サポート
```
【Profile】 【FileBox チェック】 【Error 時】
────────────────────────────────────────────────────────
Default init 時に provider 必須 CoreInitError::MissingService
NoFs init 時に provider OK (optional なので無視)
(実行時 read/write) FileError::Unsupported
```
### 拡張ポイント
- Phase 110: FileHandleBox（複数ファイル同時）
- Phase 111: append mode 追加
- Phase 112: Ring0 service registry 統一化
- Phase 113: TestMock/Sandbox/ReadOnly/Embedded profile 実装
---
**Phase 109 指示書作成日**: 2025-12-03（3修正案統合版）
Status: Historical

594
docs/archive/phases/phase-106-156/phase110_filehandlebox_design.md Normal file
View File

@ -0,0 +1,594 @@
# Phase 110: FileHandleBox 設計（複数回アクセス対応）
## 0. ゴール
- Phase 108 で実装した FileBox（「1ショット I/O」：read/write 1回ずつ）を補完する
- FileHandleBox（「複数回アクセス I/O」：open → read/write/read → close）を設計・実装
- **Ring0FsFileIo を内部で再利用**して、レイヤー統一を維持
- **RuntimeProfile との整合**：Default では使用可能、NoFs では使用不可
---
## 1. スコープと非スコープ
### スコープ（今回やること）
1. **設計ドキュメントの作成**
- FileBox / FileHandleBox / FileIo / FsApi の役割と関係を定義
- FileHandleBox の API（open/read/write/close 等）とライフサイクルを決める
- 二重 open 時の仕様を明記
2. **Rust 側の最小実装**
- FileHandleBox の型スケルトンと trait 実装（NyashBox）を追加
- Ring0FsFileIo を内部で使い回す形で、最小の open/read/write/close を通す
- close() 後の挙動を明確に定義
3. **プロファイルとの整合**
- RuntimeProfile::Default のときは FileHandleBox が使用可能
- RuntimeProfile::NoFs のときは FileHandleBox は禁止（open 時にエラー）
### 非スコープ（今回はやらない）
- FileHandleBox を Nyash (.hako) 側からフル運用するサンプル大量追加（必要なら 1–2 個の最小例だけ）
- ファイルロック/権限/並行書き込みなどの高度機能
- FileBox API 自体の破壊的変更（既存の read/write の意味は維持）
- append mode（Phase 111 で扱う）
---
## 2. Task 1: 設計ドキュメント作成
### 2.1 ファイル
- `docs/development/current/main/phase110_filehandlebox_design.md`（このドキュメント）
### 2.2 目的と役割分担
**FileBox（Phase 108）**:
- シンプルな 1 ショット I/O
- `read(path) -> String` / `write(path, content) -> OK/Error` のようなメソッド
- ファイルを開いて → 読む/書く → 閉じるをすべて隠す
- ユースケース：ログ書き込み、ワンショット設定ファイル読み込み
**FileHandleBox（Phase 110）**:
- 複数回アクセス I/O
- ハンドルで 1 ファイルを確保 → open/read/write/close を自分で制御
- ユースケース：大きなテキストファイルの行単位読み込み、逐次更新
**レイヤー図**:
```
[FileBox] [FileHandleBox]
| |
└──────┬────────────────┘
| (FileIo trait)
v
[Ring0FsFileIo]
|
v (FsApi)
[Ring0.fs]
|
v
[std::fs]
```
### 2.3 ライフサイクル設計
#### FileHandleBox のライフサイクル
```
1. birth() / new()
└─ path 未指定、io 未初期化（None）
└ファイルはまだ開かれない
2. open(path, mode)
└─ Ring0FsFileIo をこのインスタンス用に作成して保持
└─ FileIo.open(path) を内部で呼び出す
└─ 以後 read/write が利用可能に
3. 複数回 read/write
└─ 同じハンドルで繰り返し呼び出し可能
└─ close() されるまで有効
4. close()
└─ 内部 FileIo をリセット（Option::None に）
└─ 以後 read/write は Err("FileHandleBox is not open")
5. Drop 時
└─ close() 忘れがあれば、警告ログを出す（Phase 110 では実装可能、または後回し）
```
#### .hako 側での使用パターン
```nyash
// パターン1: 新しいファイルに書き込み
local h = new FileHandleBox()
h.open("/tmp/output.txt", "w")
h.write("line 1")
h.write("line 2")
h.close()
// パターン2: 既存ファイルを読む
local h = new FileHandleBox()
h.open("/tmp/input.txt", "r")
local content = h.read()
h.close()
// パターン3: close() 忘れ（警告ログまたはパニック、Phase 110 で決定）
local h = new FileHandleBox()
h.open("/tmp/data.txt", "w")
h.write("data")
// close() なしで終了 ← 警告が出るかもしれない
```
### 2.4 二重 open の仕様（重要）
**方針**:
- 最初の open → 成功、io が Some(FileIo) に
- 2 番目の open → エラーを返す（Fail-Fast）
- 理由：複数ファイルハンドルが必要なら複数 FileHandleBox インスタンスを使う
**実装**:
```rust
pub fn open(&mut self, path: &str, mode: &str) -> Result<(), String> {
// 既に open 済みなら error
if self.io.is_some() {
return Err("FileHandleBox is already open. Call close() first.".to_string());
}
// 新規 open
let io = Arc::new(Ring0FsFileIo::new(self.ring0.clone()));
io.open(path)?;
self.io = Some(io);
Ok(())
}
```
### 2.5 close() 後の読み書き
```rust
pub fn read_to_string(&self) -> Result<String, String> {
self.io.as_ref()
.ok_or("FileHandleBox is not open".to_string())?
.read()
}
pub fn write_all(&self, content: &str) -> Result<(), String> {
self.io.as_ref()
.ok_or("FileHandleBox is not open".to_string())?
.write(content)
}
```
---
## 3. Task 2: API 定義（Rust 側インターフェース）
### 3.1 ファイル
- `src/boxes/file/mod.rs`（または新規 `src/boxes/file/handle_box.rs`）
- `src/boxes/file/provider.rs`（必要に応じて）
### 3.2 Rust 側 struct 定義
```rust
/// Phase 110: FileHandleBox
///
/// ハンドルベースのファイル I/O。
/// open(path, mode) → read/write → close() という複数回アクセスをサポート。
pub struct FileHandleBox {
base: BoxBase,
path: String,
mode: String,
io: Option<Arc<dyn FileIo>>, // 各インスタンスが独立した FileIo を保持
}
```
### 3.3 NyashBox 実装
```rust
impl NyashBox for FileHandleBox {
fn type_name(&self) -> &str {
"FileHandleBox"
}
fn to_string_box(&self) -> StringBox {
StringBox::new(format!("FileHandleBox(path={}, mode={}, open={})",
self.path, self.mode, self.is_open()))
}
fn equals(&self, _other: &dyn NyashBox) -> bool {
// FileHandleBox インスタンスは path + mode で比較
// 厳密でなくて OK
false // 簡易実装
}
fn as_any(&self) -> &dyn std::any::Any {
self
}
}
```
### 3.4 メソッドセット
```rust
impl FileHandleBox {
/// 新規 FileHandleBox を作成（ファイルはまだ open されない）
pub fn new() -> Self {
FileHandleBox {
base: BoxBase::new(),
path: String::new(),
mode: String::new(),
io: None,
}
}
/// ファイルを開く
///
/// # Arguments
/// - path: ファイルパス
/// - mode: "r" (読み込み) or "w" (上書き) ※ Phase 111 で "a" (append) 追加予定
///
/// # Error
/// - 既に open されている場合: "FileHandleBox is already open. Call close() first."
/// - ファイルが見つからない場合（mode="r"）: "File not found"
pub fn open(&mut self, path: &str, mode: &str) -> Result<(), String> {
// 二重 open チェック
if self.io.is_some() {
return Err("FileHandleBox is already open. Call close() first.".to_string());
}
// mode 検証
if mode != "r" && mode != "w" {
return Err(format!("Unsupported mode: {}. Use 'r' or 'w'", mode));
}
// 新規 FileIo 作成（Ring0FsFileIo）
// ※ provider_lock から取得するか、直接生成するかは実装で決定
let io = Arc::new(Ring0FsFileIo::new(ring0.clone()));
io.open(path)?;
self.path = path.to_string();
self.mode = mode.to_string();
self.io = Some(io);
Ok(())
}
/// ファイルの内容を全て読む
///
/// # Error
/// - open されていない場合: "FileHandleBox is not open"
pub fn read_to_string(&self) -> Result<String, String> {
self.io.as_ref()
.ok_or("FileHandleBox is not open".to_string())?
.read()
}
/// ファイルに内容を書き込む（上書きモード）
///
/// # Error
/// - open されていない場合: "FileHandleBox is not open"
/// - write mode でない場合: "FileHandleBox opened in read mode"
pub fn write_all(&self, content: &str) -> Result<(), String> {
if self.mode != "w" {
return Err("FileHandleBox opened in read mode".to_string());
}
self.io.as_ref()
.ok_or("FileHandleBox is not open".to_string())?
.write(content)
}
/// ファイルを閉じる
///
/// # Error
/// - open されていない場合: "FileHandleBox is not open"
pub fn close(&mut self) -> Result<(), String> {
if self.io.is_none() {
return Err("FileHandleBox is not open".to_string());
}
// 内部 FileIo を drop
self.io.take();
self.path.clear();
self.mode.clear();
Ok(())
}
/// ファイルが open されているかチェック
pub fn is_open(&self) -> bool {
self.io.is_some()
}
}
```
### 3.5 Ring0FsFileIo の独立性（重要）
**設計原則**:
- 各 FileHandleBox インスタンスが **独立した FileIo を保持**
- 複数の FileHandleBox が同時に異なるファイルを open できる
**例**:
```rust
let mut h1 = FileHandleBox::new();
h1.open("/tmp/file1.txt", "r")?;
let mut h2 = FileHandleBox::new();
h2.open("/tmp/file2.txt", "w")?;
// h1 と h2 は別々の FileIo（Ring0FsFileIo）を持つ
// h1.read() と h2.write() は同時実行可能
h1.close()?;
h2.close()?;
```
---
## 4. Task 3: プロファイルとの整合
### 4.1 ファイル
- `src/runtime/provider_lock.rs`（必要に応じて）
- `src/runtime/runtime_profile.rs`
- `docs/development/current/main/phase110_filehandlebox_design.md`（このドキュメント）
### 4.2 FileHandleBox のプロファイル位置づけ
**RuntimeProfile::Default**:
- **位置づけ**: optional（コアボックスではない）
- **動作**:
- provider_lock に FileIo が登録されている
- FileHandleBox.open() は成功する
- read/write 可能
**RuntimeProfile::NoFs**:
- **位置づけ**: 使用不可（disabled）
- **動作**:
- provider_lock に FileIo が登録されない（NoFsFileIo のみ）
- FileHandleBox.open() を呼ぶと：
```
Err("File I/O disabled in no-fs profile. FileHandleBox is not available.")
```
**将来計画（Phase 113+）**:
- **RuntimeProfile::TestMock**: mock FileIo を使用（テスト用）
- **RuntimeProfile::Sandbox**: 指定ディレクトリのみアクセス可能
- **RuntimeProfile::ReadOnly**: 読み取り専用（write Err）
### 4.3 Policy 記述
```markdown
## プロファイル別の可用性
| Profile | FileBox | FileHandleBox | 特性 |
|----------|---------|---------------|------|
| Default | ✅ | ✅ | 完全なファイル I/O |
| NoFs | ❌ | ❌ | ファイル I/O 禁止 |
| TestMock (TBD) | ✅ mock | ✅ mock | テスト用ダミー |
| Sandbox (TBD) | ✅ dir限定 | ✅ dir限定 | サンドボックス |
**注意**: FileHandleBox は optional boxes だが、NoFs では
「disabled」として扱う（optional ではなく「使用不可」）
```
---
## 5. Task 4: 最小限のテストとサンプル
### 5.1 ファイル
- `src/boxes/file/tests.rs`（新規 or 既存に追加）
- `apps/examples/file_handle_min.hako`（オプション、.hako 側のサンプル）
### 5.2 テスト内容
#### テスト 1: Default プロファイル - 基本動作
```rust
#[test]
fn test_filehandlebox_basic_write_read() {
// 新しいファイルに書き込み
let mut h = FileHandleBox::new();
assert!(!h.is_open());
let tmp_path = "/tmp/phase110_test_write_read.txt";
h.open(tmp_path, "w").expect("open failed");
assert!(h.is_open());
h.write_all("hello world").expect("write failed");
h.close().expect("close failed");
assert!(!h.is_open());
// 同じファイルを読む
let mut h2 = FileHandleBox::new();
h2.open(tmp_path, "r").expect("open failed");
let content = h2.read_to_string().expect("read failed");
assert_eq!(content, "hello world");
h2.close().expect("close failed");
// cleanup
std::fs::remove_file(tmp_path).ok();
}
```
#### テスト 2: 二重 open error
```rust
#[test]
fn test_filehandlebox_double_open_error() {
let mut h = FileHandleBox::new();
h.open("/tmp/test.txt", "w").expect("first open");
// 2 番目の open は error
let result = h.open("/tmp/test2.txt", "w");
assert!(result.is_err());
assert!(result.unwrap_err().contains("already open"));
}
```
#### テスト 3: close() 後のアクセス error
```rust
#[test]
fn test_filehandlebox_closed_access_error() {
let mut h = FileHandleBox::new();
h.open("/tmp/test.txt", "w").expect("open");
h.close().expect("close");
// close 後の read は error
let result = h.read_to_string();
assert!(result.is_err());
assert!(result.unwrap_err().contains("not open"));
}
```
#### テスト 4: NoFs プロファイル - open error
```rust
#[test]
fn test_filehandlebox_nofs_profile_disabled() {
// NYASH_RUNTIME_PROFILE=no-fs で実行される想定
let profile = RuntimeProfile::NoFs;
let mut h = FileHandleBox::new();
let result = h.open_with_profile("/tmp/test.txt", "r", &profile);
assert!(result.is_err());
assert!(result.unwrap_err().contains("disabled in no-fs profile"));
}
```
### 5.3 .hako 側サンプル（オプション）
**apps/examples/file_handle_min.hako**:
```nyash
// File handle を使った行単位読み込みのプロトタイプ（将来）
// Phase 110 では不要。Phase 111 以降で追加予定
```
---
## 6. Task 5: ドキュメント更新
### 6.1 ファイル
- `docs/development/current/main/core_boxes_design.md`（修正）
- `docs/development/current/main/ring0-inventory.md`（修正）
- `CURRENT_TASK.md`（修正）
### 6.2 やること
#### core_boxes_design.md 更新
新セクション「5.5 Phase 110 - FileHandleBox」を追加：
```markdown
### 5.5 Phase 110 - FileHandleBox
FileBox（ワンショット I/O）を補完するハンドルベースのファイル I/O。
- **位置づけ**: core_optional（future で core_required に昇格の可能性）
- **API**: open(path, mode) → read/write → close()
- **プロファイル対応**: Default ✅、NoFs ❌
- **実装**: Ring0FsFileIo を内部で再利用
詳細: [Phase 110 設計書](phase110_filehandlebox_design.md)
```
#### ring0-inventory.md 更新
「File I/O Service」セクションの「Future Expansion」に追記：
```markdown
## Future Expansion
- Phase 110: FileHandleBox（ハンドルベース複数回アクセス）
- Phase 111: append mode サポート
- Phase 112: metadata / stat サポート
- Phase 113: Ring0 service registry 統一化
```
#### CURRENT_TASK.md 更新
- Phase 110 を「計画中 → 進行中」に変更（実装開始時）
- Phase 110 完了後に「進行中 → 完了」に更新
- Backlog の「FileHandleBox」項目を消す
- 次の候補（append mode, metadata）を記載
---
## 7. 実装チェックリスト（Phase 110）
- [ ] phase110_filehandlebox_design.md が存在し、全 5 Task が記述されている
- [ ] Rust 側に FileHandleBox struct が追加されている
- [ ] FileHandleBox が NyashBox を実装している
- [ ] open/read/write/close/is_open メソッドが全て実装されている
- [ ] 二重 open が Err を返すことが確認されている
- [ ] close() 後のアクセスが Err を返すことが確認されている
- [ ] Default プロファイルでの基本動作テストが PASS
- [ ] NoFs プロファイルでの open Err テストが PASS
- [ ] FileBox の既存 API と挙動は変わっていない
- [ ] core_boxes_design.md / ring0-inventory.md / CURRENT_TASK.md が Phase 110 と整合している
- [ ] cargo build --release SUCCESS
- [ ] cargo test --release 全テスト PASS
---
## 8. 設計原則（Phase 110 で確立）
### 複数ファイルアクセス パターン
```
【1つのファイルを複数回】
local h = new FileHandleBox()
h.open("/file", "w")
h.write("data1")
h.write("data2")
h.close()
【複数のファイル同時アクセス】
local h1 = new FileHandleBox()
h1.open("/file1", "r")
local h2 = new FileHandleBox()
h2.open("/file2", "w")
h1.close()
h2.close()
```
### Fail-Fast 原則の適用
- open() 呼び出し時に既に open 済み → 即座に Err
- close() 後の read/write → 即座に Err
- NoFs profile で open → 即座に Err
### 後方互換性
- FileBox は完全に独立（既存 API 変更なし）
- FileHandleBox は新規 Box として独立
- Ring0FsFileIo の変更なし
---
## 9. 将来への拡張ポイント
### Phase 111: append mode + metadata（完了 ✅）
- **append mode**: `mode = "a"` を実装、末尾に追記可能に
- **metadata API**: size / exists / is_file / is_dir を内部 Rust API として実装
- **FsApi.append_all()**: write_all と対称的に追加
- **実装完了**: Commit fce7555e で 4 つのテスト全て PASS
### Phase 112 以降の計画
- **Phase 112**: Ring0 Service Registry 統一化（metadata に modified フィールド追加）
- **Phase 113**: FileHandleBox NyashBox 公開 API（.hako から metadata 呼び出し可能に）
- **Phase 114**: FileIo 機能拡張（exists/stat/canonicalize を trait に追加）
- **Phase 115**: 並行アクセス安全性（Arc<Mutex<...>>）
- **Phase 116**: file encoding explicit 指定（UTF-8 以外）
---
**Phase 110 設計書作成日**: 2025-12-03（修正版 5点統合）
**Phase 111 完成日**: 2025-12-03（修正案統合版、4 テスト全 PASS）
Status: Historical

633
docs/archive/phases/phase-106-156/phase111_filehandlebox_append_metadata.md Normal file
View File

@ -0,0 +1,633 @@
# Phase 111: FileHandleBox append モード + metadata 拡張
## 0. ゴール
- Phase 110 で作った FileHandleBox（複数回アクセス I/O）に対して:
- **"a" append モード** を追加して、ログ／追記用途に対応する。
- **ファイルメタデータ取得 API**（size / exists / is_file / is_dir）を設計・実装する。
- すべて Ring0FsFileIo → Ring0.FsApi 経由で行い、レイヤー構造と Fail-Fast を崩さない。
---
## 1. スコープと非スコープ
### スコープ（今回やること）
1. **設計ドキュメント**:
- append モードの意味（truncate との違い）を正確に定義。
- metadata API（size/exists/is_file/is_dir）を決定。
- FsApi 拡張（append_all）の位置づけを明記。
2. **FsApi / Ring0FsFileIo 側の拡張**:
- FsApi trait に `append_all(path, data)` メソッドを追加。
- Ring0FsFileIo で append/truncate の 2 モード実装。
3. **FileHandleBox API の拡張**:
- open(path, mode) に "a" サポート（"r"/"w"/"a" の 3 モード）。
- write_all が mode に応じて truncate/append を切り替え。
- metadata helper（size/exists/is_file/is_dir）を内部 Rust API として実装。
4. **Profile との整合**:
- Default: append & metadata 有効。
- NoFs: open 自体がエラー、metadata もエラー。
5. **テスト + ドキュメント**:
- FileHandleBox append テスト。
- metadata テスト。
- NoFs profile 対応テスト。
### 非スコープ（今回はやらない）
- modified（mtime）情報（Phase 112+ で検討）。
- FileBox（ワンショット API）側への append 追加（必要になれば後フェーズ）。
- パスワイルドカード、ディレクトリ列挙、ウォッチャなどの高度機能。
- ACL/パーミッション／ロックなどの OS 特有機能。
- **NyashBox 公開 API**（metadata メソッドの .hako 側からの呼び出し）→ Phase 112+ で検討。
---
## 2. Task 1: 設計ドキュメント（append ＋ metadata）
### 2.1 実装内容
**ファイル**:
- 本ドキュメント（phase111_filehandlebox_append_metadata.md）
### 2.2 設計決定
#### append モードの仕様
**open(path, "a") の意味**:
- 存在しない場合 → 新規作成。
- 存在する場合 → ファイル末尾に書き足す。
**write_all(content) の挙動**:
- Mode "w" → truncate（毎回上書き、Phase 108 決定どおり）。
- Mode "a" → append（末尾に追記）。
- Mode "r" で write_all → "FileHandleBox is opened in read-only mode" エラー。
**truncate vs append の明確な使い分け**:
```rust
// truncate mode: ログファイルを毎回リセット
handle.open("output.log", "w")?;
handle.write_all("Session started\n")?;
// append mode: 複数回の実行結果を累積
handle.open("history.log", "a")?;
handle.write_all("Operation 1\n")?; // 末尾に追記
handle.write_all("Operation 2\n")?; // さらに末尾に追記
```
#### metadata API の仕様
**最小限の属性セット**:
- `size()` → ファイルサイズ（バイト数）
- `exists()` → ファイルが存在するか
- `is_file()` → ファイルであるか（ディレクトリではない）
- `is_dir()` → ディレクトリであるか
**注: modified（mtime）は Phase 112 以降で検討**（FsMetadata への追加が必要）。
**ライフサイクルと metadata の関係**:
- **path が設定されていれば**（open 済みでなくても）metadata 取得可能。
- 例: close() 後でも stat 可能。
- 例: open せずに path だけ指定して metadata 取得（予定）。
理由: FsApi.metadata(path) は stateless な操作なので、FileIo インスタンスの有無に依存しない。
#### FsApi 拡張の位置づけ
**FsApi.append_all(path, data) の追加**:
- Phase 107: read_to_string / read / write_all が確立。
- Phase 111: append_all を追加（write_all と対称的）。
```rust
pub trait FsApi: Send + Sync {
fn read_to_string(&self, path: &Path) -> Result<String, IoError>;
fn read(&self, path: &Path) -> Result<Vec<u8>, IoError>;
fn write_all(&self, path: &Path, data: &[u8]) -> Result<(), IoError>;
fn append_all(&self, path: &Path, data: &[u8]) -> Result<(), IoError>; // ← 新規
fn exists(&self, path: &Path) -> bool;
fn metadata(&self, path: &Path) -> Result<FsMetadata, IoError>;
fn canonicalize(&self, path: &Path) -> Result<PathBuf, IoError>;
}
```
**Ring0FsFileIo での実装**:
- open(path, mode) で path と mode を保持。
- write(text) で:
- Mode "w" → FsApi.write_all(path, text.as_bytes())（truncate）。
- Mode "a" → FsApi.append_all(path, text.as_bytes())（append）。
- 内部 metadata_helper で FsApi.metadata(path) を呼び出し。
---
## 3. Task 2: FsApi / Ring0FsFileIo 拡張
### 3.1 実装内容
**ファイル**:
- `src/runtime/ring0/traits.rs`（FsApi trait 拡張）
- `src/runtime/ring0/std_impls.rs`（FsApi 実装）
- `src/providers/ring1/file/ring0_fs_fileio.rs`（Ring0FsFileIo 拡張）
### 3.2 やること
#### FsApi trait 拡張（src/runtime/ring0/traits.rs）
1. **append_all メソッドを追加**:
```rust
pub trait FsApi: Send + Sync {
// ... 既存メソッド ...
/// ファイルに追記（append）
///
/// ファイルが存在しない場合は新規作成、存在する場合は末尾に追記。
/// Phase 111: write_all と対称的に提供。
fn append_all(&self, path: &Path, data: &[u8]) -> Result<(), IoError>;
}
```
2. **FsMetadata の確認**:
- 既に実装済みの FsMetadata を確認：
```rust
pub struct FsMetadata {
pub is_file: bool,
pub is_dir: bool,
pub len: u64,
}
```
- Phase 111 では modified は追加しない（後フェーズで）。
#### std_impls.rs での実装
```rust
impl FsApi for StdFsApi {
fn append_all(&self, path: &Path, data: &[u8]) -> Result<(), IoError> {
use std::fs::OpenOptions;
use std::io::Write;
let mut file = OpenOptions::new()
.create(true) // 存在しなければ作成
.append(true) // append モードで開く
.open(path)
.map_err(|e| IoError::Io(format!("append_all failed: {}", e)))?;
file.write_all(data)
.map_err(|e| IoError::Io(format!("write failed: {}", e)))
}
}
```
#### Ring0FsFileIo での append 対応（src/providers/ring1/file/ring0_fs_fileio.rs）
1. **struct フィールド確認**:
- path, mode を保持していることを確認。
2. **write() メソッドを拡張**:
```rust
impl FileIo for Ring0FsFileIo {
fn write(&self, text: &str) -> FileResult<()> {
if self.mode == "a" {
// Append mode
self.ring0.fs.append_all(Path::new(&self.path), text.as_bytes())
.map_err(FileError::Io)
} else if self.mode == "w" {
// Truncate mode (default)
self.ring0.fs.write_all(Path::new(&self.path), text.as_bytes())
.map_err(FileError::Io)
} else if self.mode == "r" {
Err(FileError::Unsupported(
"Cannot write in read-only mode".to_string()
))
} else {
Err(FileError::Unsupported(
format!("Unsupported mode: {}", self.mode)
))
}
}
// 内部 metadata helper（phase 111）
fn metadata(&self) -> FileResult<crate::runtime::ring0::traits::FsMetadata> {
self.ring0.fs.metadata(Path::new(&self.path))
.map_err(FileError::Io)
}
}
```
3. **FileIo trait は追加しない** ← Phase 111 での決定：
- metadata メソッドは FileIo trait には追加せず、Ring0FsFileIo のプライベートメソッドとして実装。
- FileHandleBox が metadata 取得時に、Ring0FsFileIo の内部ヘルパを呼び出す形にする。
---
## 4. Task 3: FileHandleBox API 実装（append + metadata）
### 4.1 実装内容
**ファイル**:
- `src/boxes/file/handle_box.rs`
### 4.2 やること
#### open() メソッド拡張
```rust
pub fn open(&mut self, path: &str, mode: &str) -> Result<(), String> {
// Double-open チェック
if self.is_open() {
return Err(already_open());
}
// Mode バリデーション（"r", "w", "a" のみ）
if mode != "r" && mode != "w" && mode != "a" {
return Err(unsupported_mode(mode));
}
// NoFs profile チェック（既存）
if self.io.is_none() { // provider が無い
return Err(provider_disabled_in_nofs_profile());
}
// path と mode を保存
self.path = path.to_string();
self.mode = mode.to_string();
// FileIo に open を委譲（mode を含める）
self.io
.as_ref()
.unwrap()
.open(path)
.map_err(|e| format!("Open failed: {:?}", e))
}
```
**注**: mode パラメータはファイル操作のモード制御に使用し、FileIo.open() 呼び出し時には既に self.mode に保存されている。
#### write_all() メソッド拡張
```rust
pub fn write_all(&self, content: &str) -> Result<(), String> {
// open 済みチェック
if !self.is_open() {
return Err(not_open());
}
// read-only チェック
if self.mode == "r" {
return Err("FileHandleBox is opened in read-only mode".to_string());
}
// write (mode に基づいて truncate/append を切り替え)
self.io
.as_ref()
.unwrap()
.write(content)
.map_err(|e| format!("Write failed: {:?}", e))
}
```
**write() メソッド内**（Ring0FsFileIo）で mode チェックして append/truncate を判定。
#### metadata メソッド群（内部 Rust API）
```rust
impl FileHandleBox {
/// ファイルサイズを取得（バイト数）
///
/// Path さえあれば（open 済みでなくても）stat 可能。
pub fn size(&self) -> Result<u64, String> {
if self.path.is_empty() {
return Err("FileHandleBox path not set".to_string());
}
// Ring0FsFileIo の内部 metadata_helper を呼び出し
// または Ring0Context から直接 FsApi.metadata() を取得
// 詳細は実装時に決定
self.metadata_internal()
.map(|meta| meta.len)
}
/// ファイルが存在するか確認
pub fn exists(&self) -> Result<bool, String> {
if self.path.is_empty() {
return Err("FileHandleBox path not set".to_string());
}
self.metadata_internal()
.map(|_| true)
.or_else(|_| Ok(false)) // not found → false
}
/// ファイルであるか確認
pub fn is_file(&self) -> Result<bool, String> {
if self.path.is_empty() {
return Err("FileHandleBox path not set".to_string());
}
self.metadata_internal()
.map(|meta| meta.is_file)
}
/// ディレクトリであるか確認
pub fn is_dir(&self) -> Result<bool, String> {
if self.path.is_empty() {
return Err("FileHandleBox path not set".to_string());
}
self.metadata_internal()
.map(|meta| meta.is_dir)
}
/// 内部ヘルパー: FsApi.metadata を呼び出し
fn metadata_internal(&self) -> Result<crate::runtime::ring0::traits::FsMetadata, String> {
// 実装パターン:
// Option 1: io.as_ref().unwrap() から metadata() ヘルパを呼び出す
// Option 2: provider_lock から Ring0Context を取得して FsApi を呼び出す
// Phase 111 では Option 1 を推奨（io と path が一体的に扱える）
todo!("metadata_internal implementation")
}
}
```
**設計方針**:
- metadata メソッド群は **Rust 内部 API** として実装。
- .hako から呼び出す場合は、Phase 112+ で MethodBox 登録を検討。
- 現在は Unit テスト で動作確認するだけ。
---
## 5. Task 4: Profile との整合チェック
### 5.1 実装内容
**ファイル**:
- `src/runtime/runtime_profile.rs`（確認のみ、修正不要）
- `src/runtime/plugin_host.rs`（確認のみ、修正不要）
- `docs/development/current/main/phase111_filehandlebox_append_metadata.md`（本ドキュメント）
### 5.2 現行設計確認
#### Default プロファイル
- FileBox / FileHandleBox 両方が Ring0FsFileIo を使用。
- append / metadata も**フル機能**で動作。
#### NoFs プロファイル
- FileBox: open せず read/write でエラー "FileBox disabled in no-fs profile"。
- FileHandleBox: open 自体が "FS disabled in NoFs profile" エラーで拒否。
- metadata: NoFs で path を stat しない（実装上、open 済みだからこそ stat 可能という前提）。
**Phase 111 での確認**:
- NoFs profile でも metadata_internal() が呼び出されうるか？
- path が設定されている状態で metadata() を呼ぶ場合、どうするか。
- 現在の設計では io が無い状態では metadata も失敗（OK）。
---
## 6. Task 5: テスト + docs 更新
### 6.1 テスト
**ファイル**:
- `src/boxes/file/handle_box.rs` 内の test モジュール
#### テスト 1: append モード動作確認
```rust
#[test]
fn test_filehandlebox_append_mode() {
use std::fs;
let path = "/tmp/phase111_append_test.txt";
let _ = fs::remove_file(path); // cleanup
// First write (truncate)
let mut handle = FileHandleBox::new();
handle.open(path, "w").unwrap();
handle.write_all("hello\n").unwrap();
handle.close().unwrap();
// Append
let mut handle = FileHandleBox::new();
handle.open(path, "a").unwrap();
handle.write_all("world\n").unwrap();
handle.close().unwrap();
// Verify
let content = fs::read_to_string(path).unwrap();
assert_eq!(content, "hello\nworld\n");
let _ = fs::remove_file(path);
}
```
#### テスト 2: metadata（size）確認
```rust
#[test]
fn test_filehandlebox_metadata_size() {
use std::fs;
let path = "/tmp/phase111_metadata_test.txt";
let _ = fs::remove_file(path);
// Write test file
let mut handle = FileHandleBox::new();
handle.open(path, "w").unwrap();
handle.write_all("hello").unwrap(); // 5 bytes
handle.close().unwrap();
// Check size
let mut handle = FileHandleBox::new();
let size = handle.size().unwrap();
assert_eq!(size, 5);
let _ = fs::remove_file(path);
}
```
#### テスト 3: metadata（is_file / is_dir）確認
```rust
#[test]
fn test_filehandlebox_metadata_is_file() {
use std::fs;
let path = "/tmp/phase111_file_test.txt";
let _ = fs::remove_file(path);
// Create file
let mut handle = FileHandleBox::new();
handle.open(path, "w").unwrap();
handle.close().unwrap();
// Check is_file
let mut handle = FileHandleBox::new();
let is_file = handle.is_file().unwrap();
assert!(is_file);
let is_dir = handle.is_dir().unwrap();
assert!(!is_dir);
let _ = fs::remove_file(path);
}
```
#### テスト 4: read-only mode での write 拒否
```rust
#[test]
fn test_filehandlebox_write_readonly_error() {
use std::fs;
let path = "/tmp/phase111_readonly_test.txt";
let _ = fs::remove_file(path);
// Create file
fs::write(path, "content").unwrap();
// Open in read mode
let mut handle = FileHandleBox::new();
handle.open(path, "r").unwrap();
// Try to write → Error
let result = handle.write_all("new");
assert!(result.is_err());
assert!(result.unwrap_err().contains("read-only"));
let _ = fs::remove_file(path);
}
```
#### テスト 5: NoFs profile での open 拒否
```rust
#[test]
fn test_filehandlebox_nofs_profile_error() {
// NYASH_RUNTIME_PROFILE=no-fs を設定して実行
let mut handle = FileHandleBox::new();
let result = handle.open("/tmp/test.txt", "w");
assert!(result.is_err());
assert!(result.unwrap_err().contains("disabled"));
}
```
### 6.2 ドキュメント更新
#### phase110_filehandlebox_design.md に追記
Section 「Phase 111 との関係」を追加：
```markdown
### Phase 111: append モード + metadata 拡張
- **append モード**: open(path, "a") で末尾に追記。truncate (mode "w") と明確に区別。
- **metadata**: size / exists / is_file / is_dir を Ring0FsFileIo 経由で取得。
- **FsApi 拡張**: append_all(path, data) を追加（write_all と対称的）。
- **内部 Rust API**: metadata メソッド群は .hako 公開せず、テスト・内部用のみ。
- **modified（mtime）**: Phase 112+ で検討予定。
```
#### core_boxes_design.md 更新
FileHandleBox セクションに 1–2 行追記：
```markdown
- Phase 111: append モード + metadata API（size/exists/is_file/is_dir）実装完了。
```
#### CURRENT_TASK.md 更新
Phase 111 の完了行を追加：
```
## Phase 111: FileHandleBox append + metadata 拡張（完了予定）
- [ ] FsApi.append_all() 追加
- [ ] Ring0FsFileIo での append/truncate 切り替え実装
- [ ] FileHandleBox.open に "a" mode サポート
- [ ] FileHandleBox.metadata_internal / size / exists / is_file / is_dir 実装
- [ ] append テスト + metadata テスト + NoFs profile テスト
- [ ] core_boxes_design / phase111 docs 更新済み
- [ ] ビルド・テスト完全成功
## Backlog
### Phase 112: Ring0 Service Registry 統一化
- Ring0.log の統一レジストリ化
- provider_lock の汎用化
- metadata を FsMetadata に modified フィールド追加
### Phase 113: FileHandleBox NyashBox 公開 API
- metadata メソッドを .hako から呼び出し可能に
- MethodBox 登録
### Phase 114: FileIo 機能拡張
- exists / stat / canonicalize を FileIo trait に追加
- 権限・ロック機構の検討
```
---
## 7. 実装チェックリスト（Phase 111）
- [ ] FsApi trait に append_all() メソッド追加
- [ ] StdFsApi で append_all() 実装（OpenOptions.append()）
- [ ] Ring0FsFileIo.write() を mode チェックして append/truncate 切り替え
- [ ] FileHandleBox.open() に mode バリデーション（"r"/"w"/"a" のみ）
- [ ] FileHandleBox.metadata_internal() が FsApi.metadata() を呼び出し
- [ ] FileHandleBox.size / exists / is_file / is_dir を内部 Rust API として実装
- [ ] append テスト（write → append → 内容確認）
- [ ] metadata テスト（size, is_file, is_dir）
- [ ] read-only mode での write 拒否テスト
- [ ] NoFs profile 対応テスト（open がエラー）
- [ ] core_boxes_design / phase111 docs / CURRENT_TASK 更新済み
- [ ] ビルド・テスト完全成功
---
## 8. 設計原則（Phase 111 で確立）
### append vs truncate の明確な使い分け
```
【Mode】 【挙動】 【用途】
─────────────────────────────────────────────
"w" 毎回上書き（truncate） ログファイル初期化、設定ファイル更新
"a" 末尾に追記（append） 履歴ログ、イベント記録
"r" 読み取り専用 ファイル読み込み
```
### FsApi の成熟度
**Phase 107-108**:
- read_to_string, read, write_all, exists, metadata
**Phase 111**:
- append_all（write_all と対称的）
**Phase 112+**:
- modified フィールド（SystemTime）の FsMetadata 追加
- Ring0 service registry 統一化
### FileHandleBox のメタデータ戦略
**Phase 111**:
- metadata は内部 Rust API のみ（.hako 非公開）
- テスト・デバッグ用途
**Phase 112+**:
- MethodBox 登録で .hako 公開
- modified を FsMetadata に追加
---
**Phase 111 指示書完成日**: 2025-12-03（修正案統合版）
Status: Historical

427
docs/archive/phases/phase-106-156/phase112_ring0_registry_design.md Normal file
View File

@ -0,0 +1,427 @@
# Phase 112: Ring0 Service Registry 統一化
## 0. ゴール
- 現状バラバラに見える Ring0 サービス（MemApi/IoApi/TimeApi/LogApi/FsApi/ThreadApi）を、
**1つの service registry** として扱える構造にまとめる。
- 目的は：
- 初期化コードの散乱を止める（StdMem/StdFs/StdLog…の生成場所を1カ所に集約）
- プロファイル（Default/NoFs/TestMock…）ごとに Ring0 を差し替えやすくする
- 将来の mock / embedded / sandbox プロファイルの足場を先に用意しておく。
---
## 1. スコープと非スコープ
### スコープ（今回やること）
1. **設計ドキュメント**: 「Ring0 Service Registry」の形を定義。
2. **Ring0Registry struct**: `build(profile) -> Ring0Context` メソッド実装。
3. **NoFsApi struct**: NoFs profile 用の FsApi stub 実装。
4. **初期化パスの統一**:
- RuntimeProfile::from_env() で profile 読み込み（env 読み込み唯一の場所）
- Ring0Registry::build(profile) で Ring0Context 構築
- init_global_ring0() で GLOBAL_RING0 登録
5. **責務分離**:
- env 読み込み → initialize_runtime() のみ
- Profile に応じた実装選択 → Ring0Registry::build()
- 各 Std* の具体実装 → std_impls.rs に閉じ込める
6. **ドキュメント**: Phase 112 設計書 + core_boxes_design.md / ring0-inventory.md / CURRENT_TASK.md 更新。
### 非スコープ（今回はやらない）
- Nyash 側（.hako）から Ring0 を差し替える仕組み（Phase 113+）。
- FileHandleBox の NyashBox 公開 API（metadata を .hako から触るライン）。
- 並行アクセス・エンコーディング・ACL などの高機能。
---
## 2. Task 1: 設計ドキュメント作成（Ring0 Registry の全体像）
### 2.1 実装内容
**ファイル**（新規）:
- `docs/development/current/main/phase112_ring0_registry_design.md`（本ドキュメント）
### 2.2 現状の構造
**Ring0Context の構成**:
```rust
pub struct Ring0Context {
pub mem: Arc<dyn MemApi>,
pub io: Arc<dyn IoApi>,
pub time: Arc<dyn TimeApi>,
pub log: Arc<dyn LogApi>,
pub fs: Arc<dyn FsApi>, // Phase 90-A / Phase 107-111
pub thread: Arc<dyn ThreadApi>, // Phase 90-D
}
```
**現在の初期化パス**:
- `default_ring0()`: StdMem/StdIo/StdTime/StdLog/StdFs/StdThread で構築
- `init_global_ring0()`: GLOBAL_RING0 OnceLock に登録
- `get_global_ring0()`: GLOBAL_RING0 から取得
**問題点**:
- profile に応じた切り替え（NoFs など）が default_ring0() では硬い
- initialize_runtime() の中で Ring0 初期化を完全に管理していない
### 2.3 目指す構造
```
【initialize_runtime()】
↓ (profile/env 読み込み)
【Ring0Registry::build(profile)】
↓ (profile に応じた実装選択)
【Ring0Context { mem, io, time, log, fs, thread }】
↓ (init_global_ring0())
【GLOBAL_RING0】
↓
【PluginHost / FileBox / FileHandleBox / Logger / Runner …】
```
### 2.4 設計原則（Phase 112 で確立）
| 層 | 責務 | 例 |
|-----|------|-----|
| env | User configuration | NYASH_RUNTIME_PROFILE=no-fs |
| initialize_runtime() | env 読み込み + Ring0 初期化 | profile = RuntimeProfile::from_env() |
| Ring0Registry | 実装選択と構築 | build(profile) → Default か NoFs か |
| Std*/NoFs* | 具体実装 | StdFs / NoFsApi |
| Ring0Context | 統合されたコンテキスト | 全 API を一括提供 |
---
## 3. Task 2: Ring0Registry インターフェース定義
### 3.1 実装内容
**ファイル**:
- `src/runtime/ring0/mod.rs`（修正）
- `src/runtime/runtime_profile.rs`（既存、確認のみ）
### 3.2 Ring0Registry 構造体の追加
```rust
// src/runtime/ring0/mod.rs
use crate::runtime::runtime_profile::RuntimeProfile;
/// Phase 112: Ring0 service registry
///
/// profile ごとに適切な FsApi 実装（等）を選択して Ring0Context を構築する factory。
pub struct Ring0Registry;
impl Ring0Registry {
/// Ring0Context を profile に応じて構築
pub fn build(profile: RuntimeProfile) -> Ring0Context {
match profile {
RuntimeProfile::Default => Self::build_default(),
RuntimeProfile::NoFs => Self::build_no_fs(),
}
}
fn build_default() -> Ring0Context {
Ring0Context {
mem: Arc::new(StdMem::new()),
io: Arc::new(StdIo),
time: Arc::new(StdTime),
log: Arc::new(StdLog),
fs: Arc::new(StdFs),
thread: Arc::new(StdThread),
}
}
fn build_no_fs() -> Ring0Context {
Ring0Context {
mem: Arc::new(StdMem::new()),
io: Arc::new(StdIo),
time: Arc::new(StdTime),
log: Arc::new(StdLog),
fs: Arc::new(NoFsApi), // Phase 112: NoFs profile では FsApi を disabled に
thread: Arc::new(StdThread),
}
}
}
```
### 3.3 default_ring0() の位置付け
既存の `default_ring0()` は、**互換性のため** 以下のように修正：
```rust
/// Phase 88: デフォルト Ring0Context を作成
///
/// Phase 112 以降は、initialize_runtime() を通じて
/// Ring0Registry::build(profile) 経由で初期化されることが推奨。
///
/// この関数は直接呼び出しに対する互換性レイヤーとして保持。
pub fn default_ring0() -> Ring0Context {
Ring0Registry::build(RuntimeProfile::Default)
}
```
**重要**: 今後は initialize_runtime() → Ring0Registry::build() の流れが SSOT。
---
## 4. Task 3: NoFsApi 実装（Phase 109/111 の FsApi stub）
### 4.1 実装内容
**ファイル**:
- `src/runtime/ring0/std_impls.rs`（NoFsApi 追加）
- `src/runtime/ring0/mod.rs`（re-export 追加）
### 4.2 NoFsApi 構造体
```rust
// src/runtime/ring0/std_impls.rs
/// Phase 112: No-FS profile 用 FsApi stub
///
/// FileSystem 操作がすべて「無効」として機能する。
/// Phase 109 の NoFsFileIo（FileIo trait）と異なり、
/// Ring0 レベルの FsApi trait を実装する。
pub struct NoFsApi;
impl FsApi for NoFsApi {
fn read_to_string(&self, _path: &Path) -> Result<String, IoError> {
Err(IoError::Io(
"FileSystem operations disabled in no-fs profile".to_string()
))
}
fn read(&self, _path: &Path) -> Result<Vec<u8>, IoError> {
Err(IoError::Io(
"FileSystem operations disabled in no-fs profile".to_string()
))
}
fn write_all(&self, _path: &Path, _data: &[u8]) -> Result<(), IoError> {
Err(IoError::Io(
"FileSystem operations disabled in no-fs profile".to_string()
))
}
fn append_all(&self, _path: &Path, _data: &[u8]) -> Result<(), IoError> {
Err(IoError::Io(
"FileSystem operations disabled in no-fs profile".to_string()
))
}
fn exists(&self, _path: &Path) -> bool {
false
}
fn metadata(&self, _path: &Path) -> Result<FsMetadata, IoError> {
Err(IoError::Io(
"FileSystem operations disabled in no-fs profile".to_string()
))
}
fn canonicalize(&self, _path: &Path) -> Result<PathBuf, IoError> {
Err(IoError::Io(
"FileSystem operations disabled in no-fs profile".to_string()
))
}
}
```
### 4.3 re-export
```rust
// src/runtime/ring0/mod.rs
pub use std_impls::{NoopMem, StdFs, StdIo, StdLog, StdMem, StdThread, StdTime, NoFsApi};
```
---
## 5. Task 4: initialize_runtime() と Global Ring0 の統一
### 5.1 実装内容
**ファイル**:
- `src/runner/initialize_runtime.rs`（既存、確認・修正）
- `src/runtime/ring0/mod.rs`（确认のみ）
### 5.2 initialize_runtime() の責務
```rust
// src/runner/initialize_runtime.rs（または src/runtime/mod.rs）
use crate::runtime::runtime_profile::RuntimeProfile;
use crate::runtime::ring0::{Ring0Context, Ring0Registry, init_global_ring0, get_global_ring0};
/// Phase 112: Runtime 初期化（唯一の env 読み込み / Ring0 初期化ポイント）
///
/// **責務**:
/// 1. RuntimeProfile を env から読む（env 読み込みはここだけ）
/// 2. Ring0Registry::build(profile) で Ring0Context を構築
/// 3. init_global_ring0() で GLOBAL_RING0 に登録
pub fn initialize_runtime() -> Arc<Ring0Context> {
// 1. Profile を env から読む（唯一の場所）
let profile = RuntimeProfile::from_env();
// 2. Ring0Context を構築（profile に応じた実装選択）
let ctx = Ring0Registry::build(profile);
// 3. GLOBAL_RING0 に登録
init_global_ring0(ctx);
// 4. グローバル Ring0Context を取得して返す
get_global_ring0()
}
```
### 5.3 設計原則
**重要な約束**:
- **env 直読み禁止**: すべての環境変数読み込みは initialize_runtime() を通す
- **Ring0Context 入口の一本化**: default_ring0() ではなく initialize_runtime() を呼ぶ
- **Profile-aware**: Ring0Registry::build(profile) が、runtime 全体のふるまいを決定する
---
## 6. Task 5: Provider / PluginHost 側から見た Ring0 の統一
### 6.1 実装内容
**ファイル**:
- `src/runtime/plugin_host.rs`（確認、修正不要の可能性）
- `src/runtime/provider_lock.rs`（確認）
- ドキュメント更新（phase110/111）
### 6.2 Ring0.fs が NoFsApi の場合の動作（新規の一貫性 ✅）
**Phase 112 で確立される新しい約束**:
```
【設計】Ring0 レベルで NoFsApi を使うと、すべての上位層が自動的に disabled
Flow:
Ring0Registry::build(RuntimeProfile::NoFs)
↓
Ring0Context { fs: Arc::new(NoFsApi), ... }
↓
Ring0FsFileIo が内部で ring0.fs.read/write/append を呼ぶ
↓
→ すべて IoError で失敗する（自動的に disabled）
↓
FileBox.read() / FileHandleBox.open() も失敗
↓
→ ユーザー側は「FileBox/FileHandleBox が使えない」と認識
```
**つまり**: Ring0.fs が NoFsApi なら、PluginHost/FileBox/FileHandleBox は何もしなくても自動的に disabled になる！
### 6.3 PluginHost との関係
**既存の logic（Phase 109/111）はそのまま**:
- PluginHost.with_core_from_registry(ring0, registry, profile)
- FileBox provider 存在確認は profile に応じて切り替え（既実装）
- FileHandleBox.open()
- NoFs profile では provider_lock から provider が無いので、即座に「disabled」エラー
- Ring0FsFileIo
- 内部で ring0.fs を呼び出す構造はそのまま。NoFsApi なら自動的に disabled
**結論**: Phase 112 で Ring0Registry を導入しても、既存のロジックは変わらない！
---
## 7. Task 6: ドキュメント更新
### 7.1 実装内容
**ファイル**:
- `phase112_ring0_registry_design.md`（本ドキュメント）
- `core_boxes_design.md`（Ring0 セクション追加）
- `ring0-inventory.md`（Phase 112 エントリ追加）
- `CURRENT_TASK.md`（Phase 112 反映）
### 7.2 core_boxes_design.md への追記
Ring0 セクションに以下を追加：
```markdown
## Section 17: Phase 112 - Ring0 Service Registry 統一化
### 概要
Ring0Context の初期化を「Ring0Registry::build(profile)」に集約。
profile ごとに実装を切り替える factory パターンで、
プロファイル対応と将来の拡張を簡素化。
### 設計
- **default_ring0()**: Ring0Registry::build(RuntimeProfile::Default) に統一
- **NoFsApi**: NoFs profile で FsApi 無効化（Ring0 レベル）
- **initialize_runtime()**: env 読み込み → Ring0Registry.build() → init_global_ring0()
### プロファイル別の Ring0Context
| Profile | mem | io | time | log | fs | thread |
|---------|-----|----|----|-----|----|----|
| Default | ✅ StdMem | ✅ StdIo | ✅ StdTime | ✅ StdLog | ✅ StdFs | ✅ StdThread |
| NoFs | ✅ StdMem | ✅ StdIo | ✅ StdTime | ✅ StdLog | ❌ NoFsApi | ✅ StdThread |
### 実装完了日
**Phase 112 実装完了日**: 2025-12-03（予定）
```
---
## 8. 完成チェックリスト（Phase 112）
- [ ] Ring0Registry struct と build(profile) メソッド実装
- [ ] NoFsApi struct 実装（FsApi trait）
- [ ] default_ring0() を Ring0Registry::build(RuntimeProfile::Default) に統一
- [ ] initialize_runtime() が env 読み込み → Ring0Registry → init_global_ring0() の流れ
- [ ] PluginHost / FileBox / FileHandleBox からの Ring0 アクセス経路が変わらない（互換性維持）
- [ ] NoFsApi による自動的な disabled 動作確認（integration test）
- [ ] phase112_ring0_registry_design.md / core_boxes_design.md / CURRENT_TASK.md 更新済み
- [ ] ビルド・ファイル I/O 関連テスト全 PASS
---
## 9. 設計原則（Phase 112 で確立）
### 責務分離
```
【Layer】 【責務】 【誰が実装】
─────────────────────────────────────────────────────
env User configuration User
initialize_runtime env 読み込み + Ring0 初期化 runner
Ring0Registry Profile 応じた実装選択 ring0
Std* / NoFsApi 具体実装（std::fs など） ring0/std_impls
Ring0Context API 統合 Ring0
PluginHost/FileBox Ring0 の利用者 runtime/boxes
```
### Profile 拡張の足場
**将来の追加が簡単**:
```rust
// Phase 113+ で以下のように拡張可能
impl Ring0Registry {
pub fn build(profile: RuntimeProfile) -> Ring0Context {
match profile {
RuntimeProfile::Default => Self::build_default(),
RuntimeProfile::NoFs => Self::build_no_fs(),
RuntimeProfile::TestMock => Self::build_test_mock(), // ← 追加
RuntimeProfile::Sandbox => Self::build_sandbox(), // ← 追加
RuntimeProfile::ReadOnly => Self::build_readonly(), // ← 追加
RuntimeProfile::Embedded => Self::build_embedded(), // ← 追加
}
}
}
```
---
**Phase 112 指示書完成日**: 2025-12-03（修正案統合版）
Status: Historical

444
docs/archive/phases/phase-106-156/phase113_filehandlebox_public_api.md Normal file
View File

@ -0,0 +1,444 @@
# Phase 113: FileHandleBox Nyash 公開 API
## 0. ゴール
- Phase 110–111 で実装した FileHandleBox の能力（open/read/write/close + "a" + metadata）を、
Nyash (.hako) 側から「普通の Box メソッド」として使える形に公開する。
## 1. スコープと非スコープ
### スコープ（今回やること）
1. **設計ドキュメント**: 「公開メソッドセット」と挙動を定義
2. **Rust 側メソッド公開**: NyashBox trait / invoke_method() で MethodBox 登録
3. **MethodBox 登録**: BoxFactory に FileHandleBox メソッドテーブルを追加
4. **ディスパッチ方式**: StringBox と同じ動的ディスパッチパターン採用
5. **.hako サンプル**: 最小限の使用例を提示
6. **Profile 挙動確認**: Default / NoFs での動作明記
7. **ドキュメント更新**: core_boxes_design / ring0-inventory / CURRENT_TASK
### 非スコープ（今回はやらない）
- FileHandleBox を CoreBox に昇格（Phase 114+ 検討）
- Binary モード / 詳細テキストエンコーディング対応（Phase 114+）
- modified / created などの詳細メタデータ（Phase 114+）
- Exception / Result 型の統一（Phase 114+ 検討）
- プロファイル追加（TestMock/Sandbox/Embedded は Phase 114+）
## 2. 設計決定事項（Phase 113 確定）
| 項目 | 決定内容 | 理由 |
|------|---------|------|
| **Return Type** | すべて Void（エラーは panic）| 実装シンプルさ。Phase 114+ で Result 検討 |
| **Mode パラメータ** | "a", "r", "w" のみ | バイナリ対応は Phase 114+ |
| **Box クラス体系** | MethodBox のみ（CoreBox 化は Phase 114+）| Phase 113 は最小スコープ |
| **メソッドディスパッチ** | NyashBox trait メソッド直接実装 | 既存の NyashBox パターンに従う |
| **NoFs プロファイル** | open は panic、他は no-op | Ring0Registry による自動無効化 |
| **if 文条件** | Nyash 既実装のはず（確認）| 疑似コードで Bool 直接使用可能 |
| **テスト方式** | Rust ユニット + .hako 統合テスト両方 | カバレッジ完全化 |
## 3. Task 1: 公開 API の設計
### 3.1 メソッドセット（Nyash 側公開）
```
I/O メソッド:
- open(path: String, mode: String) -> Void
* mode: "r"=read, "w"=write(truncate), "a"=append
* パニック on エラー（Mode validation など）
- read() -> String
* 全内容をいっぺんに読む
* パニック on エラー or ファイル未open
- write(text: String) -> Void
* data を書く（mode="w" or "a" での動作に従う）
* パニック on not open / mode mismatch
- close() -> Void
* ハンドルを閉じる（Rust 側で file クローズ）
* 既に closed なら no-op
メタデータ メソッド:
- exists() -> Bool
* パス存在確認（path は open() 時に保持）
- size() -> Integer
* ファイルサイズをバイト単位で返す
* パニック on ファイルなし / metadata 取得失敗
- isFile() -> Bool
* 通常ファイルか確認
- isDir() -> Bool
* ディレクトリか確認
```
### 3.2 疑似コード例
```nyash
box FileExample {
main() {
local h = new FileHandleBox()
// ファイル追記
h.open("/tmp/log.txt", "a")
h.write("hello\n")
h.close()
// ファイル読み込みと統計
h.open("/tmp/log.txt", "r")
local content = h.read()
if h.exists() {
local n = h.size()
print("Size: " + n)
}
h.close()
}
}
```
### 3.3 プロファイル別動作
**Default プロファイル**:
- Ring0FsFileIo → FsApi（StdFs）経由でファイルシステムアクセス
- open/read/write/close/exists/size すべて正常動作
**NoFs プロファイル**:
- open() → panic!（"FileSystem operations disabled in no-fs profile"）
- read/write/close → open に達しないので呼ばれない（no-op）
- exists/size → false / panic（メタデータ取得不可）
* もしくは open せずに呼ばれた場合は panic
## 4. Task 2: Rust 側メソッド公開
### 4.1 実装内容
ファイル:
- `src/boxes/file/handle_box.rs`（既存）
- `src/boxes/mod.rs` or `src/nyash_box.rs`（trait 周辺）
- `src/boxes/factory.rs` or `BoxFactory`（登録）
やること:
1. **FileHandleBox に Nyash メソッド実装**:
```rust
impl FileHandleBox {
// Nyash-visible methods
pub fn ny_open(&mut self, path: &str, mode: &str) {
self.open(path, mode).unwrap_or_else(|e| panic!("{}", e));
}
pub fn ny_read(&self) -> StringBox {
match self.read_to_string() {
Ok(content) => StringBox::new(content),
Err(e) => panic!("{}", e),
}
}
pub fn ny_write(&self, text: &str) {
self.write_all(text).unwrap_or_else(|e| panic!("{}", e));
}
pub fn ny_close(&mut self) {
self.close().unwrap_or_else(|e| panic!("{}", e));
}
pub fn ny_exists(&self) -> BoolBox {
match self.exists() {
Ok(result) => BoolBox::new(result),
Err(e) => panic!("{}", e),
}
}
pub fn ny_size(&self) -> IntegerBox {
match self.size() {
Ok(size) => IntegerBox::new(size as i64),
Err(e) => panic!("{}", e),
}
}
pub fn ny_is_file(&self) -> BoolBox {
match self.is_file() {
Ok(result) => BoolBox::new(result),
Err(e) => panic!("{}", e),
}
}
pub fn ny_is_dir(&self) -> BoolBox {
match self.is_dir() {
Ok(result) => BoolBox::new(result),
Err(e) => panic!("{}", e),
}
}
}
```
2. **BoxFactory / MethodBox 登録**:
- FileHandleBox の box type 名を factory に登録
- メソッドテーブル: ("open", arity=2), ("read", 0), ("write", 1), ("close", 0),
("exists", 0), ("size", 0), ("isFile", 0), ("isDir", 0)
- 既存の StringBox/IntegerBox と同じパターンで登録
3. **実装パターン**:
- NyashBox trait の既存メソッドを活用
- メソッド呼び出しは as_any_mut() でダウンキャストして直接呼び出し
- エラーハンドリングは panic! で統一（Phase 113）
### 4.2 テスト（Rust 側）
```rust
#[test]
fn test_filehandlebox_ny_open_read_default_profile() {
let profile = RuntimeProfile::Default;
let ring0 = Ring0Registry::build(profile);
let mut handle = FileHandleBox::new(ring0);
// open でテストファイルを作成
let path = "/tmp/phase113_test_open_read.txt";
handle.ny_open(path, "w");
// write する
handle.ny_write("test content\n");
// close する
handle.ny_close();
// 再度 open して読む
handle.ny_open(path, "r");
// read する
let content = handle.ny_read();
assert_eq!(content.value, "test content\n");
handle.ny_close();
// cleanup
std::fs::remove_file(path).ok();
}
#[test]
#[should_panic(expected = "disabled")]
fn test_filehandlebox_nofs_profile_panic() {
let profile = RuntimeProfile::NoFs;
let ring0 = Ring0Registry::build(profile);
let mut handle = FileHandleBox::new(ring0);
// NoFs では open が panic
handle.ny_open("/tmp/test", "a");
}
#[test]
fn test_filehandlebox_metadata_methods() {
let path = "/tmp/phase113_metadata_test.txt";
std::fs::write(path, "hello").unwrap();
let ring0 = Ring0Registry::build(RuntimeProfile::Default);
let mut handle = FileHandleBox::new(ring0);
handle.ny_open(path, "r");
// Test metadata methods
assert!(handle.ny_exists().value);
assert_eq!(handle.ny_size().value, 5);
assert!(handle.ny_is_file().value);
assert!(!handle.ny_is_dir().value);
handle.ny_close();
std::fs::remove_file(path).ok();
}
```
## 5. Task 3: .hako サンプルと統合テスト
### 5.1 サンプル .hako ファイル
ファイル: `apps/examples/file_handle/append_and_stat.hako`
```nyash
local h = new FileHandleBox()
// 初回: append モードで書き込み
h.open("/tmp/example_log.txt", "a")
h.write("First line\n")
h.close()
// 再度: append モードで追記
h.open("/tmp/example_log.txt", "a")
h.write("Second line\n")
h.close()
// Read mode で全内容を読む
h.open("/tmp/example_log.txt", "r")
local content = h.read()
print(content)
// メタデータ確認
if h.exists() {
local size = h.size()
print("File size: " + size)
}
h.close()
```
### 5.2 統合テスト（.hako 実行）
ファイル: `src/runner/tests/filehandlebox_public_api_test.rs` (新規)
内容:
```rust
#[test]
fn test_filehandlebox_public_api_append_and_read() {
// .hako ファイルを実行し、出力を検証
let output = run_nyash_example("apps/examples/file_handle/append_and_stat.hako");
assert!(output.contains("First line"));
assert!(output.contains("Second line"));
assert!(output.contains("File size:"));
}
#[test]
fn test_filehandlebox_nofs_disabled() {
// NYASH_RUNTIME_PROFILE=no-fs で実行した場合、
// open がパニックして適切なエラーメッセージが出るか確認
let output = run_nyash_with_profile(
"apps/examples/file_handle/append_and_stat.hako",
"no-fs"
);
assert!(output.contains("disabled") || output.contains("error"));
}
```
## 6. Task 4: Profile / Ring0 統合確認
ファイル: phase111 / phase112 に追記
追記内容:
**phase111_filehandlebox_append_metadata.md**:
```markdown
### 補足: Phase 113 との関連
- Phase 113 で、これらの Rust メソッドが .hako 側に公開される。
- ny_read(), ny_size() など Nyash-visible メソッドとして提供。
```
**phase112_ring0_registry_design.md**:
```markdown
### FileHandleBox の Ring0 依存
- FileHandleBox は Ring0FsFileIo を内部で保持し、Ring0.fs に依存。
- Ring0Registry で NoFsApi が設定されると、自動的に FileHandleBox.open() は fail（panic）する。
- プロファイル切り替え時の挙動は Phase 113 で明記。
```
## 7. Task 5: ドキュメント更新
### 7.1 core_boxes_design.md への追記
追記位置: FileHandleBox セクション（既存）
```markdown
### Section N: Phase 113 - FileHandleBox Nyash 公開 API
#### 概要
FileHandleBox の内部メソッド（open/read/write/close/exists/size など）を
NyashBox trait の標準パターンで Nyash (.hako) 側に公開。
#### 公開メソッド
- open(path: String, mode: "r"|"w"|"a") -> Void (panic on error)
- read() -> String
- write(text: String) -> Void
- close() -> Void
- exists() -> Bool
- size() -> Integer
- isFile() -> Bool
- isDir() -> Bool
#### メソッドディスパッチ
NyashBox trait の標準パターン。ny_* メソッドとして実装。
#### Profile 別動作
| Profile | open | read/write | exists/size |
|---------|------|-----------|------------|
| Default | ✅ OK | ✅ OK | ✅ OK |
| NoFs | ❌ panic | - | ❌ panic |
```
### 7.2 ring0-inventory.md への追記
```markdown
## Phase 113: FileHandleBox Nyash 公開 API
- 設計: NyashBox trait 標準パターンで実装
- 実装: ny_* メソッド群追加（panic ベースエラーハンドリング）
- テスト: Rust ユニット + .hako 統合テスト両方
- Profile 対応: Default/NoFs 確認済み
```
### 7.3 CURRENT_TASK.md への追記
完了行として追加:
```
| Phase 113 | FileHandleBox Nyash API 公開 | ✅ 完了 | open/read/write/close/exists/size 公開、MethodBox 登録、Profile 対応確認 |
```
## 8. 完成チェックリスト（Phase 113）
- [ ] phase113_filehandlebox_public_api.md が完成（設計+実装詳細記載）
- [ ] FileHandleBox に ny_* メソッド実装済み
- [ ] BoxFactory に FileHandleBox メソッドテーブル登録完了
- [ ] .hako から new FileHandleBox() → open/read/write/close/exists/size 呼び出し可能
- [ ] Rust ユニットテスト: Default プロファイルで全メソッド動作確認
- [ ] Rust ユニットテスト: NoFs プロファイルで panic/no-op 動作確認
- [ ] .hako 統合テスト: append_and_stat.hako が実行・出力確認可能
- [ ] core_boxes_design.md / ring0-inventory.md / CURRENT_TASK.md 更新完了
## 9. 設計原則（Phase 113 で確立）
### NyashBox Standard Pattern
```
Nyash (.hako)
↓ Box method call
NyashBox trait methods (direct call)
↓
FileHandleBox::ny_*() methods
↓ delegate
Rust internal methods (open/read/write/close/exists/size)
```
### Profile カスケード
```
Phase 113 では何もしない
→ Ring0Registry が NoFsApi を設定
→ FileHandleBox.open() が Ring0FsFileIo 経由で FsApi.write_all() 呼び出し
→ NoFsApi が Err を返す
→ FileHandleBox.open() が panic
```
## 10. 実装メモ
### 10.1 メソッド命名規則
- Rust internal: `open()`, `read_to_string()`, `write_all()`, `close()`, etc.
- Nyash-visible: `ny_open()`, `ny_read()`, `ny_write()`, `ny_close()`, etc.
- この命名により、内部実装と公開 API を明確に区別
### 10.2 エラーハンドリング戦略
- Phase 113: panic ベース（unwrap_or_else）
- Phase 114+: Result<T, E> 型への移行を検討
- 理由: シンプルさ優先、段階的な実装
### 10.3 Profile 対応
- Default: 全機能有効
- NoFs: open() で即座に panic
- Phase 114+: TestMock/Sandbox プロファイル追加
---
**Phase 113 実装予定完了日**: 2025-12-04
**実装者**: Claude Code + ChatGPT 協働
**レビュー**: Phase 114 移行時に Result 型統合を検討
Status: Historical

247
docs/archive/phases/phase-106-156/phase114_fileio_trait_extension.md Normal file
View File

@ -0,0 +1,247 @@
# Phase 114: FileIo trait 拡張 & メタデータ統一
## 目標
FsApi 側に揃った情報（exists / metadata / canonicalize）を、FileIo trait 経由で一貫して扱えるようにする。
FileHandleBox 内部の is_file/is_dir/size などをすべて FileIo::stat() の上に乗せる。
.hako 側 API（Phase 113 で公開したメソッド群）は変更しない（内部実装だけきれい化）。
## FileIo trait 設計（FsApi との分離：stateless vs stateful）
### FsApi (Ring0) - Stateless OS抽象
```rust
pub trait FsApi {
fn exists(&self, path: &Path) -> bool;
fn metadata(&self, path: &Path) -> Result<FsMetadata>;
fn canonicalize(&self, path: &Path) -> Result<PathBuf>;
fn read_to_string(&self, path: &Path) -> Result<String>;
fn write_all(&self, path: &Path, data: &[u8]) -> Result<()>;
fn append_all(&self, path: &Path, data: &[u8]) -> Result<()>;
}
```
- **Role**: OS ファイルシステムの直接抽象化
- **State**: なし（パス引数で毎回指定）
- **Usage**: Ring0Context 経由でアクセス
### FileIo (Ring1) - Stateful ハンドル抽象
```rust
pub struct FileStat {
pub is_file: bool,
pub is_dir: bool,
pub size: u64,
}
pub trait FileIo: Send + Sync {
fn caps(&self) -> FileCaps;
fn open(&self, path: &str) -> FileResult<()>;
fn read(&self) -> FileResult<String>;
fn write(&self, text: &str) -> FileResult<()>;
fn close(&self) -> FileResult<()>;
fn as_any(&self) -> &dyn std::any::Any;
// Phase 114: Metadata operations
fn exists(&self) -> bool;
fn stat(&self) -> FileResult<FileStat>;
fn canonicalize(&self) -> FileResult<String>;
}
```
- **Role**: 現在開いているファイルハンドルに対する操作
- **State**: あり（open() で path を内部保持）
- **Usage**: FileHandleBox 経由でアクセス
### 設計原則
1. **FsApi = Stateless**: パスを毎回引数で受け取る
2. **FileIo = Stateful**: open() で path を保持、以降は引数不要
3. **分離理由**:
- FsApi: OS レイヤーの直接操作（低レベル）
- FileIo: ハンドルベースの高レベル API（.hako からアクセス）
## Ring0FsFileIo/NoFsFileIo の実装詳細
### Ring0FsFileIo (Default プロファイル)
```rust
pub struct Ring0FsFileIo {
ring0: Arc<Ring0Context>,
path: RwLock<Option<String>>, // open() で設定
mode: RwLock<Option<String>>, // "r", "w", "a"
}
impl FileIo for Ring0FsFileIo {
fn exists(&self) -> bool {
// path が設定されていれば ring0.fs.exists() を呼ぶ
// path が None なら false
}
fn stat(&self) -> FileResult<FileStat> {
// path が設定されていれば ring0.fs.metadata() を呼ぶ
// FileStat に変換して返す
}
fn canonicalize(&self) -> FileResult<String> {
// path が設定されていれば ring0.fs.canonicalize() を呼ぶ
// PathBuf を String に変換して返す
}
}
```
### NoFsFileIo (NoFs プロファイル)
```rust
pub struct NoFsFileIo;
impl FileIo for NoFsFileIo {
fn exists(&self) -> bool {
// NoFs プロファイルでは常に false
false
}
fn stat(&self) -> FileResult<FileStat> {
// Unsupported エラーを返す
Err(FileError::Unsupported("..."))
}
fn canonicalize(&self) -> FileResult<String> {
// Unsupported エラーを返す
Err(FileError::Unsupported("..."))
}
}
```
## FileHandleBox の metadata_internal() 統一設計
### Before Phase 114
```rust
// Ring0FsFileIo.metadata() を直接ダウンキャスト
fn metadata_internal(&self) -> Result<FsMetadata, String> {
self.io.as_ref()
.ok_or_else(|| "FileHandleBox not open".to_string())?
.as_any()
.downcast_ref::<Ring0FsFileIo>()
.ok_or_else(|| "FileIo is not Ring0FsFileIo".to_string())?
.metadata() // Ring0FsFileIo 専用メソッド
}
```
**問題点**:
- Ring0FsFileIo 依存（downcast 必要）
- FileIo trait を経由していない
- NoFsFileIo では動作しない
### After Phase 114
```rust
// FileIo::stat() を使用（trait 経由）
fn metadata_internal(&self) -> Result<FileStat, String> {
let io = self.io.as_ref()
.ok_or_else(|| "FileHandleBox is not open".to_string())?;
io.stat() // FileIo trait 経由
.map_err(|e| format!("Metadata failed: {}", e))
}
// 他のメソッドも metadata_internal() の上に統一
fn size(&self) -> Result<u64, String> {
self.metadata_internal().map(|meta| meta.size)
}
fn is_file(&self) -> Result<bool, String> {
self.metadata_internal().map(|meta| meta.is_file)
}
fn is_dir(&self) -> Result<bool, String> {
self.metadata_internal().map(|meta| meta.is_dir)
}
```
**改善点**:
- FileIo trait 経由で統一
- downcast 不要
- NoFsFileIo でも正しくエラーを返す
## Profile 別動作
### Default プロファイル（Ring0FsFileIo）
| メソッド | 動作 |
|---------|------|
| `exists()` | ファイルが存在すれば `true`、存在しないか path 未設定なら `false` |
| `stat()` | `FileStat { is_file, is_dir, size }` を返す。path 未設定なら `Err` |
| `canonicalize()` | 絶対パスを返す。path 未設定なら `Err` |
### NoFs プロファイル（NoFsFileIo）
| メソッド | 動作 |
|---------|------|
| `exists()` | 常に `false` |
| `stat()` | `Err(FileError::Unsupported("..."))` |
| `canonicalize()` | `Err(FileError::Unsupported("..."))` |
## テスト結果
### Ring0FsFileIo テスト（Default プロファイル）
```
✅ test_ring0_fs_fileio_stat_default_profile
✅ test_ring0_fs_fileio_exists_default_profile
✅ test_ring0_fs_fileio_canonicalize_default_profile
✅ test_ring0_fs_fileio_stat_without_open
✅ test_ring0_fs_fileio_canonicalize_without_open
```
### NoFsFileIo テスト
```
✅ test_nofs_fileio_exists (常に false)
✅ test_nofs_fileio_stat_error (Unsupported エラー)
✅ test_nofs_fileio_canonicalize_error (Unsupported エラー)
```
### FileHandleBox テスト
```
✅ test_filehandlebox_metadata_internal_default (stat() 経由で FileStat 取得)
✅ test_filehandlebox_metadata_internal_not_open (エラー確認)
✅ test_filehandlebox_ny_size_uses_stat (ny_size() が stat() 経由)
✅ test_filehandlebox_exists_uses_fileio (exists() が FileIo::exists() 経由)
✅ test_filehandlebox_is_file_is_dir_via_stat (is_file/is_dir が stat() 経由)
```
## 実装成果
### 統計
- **修正ファイル**: 4ファイル
- `src/boxes/file/provider.rs`
- `src/providers/ring1/file/ring0_fs_fileio.rs`
- `src/providers/ring1/file/nofs_fileio.rs`
- `src/boxes/file/handle_box.rs`
- `src/providers/ring1/file/core_ro.rs`
- **追加行**: 約 +150 行
- **削除行**: 約 -20 行
- **新規テスト**: 11個
### 技術的成果
1. **FileIo trait 拡張**: exists/stat/canonicalize 正式追加
2. **統一設計**: FileHandleBox 内部が metadata_internal() に統一
3. **Profile 対応**: Default/NoFs 両プロファイルで正しく動作
4. **後方互換性**: .hako 側 API は変更なし（内部実装のみ統一）
## 次のステップ
- **Phase 115**: PathBox 実装（パス操作専用Box）
- **Phase 116**: ディレクトリ操作（mkdir/rmdir/readdir）
## 関連ドキュメント
- [core_boxes_design.md](./core_boxes_design.md) - FileHandleBox 設計
- [ring0-inventory.md](./ring0-inventory.md) - Ring0 機能一覧
- [Phase 113 実装](./phase113_filehandlebox_api.md) - Nyash API 公開
Status: Historical

173
docs/archive/phases/phase-106-156/phase120_baseline_results.md Normal file
View File

@ -0,0 +1,173 @@
# Phase 120: selfhost Stage-3 ベースライン結果
## 実行日時
2025-12-04（Phase 106-115 完了直後）
## 環境
- **Rust VM**: ./target/release/hakorune
- **LLVM**: llvmlite ハーネス（今回は未実行）
- **JoinIR Strict**: NYASH_JOINIR_STRICT=1
- **selfhost**: NYASH_USE_NY_COMPILER=1 NYASH_PARSER_STAGE3=1 HAKO_PARSER_STAGE3=1
## 代表パス実行結果
### 1. peek_expr_block.hako
**ファイル**: `apps/tests/peek_expr_block.hako`
| 項目 | 結果 |
|------|------|
| **実行結果** | ✅ 成功 |
| **エラーメッセージ** | なし |
| **警告メッセージ** | `[deprecate/env]` NYASH_PARSER_STAGE3 deprecated<br>`⚠️ [DEPRECATED]` builtin ArrayBox deprecated<br>`[selfhost-child] timeout` 2000ms |
| **標準出力** | `found one`<br>`RC: 1` |
| **備考** | match 式が正常に JoinIR If Lowering で処理。ブロック式の評価も正常動作。期待通りの出力を確認。 |
**技術的詳細**:
- match 式が If Lowering で複数の条件分岐に変換された
- ブロック式（`{ print("...") 値 }`）が正しく評価され、最後の値が返却された
- PHI 命令による各分岐からの値の合流が正常動作
### 2. loop_min_while.hako
**ファイル**: `apps/tests/loop_min_while.hako`
| 項目 | 結果 |
|------|------|
| **実行結果** | ✅ 成功 |
| **エラーメッセージ** | なし |
| **警告メッセージ** | `[deprecate/env]` NYASH_PARSER_STAGE3 deprecated<br>`[selfhost-child] timeout` 2000ms |
| **標準出力** | `0`<br>`1`<br>`2`<br>`RC: 0` |
| **デバッグ出力** | `[ControlForm::Loop]` entry=3 preheader=3 header=4 body=5 latch=6 exit=7 |
| **備考** | loop 構文が正常に JoinIR Loop Lowering で処理。ControlForm 構造が正しく構築。 |
**技術的詳細**:
- ループが JoinIR Loop Lowering で処理され、ControlForm::Loop 構造を構築
- entry/preheader/header/body/latch/exit の各ブロックが正しく生成
- ループ変数 `i` の PHI 命令が正常生成（初期値 0 と更新値の合流）
- ループ終了条件 `i < 3` が正しく評価され、exit ブロックへ遷移
### 3. esc_dirname_smoke.hako
**ファイル**: `apps/tests/esc_dirname_smoke.hako`
| 項目 | 結果 |
|------|------|
| **実行結果** | ❌ エラー |
| **エラーメッセージ** | `[ERROR] ❌ [rust-vm] VM error: Invalid instruction: Unknown method 'println' on ConsoleBox` |
| **警告メッセージ** | `[deprecate/env]` NYASH_PARSER_STAGE3 deprecated<br>`[warn] dev verify:` NewBox ConsoleBox not followed by birth()<br>`[warn] dev verify:` NewBox Main not followed by birth()<br>`⚠️ [DEPRECATED]` builtin ConsoleBox deprecated<br>`[selfhost-child] timeout` 2000ms |
| **標準出力** | なし（エラーで中断） |
| **デバッグ出力** | `[ControlForm::Loop]` entry=8 preheader=8 header=9 body=10 latch=11 exit=12 |
| **備考** | esc_json メソッドのループと dirname メソッドの if 文は正常動作。ConsoleBox.println でエラー。 |
**技術的詳細**:
- esc_json メソッド内のループが JoinIR Loop Lowering で正常処理
- dirname メソッド内の if 文も JoinIR If Lowering で正常処理
- StringBox メソッド（length, substring, lastIndexOf）の呼び出しは正常
- **エラー原因**: ConsoleBox の println メソッドが見つからない
- ConsoleBox の実装に println メソッドがない可能性
- selfhost コンパイラのメソッド解決に問題がある可能性
- **NewBox→birth 警告**: ConsoleBox と Main の生成時に birth() 呼び出しが検出されない
- birth() が省略可能な設計なので、これは警告レベルの問題
## Phase 120 サマリー
### 実行結果統計
- **✅ 完全成功**: 2本（peek_expr_block.hako, loop_min_while.hako）
- **⚠️ 警告あり**: 2本（警告があっても実行成功）
- **❌ エラー**: 1本（esc_dirname_smoke.hako）
### JoinIR Strict モードでの検証
| 検証項目 | 結果 | 備考 |
|---------|------|------|
| If 文の JoinIR Lowering | ✅ 正常動作 | peek_expr_block.hako, esc_dirname_smoke.hako |
| Loop の JoinIR Lowering | ✅ 正常動作 | loop_min_while.hako, esc_dirname_smoke.hako |
| ControlForm 構造生成 | ✅ 正常動作 | header/body/latch/exit ブロックが正しく構築 |
| match 式の処理 | ✅ 正常動作 | If Lowering で複数条件分岐に変換 |
| ブロック式の評価 | ✅ 正常動作 | 最後の式が値として返却 |
| PHI 命令生成 | ✅ 正常動作 | 分岐・ループでの値合流 |
| StringBox メソッド | ✅ 正常動作 | length, substring, lastIndexOf |
| ConsoleBox.println | ❌ エラー | メソッド解決失敗 |
### 重要な発見
1. **JoinIR Lowering は安定動作**
- If/Loop の基本的な JoinIR Lowering は完全に動作している
- ControlForm 構造が正しく構築され、PHI 命令も正常生成
2. **selfhost コンパイラの動作**
- 2000ms タイムアウト警告が出るが、これはコンパイル時間の警告（正常動作）
- NYASH_PARSER_STAGE3 の deprecation 警告は環境変数名の変更推奨
3. **ConsoleBox.println 問題**
- ConsoleBox の println メソッドが selfhost 経路で解決できない
- builtin ConsoleBox の plugin 化が推奨されている
- これは selfhost 経路特有の問題と思われる（通常の VM 実行では動作するはず）
## Phase 122+ への課題
### 優先度高（エラー）
- [ ] **ConsoleBox.println メソッドエラーの解決**
- 原因: selfhost 経路でのメソッド解決失敗
- 影響: ConsoleBox を使用するプログラムが実行できない
- 対応: ConsoleBox の実装確認、または selfhost コンパイラのメソッド解決修正
- [ ] **NewBox→birth 警告の調査**
- 原因: birth() 呼び出しの検出ロジック
- 影響: 警告レベル（実行は可能）
- 対応: birth() 呼び出し検出の改善、または警告条件の緩和
### 優先度中（警告）
- [ ] **NYASH_PARSER_STAGE3 deprecation 警告への対応**
- 原因: 環境変数名の変更推奨
- 影響: 警告メッセージが出力される
- 対応: `NYASH_FEATURES=stage3` への移行
- [ ] **selfhost-child 2000ms タイムアウト警告の改善**
- 原因: selfhost コンパイル時間が長い
- 影響: 警告メッセージが出力される（実行は成功）
- 対応: タイムアウト時間の調整、またはコンパイル速度の改善
### 優先度低（最適化）
- [ ] **builtin ArrayBox/ConsoleBox の plugin 化推奨への対応**
- 原因: Phase 15.5 の Everything is Plugin 方針
- 影響: deprecation 警告が出力される
- 対応: plugin 化の検討（長期的な対応）
## 結論
Phase 120 時点での selfhost Stage-3 経路は：
### ✅ **基本動作は良好**
- 2/3 のプログラムが完全に動作
- JoinIR If/Loop Lowering が安定動作
- ControlForm 構造とPHI 命令の生成が正常
### ⚠️ **警告はあるが実行可能**
- deprecation 警告は情報提供レベル
- selfhost コンパイル時間の警告は既知の挙動
### ❌ **1つの致命的エラー**
- ConsoleBox.println メソッド解決エラー
- これは Phase 122+ で優先的に修正が必要
### 📊 **Phase 106-115 の成果**
- JoinIR Strict モードでの基本動作が確立
- If/Loop の Lowering が安定して動作
- selfhost 経路の基礎が固まった
Phase 122+ で上記課題を段階的に解決し、selfhost Stage-3 経路の完全な安定化を目指す。
---
**作成日**: 2025-12-04
**Phase**: 120（selfhost Stage-3 代表パスの安定化）
**ベースライン確立**: Phase 106-115 完了時点
Status: Historical

353
docs/archive/phases/phase-106-156/phase120_selfhost_stable_paths.md Normal file
View File

@ -0,0 +1,353 @@
# Phase 120: selfhost Stage-3 代表パスの安定化
## 0. ゴール
- **JoinIR Strict ON 環境**で selfhost 経路（Stage-3 .hako コンパイラ）が安定動作することを確認
- 代表的な .hako プログラム（2-3本）を選定し、**NYASH_JOINIR_STRICT=1** での実行を記録
- フォールバック・警告・エラーを洗い出し、**Phase 106-115 完了時点のベースライン**を確立
---
## 1. スコープと非スコープ
### スコープ（今回やること）
1. **代表パス選定**: selfhost で使う .hako ファイルから代表的なものを2-3本選定
2. **docs 整理**: 代表パスの期待フロー・JoinIR Strict モードの意味を1ドキュメントにまとめる
3. **実行調査**: `NYASH_JOINIR_STRICT=1` で各代表パスを実行し、フォールバック・警告・エラーを記録
4. **スモークスクリプト作成**: 代表パスの実行を再現できる smoke スクリプト化（`tools/smokes/v2/` 形式）
5. **ベースライン確立**: Phase 106-115 完了時点での動作状況を記録（Phase 120 実装前の基準点）
### 非スコープ（今回はやらない）
- **実装修正**: JoinIR 経路の実装バグ修正（Phase 122+ に回す）
- **hako_check 統合**: Phase 121 で設計を行う（今回は selfhost パスのみ）
- **全プログラム網羅**: 代表的なもの2-3本のみ（全 .hako の検証は別 Phase）
---
## 2. Task 1: 代表パス選定と期待フロー整理
### 2.1 代表パスの選定基準
**Phase 120 で扱う「代表パス」の条件**:
| 基準 | 説明 |
|------|------|
| **selfhost 経路で実行** | `NYASH_USE_NY_COMPILER=1` 等の selfhost 環境変数で動作するもの |
| **Stage-3 対象** | .hako コンパイラ自体、または selfhost で動作する実用プログラム |
| **複雑さのバランス** | 単純すぎず（hello world）、複雑すぎず（全 selfhost コンパイラ）のもの |
| **既存テスト可能** | apps/ または local_tests/ に既に存在し、動作確認済みのもの |
**推奨候補**（2-3本選定）:
1. **簡易パーサーテスト**: `apps/tests/peek_expr_block.hako` 等（簡単な制御構造）
2. **ループ・PHI 含む**: `apps/tests/loop_min_while.hako` 等（JoinIR If/Loop Lowering 対象）
3. **実用スクリプト**: `apps/examples/` から1本（FileBox/StringBox 使用等）
### 2.2 期待フローのドキュメント化
**ファイル**: `docs/development/current/main/selfhost_stage3_expected_flow.md`（新規）
**記載内容**:
```markdown
# selfhost Stage-3 期待フロー（Phase 120 時点）
## 概要
Phase 106-115 完了時点での selfhost 経路（Stage-3 .hako コンパイラ）の動作フローを記録。
## 実行環境
- **VM バックエンド**: `./target/release/nyash program.hako`（デフォルト）
- **LLVM バックエンド**: `./target/release/nyash --backend llvm program.hako`
- **selfhost 有効**: `NYASH_USE_NY_COMPILER=1` 等の環境変数
## JoinIR Strict モードとは
**環境変数**: `NYASH_JOINIR_STRICT=1`
**目的**: JoinIR 経路で旧 MIR/PHI 経路へのフォールバックを禁止し、厳格に JoinIR Lowering のみを使用
**期待される動作**:
- ✅ If/Loop Lowering が完全に JoinIR 経由で動作
- ❌ 旧 PHI 生成器へのフォールバックは禁止（エラーで停止）
- ⚠️ 警告: フォールバック候補があれば警告出力
## 代表パスの期待フロー
### 1. peek_expr_block.hako（簡易パーサーテスト）
**期待**:
- ✅ If 文が JoinIR If Lowering で処理
- ✅ ブロック式が正常に評価
- ✅ NYASH_JOINIR_STRICT=1 でもエラーなし
### 2. loop_min_while.hako（ループ・PHI 含む）
**期待**:
- ✅ Loop が JoinIR Loop Lowering で処理
- ✅ PHI 命令が正しく生成（ループ変数の合流）
- ⚠️ 警告: 旧 PHI 経路へのフォールバック候補があるかもしれない（Phase 120 調査対象）
### 3. [実用スクリプト名]（実用例）
**期待**:
- ✅ FileBox/StringBox 等の Box 操作が正常動作
- ✅ 複雑な制御構造が JoinIR 経由で処理
- ⚠️ 警告: 複雑さによってはフォールバックや警告が出る可能性
## Phase 120 の目標
上記の「期待」と「実際の動作」を比較し、ギャップを記録する。
実装修正は Phase 122+ で行う（Phase 120 はベースライン確立のみ）。
```
---
## 3. Task 2: 実行調査とログ記録
### 3.1 実行コマンド
各代表パスについて、以下のコマンドで実行し、出力を記録する:
```bash
# VM バックエンド（デフォルト）
NYASH_JOINIR_STRICT=1 NYASH_USE_NY_COMPILER=1 \
./target/release/nyash [代表パス.hako] 2>&1 | tee /tmp/phase120_vm_[name].log
# LLVM バックエンド（オプション）
NYASH_JOINIR_STRICT=1 NYASH_USE_NY_COMPILER=1 \
./target/release/nyash --backend llvm [代表パス.hako] 2>&1 | tee /tmp/phase120_llvm_[name].log
```
### 3.2 記録内容
**ログファイル**: `/tmp/phase120_execution_results.txt`（新規）
**記録形式**:
```
=== Phase 120: selfhost Stage-3 代表パス実行記録 ===
実行日時: 2025-12-04
Phase 106-115 完了時点のベースライン
--- 代表パス 1: peek_expr_block.hako ---
コマンド: NYASH_JOINIR_STRICT=1 NYASH_USE_NY_COMPILER=1 ./target/release/nyash apps/tests/peek_expr_block.hako
結果: ✅ 成功 / ❌ エラー / ⚠️ 警告あり
エラー・警告メッセージ:
[ログ出力をここに貼り付け]
備考:
- [気づいた点や特記事項]
--- 代表パス 2: loop_min_while.hako ---
...
```
### 3.3 分類基準
**ログ分類**:
| 分類 | 判定基準 | 対応 |
|------|---------|------|
| ✅ **完全成功** | エラーなし、警告なし、期待通りの出力 | ベースライン記録 |
| ⚠️ **警告あり** | 実行成功、警告メッセージあり | Phase 122+ で調査 |
| ❌ **エラー** | 実行失敗、エラーで停止 | Phase 122+ で修正 |
---
## 4. Task 3: スモークスクリプト作成
### 4.1 実装内容
**ファイル**: `tools/smokes/v2/profiles/integration/selfhost/phase120_stable_paths.sh`（新規）
**スクリプト構造**:
```bash
#!/bin/bash
# Phase 120: selfhost Stage-3 代表パス smoke テスト
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
source "$SCRIPT_DIR/../../../common.sh"
# Phase 120 環境変数
export NYASH_JOINIR_STRICT=1
export NYASH_USE_NY_COMPILER=1
# 代表パス 1: peek_expr_block.hako
run_test "selfhost_peek_expr" "apps/tests/peek_expr_block.hako" "vm"
# 代表パス 2: loop_min_while.hako
run_test "selfhost_loop_min" "apps/tests/loop_min_while.hako" "vm"
# 代表パス 3: [実用スクリプト]
run_test "selfhost_example" "apps/examples/[name].hako" "vm"
# LLVM バックエンド版（オプション）
# run_test "selfhost_peek_expr_llvm" "apps/tests/peek_expr_block.hako" "llvm"
echo "[Phase 120] selfhost stable paths smoke test completed"
```
### 4.2 統合
**スモークテストランナーに追加**:
`tools/smokes/v2/profiles/integration/integration_profile.txt` に以下を追加:
```
selfhost/phase120_stable_paths.sh
```
### 4.3 実行確認
```bash
# 単発実行
bash tools/smokes/v2/profiles/integration/selfhost/phase120_stable_paths.sh
# integration プロファイル全体実行
tools/smokes/v2/run.sh --profile integration --filter "selfhost_*"
```
---
## 5. Task 4: ベースライン確立とドキュメント更新
### 5.1 実装内容
**ファイル**: `docs/development/current/main/phase120_baseline_results.md`（新規）
**記載内容**:
```markdown
# Phase 120: selfhost Stage-3 ベースライン結果
## 実行日時
2025-12-04（Phase 106-115 完了直後）
## 環境
- **Rust VM**: ./target/release/nyash
- **LLVM**: llvmlite ハーネス（オプション）
- **JoinIR Strict**: NYASH_JOINIR_STRICT=1
- **selfhost**: NYASH_USE_NY_COMPILER=1
## 代表パス実行結果
### 1. peek_expr_block.hako
| 項目 | 結果 |
|------|------|
| **実行結果** | ✅ 成功 / ⚠️ 警告 / ❌ エラー |
| **エラーメッセージ** | [ログから抽出] |
| **警告メッセージ** | [ログから抽出] |
| **備考** | [特記事項] |
### 2. loop_min_while.hako
[同様の表]
### 3. [実用スクリプト名]
[同様の表]
## Phase 122+ への課題
**優先度高**:
- [ ] [エラー1の説明]
- [ ] [エラー2の説明]
**優先度中**:
- [ ] [警告1の説明]
- [ ] [警告2の説明]
**優先度低（最適化）**:
- [ ] [改善案1]
- [ ] [改善案2]
## 結論
Phase 120 時点での selfhost Stage-3 経路は：
- ✅ **基本動作**: [成功した代表パスの数]本
- ⚠️ **警告あり**: [警告があった数]本
- ❌ **エラー**: [エラーが出た数]本
Phase 122+ で上記課題を段階的に解決する。
```
### 5.2 CURRENT_TASK.md 更新
**ファイル**: `CURRENT_TASK.md`（修正）
**Phase 120 セクション追加**:
```markdown
### 🎯 Phase 120: selfhost Stage-3 代表パスの安定化（完了）
- ✅ 代表パス選定: [選定した .hako ファイル名]
- ✅ 期待フロー整理: selfhost_stage3_expected_flow.md 作成
- ✅ 実行調査完了: NYASH_JOINIR_STRICT=1 での動作確認
- ✅ ベースライン確立: phase120_baseline_results.md 作成
- ✅ スモークスクリプト: phase120_stable_paths.sh 作成
**次のステップ**: Phase 121（hako_check JoinIR 統合設計）
```
---
## 6. 完成チェックリスト（Phase 120）
- [ ] 代表パス 2-3本の選定完了（peek_expr_block.hako 等）
- [ ] selfhost_stage3_expected_flow.md 作成（期待フロー整理）
- [ ] NYASH_JOINIR_STRICT=1 での実行ログ記録（/tmp/phase120_execution_results.txt）
- [ ] phase120_baseline_results.md 作成（ベースライン確立）
- [ ] スモークスクリプト作成（phase120_stable_paths.sh）
- [ ] integration プロファイルへの統合確認
- [ ] CURRENT_TASK.md 更新（Phase 120 完了記録）
- [ ] ビルド・テスト全 PASS（cargo build --release && bash phase120_stable_paths.sh）
---
## 7. 設計原則（Phase 120 で確立）
### ベースライン First
```
【Phase 120 の哲学】
実装修正の前に、「現状を正確に記録する」
Flow:
Phase 106-115 完了
↓
Phase 120: 現状記録（ベースライン確立）
↓
Phase 121: 設計（hako_check 統合計画）
↓
Phase 122+: 実装修正（段階的改善）
```
### 代表パスの活用
**少数精鋭の代表パスで効率的に検証**:
- **2-3本**で selfhost 経路の主要パターンをカバー
- **簡単・中間・複雑**の3段階でバランス
- **既存テスト**を活用（新規作成は最小限）
### JoinIR Strict モードの意義
**Phase 120 での使い方**:
- **厳格モード**: フォールバックを禁止し、JoinIR 経路の完全性を確認
- **警告収集**: 現状の JoinIR 経路の課題を可視化
- **Phase 122+ の修正指針**: 警告・エラーが修正の優先順位を決める
---
**Phase 120 指示書完成日**: 2025-12-04（Phase 106-115 完了直後）
Status: Historical

286
docs/archive/phases/phase-106-156/phase121_hako_check_investigation.md Normal file
View File

@ -0,0 +1,286 @@
# Phase 121: hako_check 現状調査結果
## 実行日時
2025-12-04（Phase 120 完了直後）
## 調査項目 1: エントリーポイント
### 1.1 シェルスクリプトエントリー
**ファイル**: `tools/hako_check.sh`
**実装内容**:
```bash
#!/usr/bin/env bash
set -euo pipefail
ROOT="$(cd "$(dirname "$0")/.." && pwd)"
BIN="${NYASH_BIN:-$ROOT/target/release/hakorune}"
# ... 環境変数設定 ...
"$BIN" --backend vm "$ROOT/tools/hako_check/cli.hako" -- --source-file "$f" "$text"
```
**重要な発見**: hako_check は **Rust バイナリではなく .hako スクリプト**として実装されている。
**環境変数**:
- `NYASH_DISABLE_PLUGINS=1`: プラグイン無効化（安定性優先）
- `NYASH_BOX_FACTORY_POLICY=builtin_first`: ビルトイン Box 優先
- `NYASH_DISABLE_NY_COMPILER=1`: Ny コンパイラ無効化
- `HAKO_DISABLE_NY_COMPILER=1`: Hako コンパイラ無効化
- `NYASH_FEATURES=stage3`: Stage-3 パーサー使用
- `NYASH_PARSER_SEAM_TOLERANT=1`: パーサー seam 許容
- `HAKO_PARSER_SEAM_TOLERANT=1`: Hako パーサー seam 許容
- `NYASH_PARSER_ALLOW_SEMICOLON=1`: セミコロン許容
- `NYASH_ENABLE_USING=1`: using 文有効化
- `HAKO_ENABLE_USING=1`: Hako using 文有効化
- `NYASH_USING_AST=1`: AST ベース using 解決
- `NYASH_NY_COMPILER_TIMEOUT_MS`: コンパイラタイムアウト（デフォルト 8000ms）
**コマンドライン引数**:
- `--backend vm`: VM バックエンド強制
- `--source-file <path> <text>`: ファイルパスと内容をインライン渡し
- `--format <text|dot|json-lsp>`: 出力フォーマット指定
### 1.2 .hako エントリーポイント
**ファイル**: `tools/hako_check/cli.hako`
**実装内容**:
```hako
static box HakoAnalyzerBox {
run(args) {
// ... 引数解析 ...
// IR 生成
ir = HakoAnalysisBuilderBox.build_from_source_flags(text, p, no_ast_eff)
// 診断ルール実行（HC001-HC031）
// ...
}
}
static box Main { method main(args) { return HakoAnalyzerBox.run(args) } }
```
**重要なポイント**:
- エントリーポイントは `Main.main()` メソッド
- `HakoAnalyzerBox.run()` で診断ロジックを実行
- IR 生成は `HakoAnalysisBuilderBox.build_from_source_flags()` を使用
## 調査項目 2: MIR 生成経路
### 2.1 IR 生成フロー
**ファイル**: `tools/hako_check/analysis_consumer.hako`
**使用している MirBuilder**: 間接的に使用（VM 内部）
**フロー**:
```
HakoAnalysisBuilderBox.build_from_source_flags()
↓
HakoParserCoreBox.parse(text) // .hako パーサーで AST 生成
↓
[Rust VM 内部]
↓
nyash_rust::parser::NyashParser::parse_from_string_with_fuel()
↓
MirCompiler::compile_with_source()
↓
MirBuilder::build_module(ast)
↓
[If/Loop 文の処理]
↓
MirBuilder::cf_if() / MirBuilder::cf_loop()
```
**呼び出し箇所**:
- `tools/hako_check/analysis_consumer.hako:32`: `HakoParserCoreBox.parse(text)`
- `src/runner/modes/common.rs:112`: `NyashParser::parse_from_string_with_fuel()`
- `src/mir/mod.rs:120`: `MirBuilder::build_module(ast)`
### 2.2 JoinIR 統合状況
**✅ 部分的に統合**: Loop の一部関数のみ JoinIR 経由
**調査結果**:
| 構文 | JoinIR 統合状況 | 実装箇所 | 制御方法 |
|------|----------------|---------|---------|
| **Loop** | ⚠️ 部分統合 | `src/mir/builder/control_flow.rs` | `HAKO_JOINIR_*_MAIN=1` |
| **If** | ❌ 未統合 | `src/mir/builder/if_form.rs` | なし |
**Loop の JoinIR 統合詳細**:
```rust
// src/mir/builder/control_flow.rs:L156-L200
fn try_cf_loop_joinir(&mut self, condition: &ASTNode, body: &ASTNode) -> Result<Option<ValueId>, String> {
let core_on = crate::config::env::joinir_core_enabled();
// Mainline targets: print_tokens, filter
if core_on && is_mainline_target(&func_name) {
// JoinIR Frontend を試す
return self.cf_loop_joinir_impl(condition, body, &func_name, debug);
}
// フォールバック: 旧 LoopBuilder
Ok(None)
}
```
**If の現状**:
```rust
// src/mir/builder/if_form.rs
// JoinIR 統合なし、旧 PHI 生成器を使用中
```
## 調査項目 3: PHI 生成経路
### 3.1 If 文の PHI 生成
**ファイル**: `src/mir/builder/if_form.rs`
**使用経路**: ❌ **旧 If Builder**（JoinIR 未統合）
**実装**:
```rust
// src/mir/builder/if_form.rs
pub fn cf_if(
&mut self,
condition: &ASTNode,
then_block: &ASTNode,
else_block: Option<&ASTNode>,
) -> Result<ValueId, String> {
// 旧 PHI 生成ロジック
// Phase 33-10 で JoinIR If Lowering が実装されたが、
// MirBuilder 経路ではまだ統合されていない
}
```
**問題点**:
- Phase 33-10 で JoinIR If Lowering が実装済み（`src/mir/join_ir/lowering/if_select.rs`）
- しかし MirBuilder の `cf_if()` はまだ旧経路を使用
- hako_check で If 文を含むコードを解析する際、旧 PHI 生成器が使われる
### 3.2 Loop の PHI 生成
**ファイル**: `src/mir/builder/control_flow.rs`
**使用経路**: ⚠️ **部分的に JoinIR Loop Lowering**（Phase 49 統合）
**実装**:
```rust
// src/mir/builder/control_flow.rs
pub fn cf_loop(&mut self, condition: &ASTNode, body: &ASTNode) -> Result<ValueId, String> {
// Phase 49/80: Try JoinIR Frontend route for mainline targets
if let Some(result) = self.try_cf_loop_joinir(&condition, &body)? {
return Ok(result);
}
// Fallback: 旧 LoopBuilder
self.cf_loop_legacy(condition, body)
}
```
**Mainline Targets** (JoinIR 経由):
- `JsonTokenizer.print_tokens/0`: `HAKO_JOINIR_PRINT_TOKENS_MAIN=1`
- `ArrayExtBox.filter/2`: `HAKO_JOINIR_ARRAY_FILTER_MAIN=1`
**その他の Loop**: 旧 LoopBuilder へフォールバック
**JoinIR Frontend の実装箇所**:
- `src/mir/join_ir/frontend/mod.rs`: `AstToJoinIrLowerer`
- `src/mir/join_ir/lowering/loop_*.rs`: Loop Lowering 実装
## 調査項目 4: 環境変数・フラグ
### 4.1 検索コマンド
```bash
rg "NYASH_HAKO_CHECK" --type rust
rg "NYASH_JOINIR" --type rust | grep -i "hako_check"
```
### 4.2 発見された環境変数
#### hako_check 専用環境変数
| 環境変数 | 用途 | 設定箇所 |
|---------|-----|---------|
| `NYASH_DISABLE_PLUGINS=1` | プラグイン無効化 | `tools/hako_check.sh` |
| `NYASH_BOX_FACTORY_POLICY=builtin_first` | ビルトイン Box 優先 | `tools/hako_check.sh` |
| `NYASH_DISABLE_NY_COMPILER=1` | Ny コンパイラ無効化 | `tools/hako_check.sh` |
| `HAKO_DISABLE_NY_COMPILER=1` | Hako コンパイラ無効化 | `tools/hako_check.sh` |
| `NYASH_FEATURES=stage3` | Stage-3 パーサー使用 | `tools/hako_check.sh` |
| `NYASH_JSON_ONLY=1` | JSON 出力のみ | `tools/hako_check.sh` |
#### JoinIR 関連環境変数
| 環境変数 | 用途 | 実装箇所 |
|---------|-----|---------|
| `NYASH_JOINIR_STRICT=1` | フォールバック禁止 | `src/config/env.rs` |
| `NYASH_JOINIR_CORE=1` | JoinIR Core 有効化 | `src/config/env.rs` |
| `HAKO_JOINIR_PRINT_TOKENS_MAIN=1` | print_tokens を JoinIR 経由 | `src/mir/builder/control_flow.rs` |
| `HAKO_JOINIR_ARRAY_FILTER_MAIN=1` | ArrayExt.filter を JoinIR 経由 | `src/mir/builder/control_flow.rs` |
| `NYASH_JOINIR_MAINLINE_DEBUG=1` | JoinIR Mainline デバッグログ | `src/mir/builder/control_flow.rs` |
| `NYASH_JOINIR_EXPERIMENT=1` | JoinIR 実験モード | `src/tests/helpers/joinir_env.rs` |
#### hako_check で使用されていない JoinIR 変数
**Phase 121 調査結果**: hako_check は現在 JoinIR 関連環境変数を使用していない。
**理由**:
- hako_check.sh で `NYASH_DISABLE_NY_COMPILER=1` を設定
- JoinIR 統合は VM の MirBuilder に実装されているが、環境変数での制御がない
- Phase 122 で `NYASH_HAKO_CHECK_JOINIR=1` を導入予定
## Phase 122+ への提言
### 優先度高（Phase 122 実装必須）
- [ ] **`NYASH_HAKO_CHECK_JOINIR=1` 環境変数追加**: hako_check で JoinIR 経路を有効化
- [ ] **If 文の JoinIR 統合**: `src/mir/builder/if_form.rs` の `cf_if()` を JoinIR 対応
- [ ] **Loop の JoinIR 統合拡張**: Mainline Targets 以外も JoinIR 経由に
### 優先度中（Phase 123 実装推奨）
- [ ] **デフォルト変更**: JoinIR 経路をデフォルトに
- [ ] **`NYASH_LEGACY_PHI=1` 環境変数追加**: 旧経路への明示的切り替え
- [ ] **警告メッセージ追加**: 旧経路使用時に非推奨警告
### 優先度低（Phase 124 クリーンアップ）
- [ ] **旧経路削除**: `if_form.rs` / `control_flow.rs` の旧 PHI 生成ロジック削除
- [ ] **環境変数削除**: `NYASH_LEGACY_PHI=1` サポート削除
- [ ] **ドキュメント更新**: 旧経路に関する記述を全削除
## 結論
hako_check 経路の現状は：
### ✅ **良好な点**
1. **安定した実装**: .hako スクリプトとして実装され、VM で安定動作
2. **環境変数制御**: 明確な環境変数で動作を制御
3. **部分統合開始**: Loop の Mainline Targets で JoinIR 統合実績あり
### ❌ **課題**
1. **If 文未統合**: If 文は旧 PHI 生成器を使用中
2. **Loop 部分統合**: Mainline Targets 以外は旧 LoopBuilder にフォールバック
3. **環境変数未整備**: JoinIR 経路を選択する統一的な環境変数がない
### ⚠️ **注意点**
1. **.hako スクリプト**: hako_check は Rust バイナリではないため、VM の MirBuilder に依存
2. **VM 経路のみ**: hako_check は常に `--backend vm` を使用
3. **プラグイン無効**: `NYASH_DISABLE_PLUGINS=1` で安定性優先
### 次のステップ
Phase 122+ で上記課題を段階的に解決する。特に **If 文の JoinIR 統合**が最優先課題。
Status: Historical

768
docs/archive/phases/phase-106-156/phase121_hako_check_joinir_design.md Normal file
View File

@ -0,0 +1,768 @@
# Phase 121: hako_check ラインの JoinIR 統合設計
## 0. ゴール
- **hako_check 経路**を JoinIR 経由に統合する設計を確立
- 現状の hako_check 実装を調査し、どこが旧 MIR/PHI 経路を使っているか明確化
- **Phase 122+ での実装**に向けた設計ドキュメントを作成（Phase 121 は設計のみ）
---
## 1. スコープと非スコープ
### スコープ（今回やること）
1. **設計ドキュメント作成**: `hako_check_design.md` を作成（hako_check の役割・構造・JoinIR 統合方針）
2. **現状調査**: hako_check の実装コードを読み、JoinIR 関連の env/flag 有無を洗い出し
3. **旧 MIR/PHI 経路の特定**: hako_check が使用している PHI 生成器・MIR ビルダーの経路を明確化
4. **統合計画**: JoinIR 経路への移行ステップを設計（Phase 122+ 実装の指針）
5. **Phase 120 との関係整理**: selfhost 経路と hako_check 経路の違いを明確化
### 非スコープ（今回はやらない）
- **実装修正**: hako_check の実装変更（Phase 122+ に回す）
- **テスト追加**: 新規テストの作成（設計確定後に Phase 122+ で実施）
- **パフォーマンス最適化**: JoinIR 統合による性能改善（Phase 123+ で検討）
---
## 2. Task 1: hako_check 設計ドキュメント作成
### 2.1 実装内容
**ファイル**: `docs/development/current/main/hako_check_design.md`（新規）
**記載内容**:
```markdown
# hako_check 設計（Phase 121 時点）
## 概要
**hako_check** は .hako ファイルの静的解析・検証を行うツール。
Phase 121 では、この経路を JoinIR 統合に向けて設計する。
## hako_check の役割
### 現在の機能
- **構文チェック**: パーサーエラーの検出
- **型チェック**: 基本的な型の整合性確認
- **MIR 生成**: .hako → MIR への変換（検証用）
- **制御フローチェック**: unreachable code などの検出
### Phase 121 での課題
- **旧 MIR/PHI 経路**: 現在は旧 PHI 生成器を使用している可能性
- **JoinIR 統合**: JoinIR Lowering 経由に移行する必要性
- **Strict モード**: NYASH_JOINIR_STRICT=1 での動作確認
## 現在の実装構造
### エントリーポイント
[調査結果を記載]
### MIR 生成経路
[調査結果を記載]
### PHI 生成経路
[調査結果を記載]
### 環境変数・フラグ
[調査結果を記載]
## JoinIR 統合設計
### 統合方針
**3段階移行戦略**:
1. **Phase 122**: 環境変数で JoinIR 経路を選択可能に（デフォルトは旧経路）
2. **Phase 123**: JoinIR 経路をデフォルトに（旧経路は `NYASH_LEGACY_PHI=1` でのみ有効）
3. **Phase 124**: 旧経路完全削除（JoinIR のみ）
### 設計原則
**Baseline First**:
- Phase 120 で確立した selfhost 経路のベースラインを参考に
- hako_check 経路でも同様のベースライン確立が必要
**Fail-Fast**:
- フォールバック処理は原則禁止
- エラーは早期に明示的に失敗させる
**環境変数制御**:
- `NYASH_HAKO_CHECK_JOINIR=1`: hako_check で JoinIR 経路を有効化
- `NYASH_JOINIR_STRICT=1`: フォールバック禁止（厳格モード）
## selfhost 経路との違い
| 項目 | selfhost 経路 | hako_check 経路 |
|------|---------------|-----------------|
| **目的** | .hako コンパイラ実行 | .hako 静的解析 |
| **実行** | VM/LLVM で実行 | MIR 生成のみ |
| **PHI 生成** | 実行時に必要 | 検証用のみ |
| **エラー処理** | 実行時エラー | 静的エラー |
## Phase 122+ 実装計画
### Phase 122: 環境変数で JoinIR 選択可能に
**実装内容**:
- [ ] `NYASH_HAKO_CHECK_JOINIR=1` 環境変数追加
- [ ] hako_check エントリーポイントで環境変数確認
- [ ] 条件分岐で JoinIR 経路 or 旧経路を選択
**テスト**:
- [ ] 既存テスト全 PASS（旧経路）
- [ ] JoinIR 経路でのスモークテスト作成
### Phase 123: JoinIR 経路をデフォルトに
**実装内容**:
- [ ] デフォルトを JoinIR 経路に変更
- [ ] `NYASH_LEGACY_PHI=1` で旧経路に戻せるように
**テスト**:
- [ ] JoinIR 経路で全テスト PASS
- [ ] 旧経路でも互換性維持確認
### Phase 124: 旧経路完全削除
**実装内容**:
- [ ] 旧 PHI 生成器削除
- [ ] `NYASH_LEGACY_PHI=1` 環境変数削除
- [ ] 関連ドキュメント更新
**テスト**:
- [ ] JoinIR 経路のみで全テスト PASS
## まとめ
Phase 121 は設計と調査のみ。実装は Phase 122+ で段階的に実施する。
```
---
## 3. Task 2: 現状調査（hako_check 実装の読解）
### 3.1 調査内容
**調査対象**:
1. **hako_check エントリーポイント**
- ファイル: `src/bin/hako_check.rs` または類似
- 調査項目: コマンドライン引数、環境変数の読み込み、実行フロー
2. **MIR 生成経路**
- ファイル: `src/mir/builder/` 配下
- 調査項目: hako_check が使用している MirBuilder の経路
3. **PHI 生成経路**
- ファイル: `src/mir/loop_builder.rs`, `src/mir/if_builder.rs` など
- 調査項目: 旧 PHI 生成器 vs JoinIR Lowering の使い分け
4. **環境変数・フラグ**
- ファイル: 全コード検索
- 調査項目: `NYASH_*` 環境変数の hako_check 関連のもの
### 3.2 調査記録
**ファイル**: `docs/development/current/main/phase121_hako_check_investigation.md`（新規）
**記載内容**:
```markdown
# Phase 121: hako_check 現状調査結果
## 実行日時
2025-12-04（Phase 120 完了直後）
## 調査項目 1: エントリーポイント
**ファイル**: [該当ファイルパス]
**実装内容**:
[コード抜粋]
**環境変数**:
- [環境変数1]: [用途]
- [環境変数2]: [用途]
**コマンドライン引数**:
- [引数1]: [用途]
- [引数2]: [用途]
## 調査項目 2: MIR 生成経路
**ファイル**: [該当ファイルパス]
**使用している MirBuilder**:
- [MirBuilder の種類]
- [呼び出し箇所]
**JoinIR 統合状況**:
- ✅ 既に JoinIR 経由: [詳細]
- ❌ 旧経路を使用: [詳細]
- ⚠️ 部分的に統合: [詳細]
## 調査項目 3: PHI 生成経路
**ファイル**: [該当ファイルパス]
**If 文の PHI 生成**:
- ✅ JoinIR If Lowering: [詳細]
- ❌ 旧 If Builder: [詳細]
**Loop の PHI 生成**:
- ✅ JoinIR Loop Lowering: [詳細]
- ❌ 旧 Loop Builder: [詳細]
## 調査項目 4: 環境変数・フラグ
**検索コマンド**:
```bash
rg "NYASH_HAKO_CHECK" --type rust
rg "NYASH_JOINIR" --type rust | grep -i "hako_check"
```
**発見された環境変数**:
- [環境変数1]: [用途]
- [環境変数2]: [用途]
## Phase 122+ への提言
**優先度高**:
- [ ] [課題1]
- [ ] [課題2]
**優先度中**:
- [ ] [課題3]
- [ ] [課題4]
**優先度低**:
- [ ] [改善案1]
- [ ] [改善案2]
## 結論
hako_check 経路の現状は：
- ✅ **JoinIR 統合済み**: [該当箇所]
- ❌ **旧経路使用中**: [該当箇所]
- ⚠️ **部分的統合**: [該当箇所]
Phase 122+ で上記課題を段階的に解決する。
```
### 3.3 調査手法
**コマンド例**:
```bash
# hako_check エントリーポイント検索
find src/bin -name "*hako_check*" -o -name "*check*"
rg "fn main" src/bin/ | grep -i "check"
# MirBuilder 呼び出し検索
rg "MirBuilder::new" --type rust
rg "build_mir" --type rust | grep -i "check"
# PHI 生成器検索
rg "do_phi" --type rust
rg "JoinIR" --type rust | grep -E "(if|loop)"
# 環境変数検索
rg "NYASH_HAKO_CHECK" --type rust
rg "env::var.*HAKO.*CHECK" --type rust
```
---
## 4. Task 3: 旧 MIR/PHI 経路の特定
### 4.1 実装内容
**ファイル**: `docs/development/current/main/phase121_legacy_path_analysis.md`（新規）
**記載内容**:
```markdown
# Phase 121: 旧 MIR/PHI 経路の特定
## 旧経路の定義
**旧 MIR/PHI 経路**とは：
- **JoinIR Lowering 前**の PHI 生成器を直接使用している経路
- **Phase 33 以前**の実装（If/Loop PHI 生成が直接 MirBuilder に組み込まれていた時期）
## 特定方法
### 1. ファイル名での特定
**旧経路候補**:
- `src/mir/if_builder.rs`: 旧 If PHI 生成器（Phase 33-10 で削除済み？）
- `src/mir/loop_builder.rs`: 旧 Loop PHI 生成器（Phase 33-10 で削除済み？）
**JoinIR 経路**:
- `src/mir/join_ir/lowering/if_select.rs`: JoinIR If Lowering
- `src/mir/join_ir/lowering/loop_*.rs`: JoinIR Loop Lowering
### 2. 関数名での特定
**旧経路の特徴的関数**:
```rust
// 旧 If PHI 生成器
fn build_if_with_phi(...)
fn merge_phi_for_if(...)
// 旧 Loop PHI 生成器
fn build_loop_with_phi(...)
fn merge_phi_for_loop(...)
```
**JoinIR 経路の関数**:
```rust
// JoinIR If Lowering
fn lower_if_to_mir(...)
fn if_select_lowering(...)
// JoinIR Loop Lowering
fn lower_loop_to_mir(...)
fn loop_lowering(...)
```
### 3. 環境変数での特定
**旧経路のフラグ**:
- `NYASH_LEGACY_PHI=1`: 旧 PHI 生成器を強制使用
**JoinIR 経路のフラグ**:
- `NYASH_JOINIR_STRICT=1`: JoinIR Lowering のみ使用（フォールバック禁止）
## hako_check での使用状況
[Task 2 の調査結果に基づいて記載]
### If 文の PHI 生成
**使用経路**: [旧経路 / JoinIR 経路 / 混在]
**根拠**: [コード抜粋・ファイル名・関数名]
### Loop の PHI 生成
**使用経路**: [旧経路 / JoinIR 経路 / 混在]
**根拠**: [コード抜粋・ファイル名・関数名]
## Phase 122+ での移行計画
**移行必要箇所**:
- [ ] [箇所1]: [詳細]
- [ ] [箇所2]: [詳細]
**既に JoinIR 統合済み**:
- ✅ [箇所1]: [詳細]
- ✅ [箇所2]: [詳細]
## まとめ
hako_check 経路の旧 MIR/PHI 使用状況：
- **旧経路使用中**: [件数]箇所
- **JoinIR 統合済み**: [件数]箇所
- **混在**: [件数]箇所
Phase 122+ で段階的に JoinIR 統合を完了する。
```
---
## 5. Task 4: 統合計画とドキュメント更新
### 5.1 統合計画の具体化
**ファイル**: `docs/development/current/main/phase121_integration_roadmap.md`（新規）
**記載内容**:
```markdown
# Phase 121: hako_check JoinIR 統合ロードマップ
## Phase 122: 環境変数で JoinIR 選択可能に
### 目標
hako_check で `NYASH_HAKO_CHECK_JOINIR=1` を指定すると、JoinIR 経路を使用するようにする。
デフォルトは旧経路を維持（互換性重視）。
### 実装ステップ
**Step 1**: 環境変数読み込み機能追加
- [ ] `src/bin/hako_check.rs` に環境変数読み込みコード追加
- [ ] `HakoCheckConfig` struct に `use_joinir: bool` フィールド追加
**Step 2**: 条件分岐の実装
- [ ] MIR 生成時に `use_joinir` を確認
- [ ] `if use_joinir { ... } else { ... }` で経路切り替え
**Step 3**: テスト追加
- [ ] 旧経路テスト: `cargo test --release hako_check_legacy`
- [ ] JoinIR 経路テスト: `NYASH_HAKO_CHECK_JOINIR=1 cargo test --release hako_check_joinir`
### 完了条件
- ✅ 環境変数なし: 旧経路で全テスト PASS
- ✅ `NYASH_HAKO_CHECK_JOINIR=1`: JoinIR 経路で代表テスト PASS
- ✅ ドキュメント更新完了
---
## Phase 123: JoinIR 経路をデフォルトに
### 目標
hako_check のデフォルトを JoinIR 経路に変更。
旧経路は `NYASH_LEGACY_PHI=1` でのみ使用可能に。
### 実装ステップ
**Step 1**: デフォルト値変更
- [ ] `HakoCheckConfig` の `use_joinir` を `true` に変更
- [ ] 環境変数 `NYASH_LEGACY_PHI=1` で旧経路に戻せるように
**Step 2**: 警告メッセージ追加
- [ ] 旧経路使用時に「非推奨」警告を表示
- [ ] JoinIR 経路への移行を促すメッセージ
**Step 3**: 全テスト PASS 確認
- [ ] JoinIR 経路で全テスト PASS
- [ ] `NYASH_LEGACY_PHI=1` で旧経路テスト PASS（互換性維持）
### 完了条件
- ✅ 環境変数なし: JoinIR 経路で全テスト PASS
- ✅ `NYASH_LEGACY_PHI=1`: 旧経路で全テスト PASS（警告あり）
- ✅ ドキュメント更新完了
---
## Phase 124: 旧経路完全削除
### 目標
旧 PHI 生成器を完全削除し、JoinIR 経路のみを使用する。
### 実装ステップ
**Step 1**: 旧経路コード削除
- [ ] `src/mir/if_builder.rs` 削除（または旧 PHI 生成部分削除）
- [ ] `src/mir/loop_builder.rs` 削除（または旧 PHI 生成部分削除）
- [ ] 関連する旧経路のヘルパー関数削除
**Step 2**: 環境変数削除
- [ ] `NYASH_LEGACY_PHI=1` サポート削除
- [ ] `NYASH_HAKO_CHECK_JOINIR=1` サポート削除（常に有効）
**Step 3**: ドキュメント更新
- [ ] 旧経路に関する記述を全削除
- [ ] JoinIR 統合完了を明記
### 完了条件
- ✅ JoinIR 経路のみで全テスト PASS
- ✅ 旧経路コード完全削除
- ✅ ドキュメント更新完了
---
## タイムライン（目安）
| Phase | 実装期間 | 完了条件 |
|-------|---------|---------|
| Phase 122 | 1-2日 | 環境変数で切り替え可能 |
| Phase 123 | 1-2日 | JoinIR デフォルト化 |
| Phase 124 | 1日 | 旧経路完全削除 |
**合計**: 3-5日で hako_check JoinIR 統合完了見込み
---
## リスク管理
### リスク 1: 互換性問題
**内容**: 旧経路に依存しているテストがある
**対策**:
- Phase 122 で環境変数による切り替えを実装
- Phase 123 で段階的にデフォルト変更
### リスク 2: パフォーマンス劣化
**内容**: JoinIR 経路が旧経路より遅い
**対策**:
- Phase 123 でパフォーマンス計測
- 問題があれば Phase 123.5 で最適化
### リスク 3: 未発見バグ
**内容**: JoinIR 経路に未発見のバグが残っている
**対策**:
- Phase 122 で代表テストを追加
- Phase 123 で全テスト PASS を確認
---
## まとめ
Phase 121 で設計を確定し、Phase 122-124 で段階的に実装する。
各 Phase で互換性を維持しながら、最終的に JoinIR 統合を完了する。
```
### 5.2 CURRENT_TASK.md 更新
**ファイル**: `CURRENT_TASK.md`（修正）
**Phase 121 セクション追加**:
```markdown
### 🎯 Phase 121: hako_check JoinIR 統合設計（完了）
- ✅ 設計ドキュメント作成: hako_check_design.md
- ✅ 現状調査完了: phase121_hako_check_investigation.md
- ✅ 旧 MIR/PHI 経路特定: phase121_legacy_path_analysis.md
- ✅ 統合計画策定: phase121_integration_roadmap.md
- ✅ Phase 120 との関係整理完了
**次のステップ**: Phase 122（hako_check 環境変数で JoinIR 選択可能に）
```
---
## 6. 完成チェックリスト（Phase 121）
- [ ] hako_check_design.md 作成（設計ドキュメント）
- [ ] phase121_hako_check_investigation.md 作成（現状調査）
- [ ] phase121_legacy_path_analysis.md 作成（旧経路特定）
- [ ] phase121_integration_roadmap.md 作成（統合計画）
- [ ] hako_check エントリーポイント調査完了
- [ ] MIR 生成経路調査完了
- [ ] PHI 生成経路調査完了
- [ ] 環境変数・フラグ調査完了
- [ ] Phase 122-124 の実装計画確定
- [ ] CURRENT_TASK.md 更新（Phase 121 完了記録）
---
## 7. 設計原則（Phase 121 で確立）
### 設計 First
```
【Phase 121 の哲学】
実装の前に、「どう作るか」を明確にする
Flow:
Phase 120: 現状記録（selfhost 経路ベースライン）
↓
Phase 121: 設計（hako_check 統合計画） ← Complete
↓
Phase 122+: 実装（段階的統合）
```
### 段階的統合の重要性
**3段階移行戦略の利点**:
- **Phase 122**: 環境変数で選択可能（リスク最小）
- **Phase 123**: デフォルト変更（互換性維持）
- **Phase 124**: 旧経路削除（完全統合）
**失敗しない移行のコツ**:
- **各 Phase で全テスト PASS**: 段階的に確認
- **環境変数での切り替え**: いつでも戻れる
- **警告メッセージ**: ユーザーに移行を促す
### Phase 120 との連携
**Phase 120 の成果を活用**:
- **ベースライン確立の手法**: hako_check でも同様の手法を使用
- **JoinIR Strict モード**: hako_check でも適用
- **スモークテスト**: hako_check 版を作成
---
**Phase 121 指示書完成日**: 2025-12-04（Phase 120 完了直後）
---
## Phase 123 Implementation Complete ✅
### 実装日時
2025-12-04
### 環境変数フラグ導入
**ファイル**: `src/config/env/hako_check.rs` (新規作成)
```rust
pub fn hako_check_joinir_enabled() -> bool {
env_bool("NYASH_HAKO_CHECK_JOINIR")
}
```
**デフォルト**: `false` (レガシー経路) - Phase 124 で `true` に変更予定
### JoinIR スイッチ実装
**ファイル**: `src/mir/builder/control_flow.rs`
**実装内容**:
- `cf_if()` メソッドに NYASH_HAKO_CHECK_JOINIR 環境変数チェックを追加
- `use_joinir` フラグに応じて処理を分岐
- Phase 123 では JoinIR 経路はプレースホルダー実装（常にレガシーにフォールバック）
- Phase 124 で完全な JoinIR 統合を実装予定
```rust
pub(super) fn cf_if(...) -> Result<ValueId, String> {
let use_joinir = crate::config::env::hako_check_joinir_enabled();
if use_joinir {
// Phase 123: Placeholder - always fallback to legacy
match self.try_cf_if_joinir(...) {
Ok(Some(value)) => return Ok(value),
_ => { /* fallback to legacy */ }
}
}
self.lower_if_form(condition, then_branch, else_branch)
}
```
### 代表ケース検証結果
**テスト実施日**: 2025-12-04
#### Legacy Path (NYASH_HAKO_CHECK_JOINIR=0)
- ✅ phase123_simple_if.hako: PASS
- ✅ phase123_nested_if.hako: PASS
- ✅ phase123_while_loop.hako: PASS
- ✅ phase123_if_in_loop.hako: PASS
**結果**: 4/4 PASS (100%)
#### JoinIR Path (NYASH_HAKO_CHECK_JOINIR=1)
- ✅ phase123_simple_if.hako: PASS
- ✅ phase123_nested_if.hako: PASS
- ✅ phase123_while_loop.hako: PASS
- ✅ phase123_if_in_loop.hako: PASS
**結果**: 4/4 PASS (100%)
**Note**: Phase 123 では JoinIR 経路はプレースホルダー実装のため、実際にはレガシー経路で処理されている。環境変数の読み取りとフラグ分岐の動作は完全に実装されており、Phase 124 で JoinIR 実装を追加すれば即座に動作可能。
### Known Limitations (Phase 123時点)
1. **JoinIR 経路はプレースホルダー**: `try_cf_if_joinir()` は常に `Ok(None)` を返し、レガシー経路にフォールバックする
2. **完全な JoinIR 統合は Phase 124**: 実際の JoinIR If Lowering 実装は Phase 124 で追加予定
3. **Loop JoinIR 統合は未実装**: Loop の JoinIR 統合も Phase 124 で実装予定
### 次のステップ (Phase 124)
1. `try_cf_if_joinir()` の完全実装
- JoinIR IfSelectLowerer の統合
- MIR 構築後の JoinIR 変換処理
2. Loop JoinIR 統合の追加
3. JoinIR 経路をデフォルト化
4. `NYASH_LEGACY_PHI=1` 環境変数の追加（レガシー経路への切り替え用）
### ビルド・実行結果
**ビルドステータス**: ✅ 成功 (10 warnings, 0 errors)
**実行確認**:
```bash
# レガシー経路（デフォルト）
./target/release/hakorune --backend vm local_tests/phase123_simple_if.hako
# 結果: 正常動作 (exit code 0)
# JoinIR 経路（環境変数指定）
NYASH_HAKO_CHECK_JOINIR=1 ./target/release/hakorune --backend vm local_tests/phase123_simple_if.hako
# 結果: 正常動作 (exit code 0)
```
### 変更ファイルサマリー
| ファイル | 変更内容 | 行数変化 |
|---------|---------|---------|
| `src/config/env/hako_check.rs` | 新規作成 | +60 |
| `src/config/env.rs` | hako_check モジュール追加 | +2 |
| `src/mir/builder/control_flow.rs` | JoinIR スイッチ実装 | +67 |
| `docs/reference/environment-variables.md` | NYASH_HAKO_CHECK_JOINIR 追加 | +1 |
| `local_tests/phase123_*.hako` | テストケース4件作成 | +88 |
| `tools/smokes/v2/profiles/integration/hako_check_joinir.sh` | テストスクリプト作成 | +117 |
**Total**: +335 lines
### まとめ
Phase 123 は **環境変数による経路選択機能の実装**に焦点を当て、以下を達成:
1. ✅ 環境変数 `NYASH_HAKO_CHECK_JOINIR` の実装完了
2. ✅ `cf_if()` メソッドでのフラグチェック・分岐実装完了
3. ✅ 代表テストケース4件作成・検証完了（両経路で100% PASS）
4. ✅ ドキュメント更新完了
---
## Phase 122-124 実装完了サマリー
### Phase 123: 環境変数スイッチ導入（完了）
- NYASH_HAKO_CHECK_JOINIR で 2パス選択可能に
- プレースホルダー実装でフレームワーク確立
- 代表テスト 4 ケース両経路で PASS
### Phase 124: JoinIR 専用化 & レガシー削除（完了 ✅）
- NYASH_HAKO_CHECK_JOINIR を完全廃止
- MIR Builder から legacy if/loop lowering 分岐削除
- hako_check は JoinIR 一本化（Fail-Fast 原則）
- 環境変数なしで JoinIR 経路がデフォルト動作
### 最終アーキテクチャ図（Phase 124）
```
.hako file
↓
Parse & Tokenize → AST
↓
MIR Builder (JoinIR lowering for if/loop)
├─ cf_if() → lower_if_form() (JoinIR)
└─ cf_loop() → LoopBuilder (JoinIR)
↓
MIR (SSA form with JoinIR-generated PHI)
↓
VM Interpreter
↓
Diagnostic Output
```
### 成果
✅ hako_check + selfhost Stage-3 が JoinIR 統一パイプラインで動作
✅ ドキュメント・実装・テストが JoinIR 前提に統一
✅ 環境変数フラグ削除により実装簡素化
✅ Fail-Fast 原則に準拠したエラーハンドリング
### 次章予告
次は selfhost Stage-4（高度なパターン対応）への準備を進める。
Status: Historical

549
docs/archive/phases/phase-106-156/phase121_integration_roadmap.md Normal file
View File

@ -0,0 +1,549 @@
# Phase 121: hako_check JoinIR 統合ロードマップ
## Phase 122: 環境変数で JoinIR 選択可能に
### 目標
hako_check で `NYASH_HAKO_CHECK_JOINIR=1` を指定すると、JoinIR 経路を使用するようにする。
デフォルトは旧経路を維持（互換性重視）。
### 実装ステップ
#### Step 1: 環境変数読み込み機能追加
**ファイル**: `src/config/env.rs`
**実装内容**:
```rust
/// hako_check で JoinIR 経路を有効化するフラグ
pub fn hako_check_joinir_enabled() -> bool {
env_flag("NYASH_HAKO_CHECK_JOINIR").unwrap_or(false)
}
```
**チェックリスト**:
- [ ] `src/config/env.rs` に `hako_check_joinir_enabled()` 関数追加
- [ ] 既存の `joinir_core_enabled()` との関係を整理
- [ ] ドキュメント更新（環境変数リスト）
#### Step 2: If 文の JoinIR 統合
**ファイル**: `src/mir/builder/if_form.rs`
**実装内容**:
```rust
// Phase 122: 環境変数で JoinIR 経路を選択可能に
pub fn cf_if(
&mut self,
condition: &ASTNode,
then_block: &ASTNode,
else_block: Option<&ASTNode>,
) -> Result<ValueId, String> {
// Phase 122: 環境変数チェック
if crate::config::env::hako_check_joinir_enabled() {
// JoinIR If Lowering を使用
return self.cf_if_joinir(condition, then_block, else_block);
}
// 旧 PHI 生成器（互換性維持）
self.cf_if_legacy(condition, then_block, else_block)
}
/// Phase 122: JoinIR If Lowering 経由
fn cf_if_joinir(
&mut self,
condition: &ASTNode,
then_block: &ASTNode,
else_block: Option<&ASTNode>,
) -> Result<ValueId, String> {
use crate::mir::join_ir::lowering::if_select::lower_if_to_mir;
lower_if_to_mir(self, condition, then_block, else_block)
}
/// 既存ロジックを cf_if_legacy に移動
fn cf_if_legacy(
&mut self,
condition: &ASTNode,
then_block: &ASTNode,
else_block: Option<&ASTNode>,
) -> Result<ValueId, String> {
// 既存の cf_if() ロジックをここに移動
// ...
}
```
**チェックリスト**:
- [ ] `cf_if_joinir()` 関数を追加（JoinIR Lowering 呼び出し）
- [ ] `cf_if()` に環境変数チェックを追加
- [ ] 既存ロジックを `cf_if_legacy()` に移動
- [ ] JoinIR If Lowering（`if_select.rs`）との連携確認
#### Step 3: Loop の JoinIR 統合拡張
**ファイル**: `src/mir/builder/control_flow.rs`
**実装内容**:
```rust
// Phase 122: 環境変数で全 Loop を JoinIR 経由に
pub fn cf_loop(
&mut self,
condition: &ASTNode,
body: &ASTNode,
) -> Result<ValueId, String> {
// Phase 122: hako_check 環境変数チェック
if crate::config::env::hako_check_joinir_enabled() {
// すべての Loop を JoinIR 経由に
if let Some(result) = self.try_cf_loop_joinir_all(&condition, &body)? {
return Ok(result);
}
// JoinIR 失敗時はエラー（フォールバック禁止）
return Err("JoinIR Loop Lowering failed (NYASH_HAKO_CHECK_JOINIR=1)".to_string());
}
// Phase 49: Mainline Targets のみ JoinIR 経由（既存ロジック）
if let Some(result) = self.try_cf_loop_joinir(&condition, &body)? {
return Ok(result);
}
// Fallback: 旧 LoopBuilder
self.cf_loop_legacy(condition, body)
}
/// Phase 122: すべての Loop を JoinIR 経由に
fn try_cf_loop_joinir_all(
&mut self,
condition: &ASTNode,
body: &ASTNode,
) -> Result<Option<ValueId>, String> {
// Mainline Targets 制限を削除
let debug = std::env::var("NYASH_JOINIR_MAINLINE_DEBUG").is_ok();
let func_name = self.current_function_name();
if debug {
eprintln!(
"[cf_loop/joinir/all] Routing {} through JoinIR Frontend (all loops)",
func_name
);
}
self.cf_loop_joinir_impl(condition, body, &func_name, debug)
}
```
**チェックリスト**:
- [ ] `try_cf_loop_joinir_all()` 関数を追加（Mainline 制限なし）
- [ ] `cf_loop()` に環境変数チェックを追加
- [ ] フォールバック禁止ロジックを実装
- [ ] JoinIR Loop Lowering との連携確認
#### Step 4: テスト追加
**スモークテスト**: `tools/smokes/v2/profiles/quick/analyze/hako_check_joinir_smoke.sh`
**実装内容**:
```bash
#!/usr/bin/env bash
set -euo pipefail
ROOT="$(cd "$(dirname "$0")/../../../../.." && pwd)"
# Phase 122: hako_check JoinIR 経路スモークテスト
echo "=== hako_check JoinIR Smoke Test ==="
# Test 1: If 文（JoinIR 経由）
echo "Test 1: If statement with JoinIR"
cat > /tmp/hako_check_if_test.hako <<'EOF'
static box Main {
method main(args) {
local x = 1
if x == 1 {
print("then")
} else {
print("else")
}
return 0
}
}
EOF
NYASH_HAKO_CHECK_JOINIR=1 "$ROOT/tools/hako_check.sh" /tmp/hako_check_if_test.hako
echo "✅ If statement test passed"
# Test 2: Loop（JoinIR 経由）
echo "Test 2: Loop with JoinIR"
cat > /tmp/hako_check_loop_test.hako <<'EOF'
static box Main {
method main(args) {
local i = 0
loop (i < 3) {
print(i)
i = i + 1
}
return 0
}
}
EOF
NYASH_HAKO_CHECK_JOINIR=1 "$ROOT/tools/hako_check.sh" /tmp/hako_check_loop_test.hako
echo "✅ Loop test passed"
# Test 3: 互換性（旧経路）
echo "Test 3: Legacy path compatibility"
"$ROOT/tools/hako_check.sh" /tmp/hako_check_if_test.hako
echo "✅ Legacy path test passed"
echo "=== All tests passed ==="
```
**チェックリスト**:
- [ ] スモークテストスクリプト作成
- [ ] If 文テスト実装
- [ ] Loop テスト実装
- [ ] 互換性テスト実装（旧経路）
- [ ] CI に統合
#### Step 5: ドキュメント更新
**更新ファイル**:
- `docs/development/current/main/hako_check_design.md`: Phase 122 実装完了を記録
- `docs/reference/env-vars.md`: `NYASH_HAKO_CHECK_JOINIR=1` を追加
- `CLAUDE.md`: Phase 122 完了を記録
**チェックリスト**:
- [ ] 設計ドキュメント更新
- [ ] 環境変数リファレンス更新
- [ ] CLAUDE.md 更新
### 完了条件
- ✅ 環境変数なし: 旧経路で全テスト PASS
- ✅ `NYASH_HAKO_CHECK_JOINIR=1`: JoinIR 経路で代表テスト PASS
- ✅ ドキュメント更新完了
### タイムライン（目安）
| タスク | 所要時間 | 担当 |
|-------|---------|-----|
| Step 1: 環境変数読み込み | 30分 | 実装者 |
| Step 2: If 文 JoinIR 統合 | 2-3時間 | 実装者 |
| Step 3: Loop JoinIR 統合拡張 | 1-2時間 | 実装者 |
| Step 4: テスト追加 | 1-2時間 | 実装者 |
| Step 5: ドキュメント更新 | 30分 | 実装者 |
| **合計** | **1日** | - |
---
## Phase 123: JoinIR 経路をデフォルトに
### 目標
hako_check のデフォルトを JoinIR 経路に変更。
旧経路は `NYASH_LEGACY_PHI=1` でのみ使用可能に。
### 実装ステップ
#### Step 1: デフォルト値変更
**ファイル**: `src/config/env.rs`
**実装内容**:
```rust
/// hako_check で JoinIR 経路を有効化するフラグ
/// Phase 123: デフォルトを true に変更
pub fn hako_check_joinir_enabled() -> bool {
// Phase 123: デフォルトを true に変更
// NYASH_LEGACY_PHI=1 で旧経路に戻せる
if env_flag("NYASH_LEGACY_PHI").unwrap_or(false) {
return false;
}
// NYASH_HAKO_CHECK_JOINIR=0 で明示的に無効化
env_flag("NYASH_HAKO_CHECK_JOINIR").unwrap_or(true)
}
```
**チェックリスト**:
- [ ] `hako_check_joinir_enabled()` のデフォルトを `true` に変更
- [ ] `NYASH_LEGACY_PHI=1` サポート追加
- [ ] 環境変数優先順位を整理
#### Step 2: 警告メッセージ追加
**ファイル**: `src/mir/builder/if_form.rs`, `src/mir/builder/control_flow.rs`
**実装内容**:
```rust
// Phase 123: 旧経路使用時に警告
pub fn cf_if(
&mut self,
condition: &ASTNode,
then_block: &ASTNode,
else_block: Option<&ASTNode>,
) -> Result<ValueId, String> {
if crate::config::env::hako_check_joinir_enabled() {
return self.cf_if_joinir(condition, then_block, else_block);
}
// Phase 123: 旧経路使用時に警告
eprintln!(
"[WARN] Using legacy PHI path for If statement. Set NYASH_LEGACY_PHI=0 to use JoinIR path."
);
self.cf_if_legacy(condition, then_block, else_block)
}
```
**チェックリスト**:
- [ ] If 文の旧経路使用時に警告を追加
- [ ] Loop の旧経路使用時に警告を追加
- [ ] 警告メッセージに移行ガイドを含める
#### Step 3: 全テスト PASS 確認
**テスト内容**:
```bash
# JoinIR 経路で全テスト PASS（デフォルト）
./tools/hako_check.sh apps/
./tools/smokes/v2/run.sh --profile quick --filter "hc*"
# 旧経路で互換性維持確認
NYASH_LEGACY_PHI=1 ./tools/hako_check.sh apps/
NYASH_LEGACY_PHI=1 ./tools/smokes/v2/run.sh --profile quick --filter "hc*"
```
**チェックリスト**:
- [ ] JoinIR 経路で全テスト PASS
- [ ] `NYASH_LEGACY_PHI=1` で旧経路テスト PASS（互換性維持）
- [ ] 警告メッセージが正しく表示されることを確認
### 完了条件
- ✅ 環境変数なし: JoinIR 経路で全テスト PASS
- ✅ `NYASH_LEGACY_PHI=1`: 旧経路で全テスト PASS（警告あり）
- ✅ ドキュメント更新完了
### タイムライン（目安）
| タスク | 所要時間 | 担当 |
|-------|---------|-----|
| Step 1: デフォルト値変更 | 30分 | 実装者 |
| Step 2: 警告メッセージ追加 | 1時間 | 実装者 |
| Step 3: 全テスト PASS 確認 | 2-3時間 | 実装者 |
| ドキュメント更新 | 30分 | 実装者 |
| **合計** | **1日** | - |
---
## Phase 124: 旧経路完全削除
### 目標
旧 PHI 生成器を完全削除し、JoinIR 経路のみを使用する。
### 実装ステップ
#### Step 1: 旧経路コード削除
**ファイル**: `src/mir/builder/if_form.rs`
**実装内容**:
```rust
// Phase 124: 旧経路削除、JoinIR のみ使用
pub fn cf_if(
&mut self,
condition: &ASTNode,
then_block: &ASTNode,
else_block: Option<&ASTNode>,
) -> Result<ValueId, String> {
// JoinIR If Lowering のみ
self.cf_if_joinir(condition, then_block, else_block)
}
// cf_if_legacy() 削除
```
**ファイル**: `src/mir/builder/control_flow.rs`
**実装内容**:
```rust
// Phase 124: 旧経路削除、JoinIR のみ使用
pub fn cf_loop(
&mut self,
condition: &ASTNode,
body: &ASTNode,
) -> Result<ValueId, String> {
// JoinIR Loop Lowering のみ
if let Some(result) = self.try_cf_loop_joinir_all(&condition, &body)? {
return Ok(result);
}
Err("JoinIR Loop Lowering failed".to_string())
}
// cf_loop_legacy() 削除
// try_cf_loop_joinir() 削除（Mainline Targets 制限版）
```
**チェックリスト**:
- [ ] `cf_if_legacy()` 削除（`if_form.rs`）
- [ ] `cf_loop_legacy()` 削除（`control_flow.rs`）
- [ ] 関連する旧 PHI 生成ヘルパー関数削除
- [ ] フォールバックロジック削除
#### Step 2: 環境変数削除
**ファイル**: `src/config/env.rs`
**実装内容**:
```rust
/// hako_check で JoinIR 経路を有効化するフラグ
/// Phase 124: 常に true（環境変数不要）
pub fn hako_check_joinir_enabled() -> bool {
true // 常に JoinIR 経路
}
```
**チェックリスト**:
- [ ] `NYASH_LEGACY_PHI=1` サポート削除
- [ ] `NYASH_HAKO_CHECK_JOINIR=1` サポート削除（常に有効）
- [ ] 関連する環境変数チェックコード削除
#### Step 3: ドキュメント更新
**更新ファイル**:
- `docs/development/current/main/hako_check_design.md`: 旧経路に関する記述削除
- `docs/reference/env-vars.md`: 削除された環境変数を記録
- `CLAUDE.md`: Phase 124 完了を記録
- `CURRENT_TASK.md`: Phase 121-124 完了を記録
**チェックリスト**:
- [ ] 設計ドキュメントから旧経路の記述削除
- [ ] 環境変数リファレンス更新
- [ ] CLAUDE.md 更新
- [ ] CURRENT_TASK.md 更新
### 完了条件
- ✅ JoinIR 経路のみで全テスト PASS
- ✅ 旧経路コード完全削除
- ✅ ドキュメント更新完了
### タイムライン（目安）
| タスク | 所要時間 | 担当 |
|-------|---------|-----|
| Step 1: 旧経路コード削除 | 2-3時間 | 実装者 |
| Step 2: 環境変数削除 | 1時間 | 実装者 |
| Step 3: ドキュメント更新 | 1時間 | 実装者 |
| 全テスト PASS 確認 | 1時間 | 実装者 |
| **合計** | **1日** | - |
---
## タイムライン（目安）
| Phase | 実装期間 | 完了条件 |
|-------|---------|---------|
| Phase 122 | 1日 | 環境変数で切り替え可能 |
| Phase 123 | 1日 | JoinIR デフォルト化 |
| Phase 124 | 1日 | 旧経路完全削除 |
**合計**: 3日で hako_check JoinIR 統合完了見込み
---
## リスク管理
### リスク 1: 互換性問題
**内容**: 旧経路に依存しているテストがある
**対策**:
- Phase 122 で環境変数による切り替えを実装
- Phase 123 で段階的にデフォルト変更
- 各 Phase で全テスト PASS を確認
**検出方法**:
```bash
# 旧経路でのテスト
NYASH_LEGACY_PHI=1 cargo test --release
# JoinIR 経路でのテスト
NYASH_HAKO_CHECK_JOINIR=1 cargo test --release
```
### リスク 2: パフォーマンス劣化
**内容**: JoinIR 経路が旧経路より遅い
**対策**:
- Phase 123 でパフォーマンス計測
- 問題があれば Phase 123.5 で最適化
- ベンチマークスクリプト作成
**計測方法**:
```bash
# 旧経路でのベンチマーク
time NYASH_LEGACY_PHI=1 ./tools/hako_check.sh apps/
# JoinIR 経路でのベンチマーク
time NYASH_HAKO_CHECK_JOINIR=1 ./tools/hako_check.sh apps/
```
### リスク 3: 未発見バグ
**内容**: JoinIR 経路に未発見のバグが残っている
**対策**:
- Phase 122 で代表テストを追加
- Phase 123 で全テスト PASS を確認
- Phase 124 で最終確認テスト実施
**検出方法**:
```bash
# 全スモークテスト実行
./tools/smokes/v2/run.sh --profile quick
# 全 hako_check テスト実行
./tools/hako_check.sh apps/
./tools/hako_check.sh tools/
./tools/hako_check.sh local_tests/
```
### リスク 4: JoinIR If Lowering の未成熟
**内容**: JoinIR If Lowering（`if_select.rs`）が一部のパターンに対応していない
**対策**:
- Phase 122 でエラーハンドリングを強化
- 未対応パターンを明確に検出してエラー報告
- 必要に応じて JoinIR If Lowering を拡張
**検出方法**:
```bash
# JoinIR Strict モードでテスト
NYASH_JOINIR_STRICT=1 NYASH_HAKO_CHECK_JOINIR=1 ./tools/hako_check.sh apps/
```
---
## まとめ
Phase 121 で設計を確定し、Phase 122-124 で段階的に実装する。
各 Phase で互換性を維持しながら、最終的に JoinIR 統合を完了する。
### 実装優先順位
1. **Phase 122**: 環境変数で JoinIR 選択可能に（最優先）
2. **Phase 123**: JoinIR 経路をデフォルトに（優先度高）
3. **Phase 124**: 旧経路完全削除（クリーンアップ）
### 期待される効果
- **コード削減**: 約 500-600 行削減（MirBuilder の約 5-10%）
- **保守性向上**: PHI 生成ロジックが JoinIR に統一
- **安定性向上**: 旧 PHI 生成器のバグが根絶
### 次のステップ
Phase 122 の実装を開始する。特に **If 文の JoinIR 統合**が最優先課題。
Status: Historical

370
docs/archive/phases/phase-106-156/phase121_legacy_path_analysis.md Normal file
View File

@ -0,0 +1,370 @@
# Phase 121: 旧 MIR/PHI 経路の特定
## 旧経路の定義
**旧 MIR/PHI 経路**とは：
- **JoinIR Lowering 前**の PHI 生成器を直接使用している経路
- **Phase 33 以前**の実装（If/Loop PHI 生成が直接 MirBuilder に組み込まれていた時期）
- Phase 33-10 で JoinIR If/Loop Lowering が実装されたが、MirBuilder への統合は未完
## 特定方法
### 1. ファイル名での特定
#### 旧経路候補
| ファイル | 状態 | 用途 |
|---------|------|------|
| `src/mir/builder/if_form.rs` | ✅ **現役** | 旧 If PHI 生成器（JoinIR 未統合） |
| `src/mir/builder/control_flow.rs` | ⚠️ **部分統合** | Loop PHI 生成器（Mainline のみ JoinIR） |
| `src/mir/loop_builder.rs` | ❓ **調査中** | 旧 Loop PHI 生成器（Phase 33-10 で削除済み？） |
#### JoinIR 経路
| ファイル | 状態 | 用途 |
|---------|------|------|
| `src/mir/join_ir/lowering/if_select.rs` | ✅ **実装済み** | JoinIR If Lowering |
| `src/mir/join_ir/lowering/loop_*.rs` | ✅ **実装済み** | JoinIR Loop Lowering |
| `src/mir/join_ir/frontend/mod.rs` | ✅ **実装済み** | AST → JoinIR 変換 |
### 2. 関数名での特定
#### 旧経路の特徴的関数
**If 文**（`src/mir/builder/if_form.rs`）:
```rust
// 旧 If PHI 生成器（Phase 121 時点で現役）
pub fn cf_if(
&mut self,
condition: &ASTNode,
then_block: &ASTNode,
else_block: Option<&ASTNode>,
) -> Result<ValueId, String> {
// 旧 PHI 生成ロジック
// - BasicBlock 直接操作
// - PHI 命令を手動で挿入
// - JoinIR Lowering を経由しない
}
```
**特徴**:
- `BasicBlock::phi()` を直接呼び出し
- `merge_phi_for_if()` 等のヘルパー関数使用
- JoinIR Lowering を経由しない
**Loop**（`src/mir/builder/control_flow.rs`）:
```rust
// Phase 49: 部分的に JoinIR 統合済み
pub fn cf_loop(
&mut self,
condition: &ASTNode,
body: &ASTNode,
) -> Result<ValueId, String> {
// Phase 49/80: Try JoinIR Frontend route for mainline targets
if let Some(result) = self.try_cf_loop_joinir(&condition, &body)? {
return Ok(result);
}
// Fallback: 旧 LoopBuilder
self.cf_loop_legacy(condition, body)
}
```
**特徴**:
- `try_cf_loop_joinir()` で JoinIR 経由を試みる
- 失敗時は `cf_loop_legacy()` へフォールバック
- Mainline Targets のみ JoinIR 経由
#### JoinIR 経路の関数
**If Lowering**（`src/mir/join_ir/lowering/if_select.rs`）:
```rust
// JoinIR If Lowering（Phase 33-10 実装済み）
pub fn lower_if_to_mir(...) -> Result<ValueId, String> {
// JoinIR ベースの If Lowering
// - IfMerge/IfSelect 命令を生成
// - PHI 命令を自動生成
}
```
**Loop Lowering**（`src/mir/join_ir/lowering/loop_*.rs`）:
```rust
// JoinIR Loop Lowering（Phase 33 実装済み）
pub fn lower_loop_to_mir(...) -> Result<ValueId, String> {
// JoinIR ベースの Loop Lowering
// - LoopForm を使用
// - PHI 命令を自動生成
}
```
### 3. 環境変数での特定
#### 旧経路のフラグ
**Phase 121 調査結果**: 明示的な旧経路フラグは**存在しない**
**理由**:
- 旧経路がデフォルトのため、フラグで有効化する必要がない
- Phase 122 で `NYASH_LEGACY_PHI=1` を導入予定
#### JoinIR 経路のフラグ
| 環境変数 | 用途 | 実装箇所 |
|---------|-----|---------|
| `NYASH_JOINIR_STRICT=1` | フォールバック禁止（厳格モード） | `src/config/env.rs` |
| `NYASH_JOINIR_CORE=1` | JoinIR Core 有効化 | `src/config/env.rs` |
| `HAKO_JOINIR_PRINT_TOKENS_MAIN=1` | print_tokens を JoinIR 経由 | `src/mir/builder/control_flow.rs` |
| `HAKO_JOINIR_ARRAY_FILTER_MAIN=1` | ArrayExt.filter を JoinIR 経由 | `src/mir/builder/control_flow.rs` |
## hako_check での使用状況
### If 文の PHI 生成
**使用経路**: ❌ **旧経路**（`src/mir/builder/if_form.rs`）
**根拠**:
1. **ファイル**: `src/mir/builder/if_form.rs` が現役
2. **関数**: `cf_if()` が JoinIR Lowering を呼び出していない
3. **コード抜粋**:
```rust
// src/mir/builder/if_form.rs:L1-L50
pub fn cf_if(
&mut self,
condition: &ASTNode,
then_block: &ASTNode,
else_block: Option<&ASTNode>,
) -> Result<ValueId, String> {
// 旧 PHI 生成ロジック（JoinIR Lowering 未使用）
// ...
}
```
**問題点**:
- Phase 33-10 で JoinIR If Lowering が実装済み（`if_select.rs`）
- しかし MirBuilder の `cf_if()` はまだ JoinIR を呼び出していない
- hako_check で If 文を含むコードを解析する際、旧 PHI 生成器が使われる
### Loop の PHI 生成
**使用経路**: ⚠️ **混在**（Mainline Targets のみ JoinIR 経由）
**根拠**:
1. **ファイル**: `src/mir/builder/control_flow.rs`
2. **関数**: `cf_loop()` → `try_cf_loop_joinir()`
3. **コード抜粋**:
```rust
// src/mir/builder/control_flow.rs:L150-L200
pub fn cf_loop(
&mut self,
condition: &ASTNode,
body: &ASTNode,
) -> Result<ValueId, String> {
// Phase 49/80: Try JoinIR Frontend route for mainline targets
if let Some(result) = self.try_cf_loop_joinir(&condition, &body)? {
return Ok(result);
}
// Fallback: 旧 LoopBuilder
self.cf_loop_legacy(condition, body)
}
```
**Mainline Targets** (JoinIR 経由):
- `JsonTokenizer.print_tokens/0`
- `ArrayExtBox.filter/2`
**その他の Loop** (旧経路):
- 上記以外のすべての Loop 文
## Phase 122+ での移行計画
### 移行必要箇所
#### 1. If 文の JoinIR 統合（最優先）
**ファイル**: `src/mir/builder/if_form.rs`
**現状**: ❌ 旧 PHI 生成器を使用中
**移行方法**:
```rust
// Phase 122: 環境変数で JoinIR 経路を選択可能に
pub fn cf_if(
&mut self,
condition: &ASTNode,
then_block: &ASTNode,
else_block: Option<&ASTNode>,
) -> Result<ValueId, String> {
// Phase 122: 環境変数チェック
if crate::config::env::env_bool("NYASH_HAKO_CHECK_JOINIR") {
// JoinIR If Lowering を使用
return self.cf_if_joinir(condition, then_block, else_block);
}
// 旧 PHI 生成器（互換性維持）
self.cf_if_legacy(condition, then_block, else_block)
}
fn cf_if_joinir(
&mut self,
condition: &ASTNode,
then_block: &ASTNode,
else_block: Option<&ASTNode>,
) -> Result<ValueId, String> {
// JoinIR If Lowering を呼び出す
use crate::mir::join_ir::lowering::if_select::lower_if_to_mir;
lower_if_to_mir(self, condition, then_block, else_block)
}
```
**実装ステップ**:
1. [ ] `cf_if_joinir()` 関数を追加（JoinIR Lowering 呼び出し）
2. [ ] `cf_if()` に環境変数チェックを追加
3. [ ] 既存ロジックを `cf_if_legacy()` に移動
#### 2. Loop の JoinIR 統合拡張（優先度中）
**ファイル**: `src/mir/builder/control_flow.rs`
**現状**: ⚠️ Mainline Targets のみ JoinIR 経由
**移行方法**:
```rust
// Phase 122: すべての Loop を JoinIR 経由に
pub fn cf_loop(
&mut self,
condition: &ASTNode,
body: &ASTNode,
) -> Result<ValueId, String> {
// Phase 122: 環境変数チェック
if crate::config::env::env_bool("NYASH_HAKO_CHECK_JOINIR") {
// すべての Loop を JoinIR 経由に
if let Some(result) = self.try_cf_loop_joinir(&condition, &body)? {
return Ok(result);
}
}
// Phase 49: Mainline Targets のみ JoinIR 経由（既存ロジック）
if let Some(result) = self.try_cf_loop_joinir(&condition, &body)? {
return Ok(result);
}
// Fallback: 旧 LoopBuilder
self.cf_loop_legacy(condition, body)
}
```
**実装ステップ**:
1. [ ] `try_cf_loop_joinir()` の Mainline Targets 制限を削除
2. [ ] 環境変数で制御するように変更
3. [ ] フォールバックロジックを整理
### 既に JoinIR 統合済み
#### 1. Loop Mainline Targets（Phase 49）
**ファイル**: `src/mir/builder/control_flow.rs`
**詳細**:
- ✅ `JsonTokenizer.print_tokens/0`: JoinIR 経由で動作確認済み
- ✅ `ArrayExtBox.filter/2`: JoinIR 経由で動作確認済み
**実装**:
```rust
// Phase 49: Mainline Integration
fn try_cf_loop_joinir(&mut self, condition: &ASTNode, body: &ASTNode) -> Result<Option<ValueId>, String> {
let core_on = crate::config::env::joinir_core_enabled();
// Mainline targets
let mainline_targets = vec!["print_tokens", "filter"];
if core_on && is_mainline_target(&func_name) {
// JoinIR Frontend を使用
return self.cf_loop_joinir_impl(condition, body, &func_name, debug);
}
Ok(None)
}
```
#### 2. JoinIR Frontend（Phase 49）
**ファイル**: `src/mir/join_ir/frontend/mod.rs`
**詳細**:
- ✅ `AstToJoinIrLowerer`: AST → JoinIR 変換
- ✅ JSON v0 → JoinIR 変換
- ✅ JoinModule 生成
## 旧経路と JoinIR 経路の比較
### If 文
| 項目 | 旧経路 | JoinIR 経路 |
|------|--------|------------|
| **ファイル** | `src/mir/builder/if_form.rs` | `src/mir/join_ir/lowering/if_select.rs` |
| **関数** | `cf_if()` | `lower_if_to_mir()` |
| **PHI 生成** | 手動（BasicBlock::phi()） | 自動（IfMerge/IfSelect） |
| **統合状況** | ❌ 現役使用中 | ✅ 実装済み（未統合） |
| **環境変数** | なし | `NYASH_HAKO_CHECK_JOINIR=1`（Phase 122） |
### Loop
| 項目 | 旧経路 | JoinIR 経路 |
|------|--------|------------|
| **ファイル** | `src/mir/builder/control_flow.rs` | `src/mir/join_ir/frontend/mod.rs` |
| **関数** | `cf_loop_legacy()` | `cf_loop_joinir_impl()` |
| **PHI 生成** | 手動（LoopBuilder） | 自動（LoopForm） |
| **統合状況** | ⚠️ フォールバック経路 | ⚠️ Mainline Targets のみ |
| **環境変数** | なし | `HAKO_JOINIR_*_MAIN=1` |
## コード削減見込み
### Phase 122 完了後
**削減箇所**:
- `src/mir/builder/if_form.rs`: 旧 PHI 生成ロジック削除可能（Phase 124）
- `src/mir/builder/control_flow.rs`: `cf_loop_legacy()` 削除可能（Phase 124）
**削減見込み**:
- `if_form.rs`: 約 200-300 行削減
- `control_flow.rs`: 約 100-150 行削減
- **合計**: 約 300-450 行削減
### Phase 124 完了後（旧経路完全削除）
**削減箇所**:
- 旧 PHI 生成ヘルパー関数削除
- フォールバックロジック削除
- 環境変数制御コード削除
**削減見込み**:
- **合計**: 約 500-600 行削減（MirBuilder 全体の約 5-10%）
## まとめ
hako_check 経路の旧 MIR/PHI 使用状況：
### ❌ **旧経路使用中**: 1箇所
1. **If 文の PHI 生成**（`src/mir/builder/if_form.rs`）
- ファイル: `if_form.rs`
- 関数: `cf_if()`
- 根拠: JoinIR Lowering を呼び出していない
### ⚠️ **部分的統合**: 1箇所
1. **Loop の PHI 生成**（`src/mir/builder/control_flow.rs`）
- ファイル: `control_flow.rs`
- 関数: `cf_loop()` → `try_cf_loop_joinir()`
- 根拠: Mainline Targets のみ JoinIR 経由、その他はフォールバック
### ✅ **JoinIR 統合済み**: 0箇所（完全統合は未完）
**Phase 122+ で段階的に JoinIR 統合を完了する。**
**最優先課題**: **If 文の JoinIR 統合**（`src/mir/builder/if_form.rs`）
Status: Historical

106
docs/archive/phases/phase-106-156/phase122_5_nyash_toml_fix.md Normal file
View File

@ -0,0 +1,106 @@
# Phase 122.5: nyash.toml ConsoleBox.println method_id 修正
## 目的
Phase 122 で ConsoleBox.println を log のエイリアスとして実装した際に、TypeRegistry では slot 400 (log と同じ) にマッピングしたが、nyash.toml では println に method_id = 2 が指定されたままになっている問題を修正する。
## 問題の詳細
### 現在の状態
**src/runtime/type_registry.rs**:
```rust
const CONSOLE_METHODS: &[MethodEntry] = &[
MethodEntry { name: "log", arity: 1, slot: 400 },
MethodEntry { name: "warn", arity: 1, slot: 401 },
MethodEntry { name: "error", arity: 1, slot: 402 },
MethodEntry { name: "clear", arity: 0, slot: 403 },
MethodEntry { name: "println", arity: 1, slot: 400 }, // ← log と同じ slot 400
];
```
**nyash.toml (line 720-722)** ❌ **不一致！**:
```toml
[libraries."libnyash_console_plugin.so".ConsoleBox.methods]
log = { method_id = 1 }
print = { method_id = 1 }
println = { method_id = 2 } # ❌ エイリアスなら log と同じ ID にすべき
```
### なぜこれが問題か
TypeRegistry（Rust側）では println と log が同じ slot 400 にマッピングされているため、プラグインシステムはこれを同じメソッドとして処理する。しかし nyash.toml では異なる method_id が指定されているため、不整合が発生する可能性がある：
1. **プラグイン呼び出し時**: Rust VM は TypeRegistry から slot 400 を取得
2. **プラグイン実装側**: method_id で println (2) と log (1) を区別する可能性
3. **結果**: プラグインが println に対応していない可能性がある
この不整合を解決する必要がある。
## 修正内容
### 修正対象
**ファイル**: `nyash.toml`
**行**: 722
### 修正内容
```diff
[libraries."libnyash_console_plugin.so".ConsoleBox.methods]
birth = { method_id = 0 }
log = { method_id = 1 }
print = { method_id = 1 }
-println = { method_id = 2 } # Phase 122: alias for log (uses println internally)
+println = { method_id = 1 } # Phase 122.5: alias for log (same method_id as log)
```
**変更点**:
- `println` の `method_id` を `2` から `1` に修正
- コメントを更新して意図を明確化
## 検証方法
### 1. 構文確認
```bash
cd /home/tomoaki/git/hakorune-selfhost
# toml パーサー確認
cargo build --release 2>&1 | grep -i toml
```
### 2. 機能確認
修正後、Phase 120 の representative tests を再実行:
```bash
# ConsoleBox.println が正常に動作することを確認
NYASH_JOINIR_STRICT=1 ./target/release/nyash apps/tests/peek_expr_block.hako
NYASH_JOINIR_STRICT=1 ./target/release/nyash apps/tests/loop_min_while.hako
NYASH_JOINIR_STRICT=1 ./target/release/nyash apps/tests/esc_dirname_smoke.hako
```
すべて成功するはず（Phase 122 で既に動作確認済み）。
### 3. 追加検証（推奨）
```bash
# プラグイン側の method_id 処理を確認（libnyash_console_plugin.so）
strings /path/to/libnyash_console_plugin.so | grep -i println
```
## 実装者への注意
- **影響範囲**: nyash.toml のみ（1行修正）
- **ビルド**: 不要（toml は実行時に読み込まれる）
- **テスト**: 既存テストで十分（Phase 120 representative tests が確認）
- **ロールバック**: 簡単（1行戻すだけ）
## 所要時間
**5分程度** - 単純な設定修正
## 完了後の次のステップ
Phase 122.5 修正完了後、以下の Phase 123 (ConsoleBox WASM/非WASM コード統一) に進む。
---
**Phase 122.5 の位置付け**:
- Phase 122 の実装完了後に発見された品質改善の第1段
- 本来は Phase 122 に含めるべきだったが、実装後の品質レビューで発見
- Phase 122 の機能は既に動作済み（この修正は完全性の向上）
Status: Historical

431
docs/archive/phases/phase-106-156/phase122_consolebox_println_unification.md Normal file
View File

@ -0,0 +1,431 @@
# Phase 122: ConsoleBox.println / log の統一（JSON v0 共通ルート）
⚠️ **Note**: このドキュメントは Phase 122 の実装記録です。
統合的なガイドは [ConsoleBox 完全ガイド](consolebox_complete_guide.md) をご参照ください。
## 0. ゴール
- .hako 側の `ConsoleBox.println(...)` と、VM/Rust 側の `ConsoleBox.log(...)` を **構造的に同じルートに揃える**
- selfhost Stage-3 → JSON v0 → Rust VM の経路でも:
- `ConsoleBox.println` がエラーにならず
- 内部では `ConsoleBox.log` と同じスロットに正規化される
- **代表ケース** `apps/tests/esc_dirname_smoke.hako` を JoinIR Strict + selfhost 経路で green にする
---
## 1. スコープと非スコープ
### スコープ（今回やること）
1. **現状分析ドキュメント作成**: ConsoleBox の「言語API」と「VM実装API」のズレを整理
2. **TypeRegistry 修正**: `println` を `log` のエイリアス（slot 400）として追加
3. **ドキュメント更新**: console_box.rs / hako_logging_design.md / logging_policy.md
4. **selfhost 再検証**: esc_dirname_smoke.hako が selfhost Stage-3 + JoinIR Strict で通ることを確認
5. **hako_check 影響確認**: ConsoleBox.println の alias 化が hako_check に影響しないことを確認
### 非スコープ（今回はやらない）
- **ConsoleService 統合**: ConsoleBox と ConsoleService の統合（Phase 123+ で検討）
- **LoggerBox 統合**: ConsoleBox と LoggerBox の統合（Phase 123+ で検討）
- **パフォーマンス最適化**: println/log の実行速度改善（Phase 124+ で検討）
---
## 2. 設計方針（どこで揃えるか）
### 2.1 言語レベルの正解
**ConsoleBox の「公式 API」定義**:
| メソッド | 引数 | 役割 | VM slot |
|---------|-----|------|---------|
| `log(message)` | 1 | コアメソッド（標準出力） | 400 |
| `warn(message)` | 1 | 警告メッセージ | 401 |
| `error(message)` | 1 | エラーメッセージ | 402 |
| `clear()` | 0 | コンソールクリア | 403 |
| **`println(message)`** | 1 | **`log` のエイリアス（ユーザー向け sugar）** | **400** |
**設計決定**:
- `println` は `log` の完全なエイリアス
- ユーザー向けは `println` で書いても `log` で書いてもよい
- 内部実装上は同じ slot 400 を使う
### 2.2 正規化ポイント（どこで println→log を吸収するか）
**✅ Option A: type_registry.rs の CONSOLE_METHODS に println を追加** (採用)
**理由**:
- VM の TypeRegistry で alias を張るだけで、全経路に適用される
- JSON v0 / selfhost / 通常VM どの経路でも同じスロットを見る
- 正規化ポイントが一箇所に固定できる（保守性が高い）
**実装**:
```rust
const CONSOLE_METHODS: &[MethodEntry] = &[
MethodEntry { name: "log", arity: 1, slot: 400 },
MethodEntry { name: "warn", arity: 1, slot: 401 },
MethodEntry { name: "error", arity: 1, slot: 402 },
MethodEntry { name: "clear", arity: 0, slot: 403 },
// Phase 122: println は log のエイリアス
MethodEntry { name: "println", arity: 1, slot: 400 },
];
```
**❌ Option B: MIR/JSON 生成時に "println" → "log" に書き換え** (却下)
**理由**:
- Bridge が増えたときに再び散る
- 正規化ポイントが複数箇所になる（保守性が低い）
---
## 3. Task 1: 現状の API 実態を docs に固定
### 3.1 実装内容
**ファイル**: `docs/development/current/main/phase122_consolebox_println_unification.md`（本ドキュメント）
**記載内容**:
#### 現状の整理
**Phase 120 での観測結果**:
- `apps/tests/esc_dirname_smoke.hako` が selfhost Stage-3 + JoinIR Strict 経路で失敗
- エラーメッセージ: `Unknown method 'println' on ConsoleBox`
**原因分析**:
| 層 | 現状 | 問題 |
|----|------|------|
| **.hako サンプル** | `console.println("...")` 前提 | ✅ ユーザー向け API |
| **src/boxes/console_box.rs** | `log/warn/error/clear` のみ実装 | ❌ `println` 未実装 |
| **type_registry.rs** | `CONSOLE_METHODS` に `log/warn/error/clear` のみ | ❌ `println` 未登録 |
| **selfhost Stage-3 経路** | JSON v0 → VM で `println` を解決できない | ❌ エラー発生 |
**設計決定**:
- `ConsoleBox.println` を「`log` と同じ意味のユーザー向け sugar」と定義
- VM の TypeRegistry で `println` → slot 400（`log` と同じ）に正規化
- すべての経路（JSON v0 / selfhost / 通常VM）で一貫性を保つ
---
## 4. Task 2: TypeRegistry に println を alias として追加
### 4.1 実装内容
**ファイル**: `src/runtime/type_registry.rs`（修正）
**修正箇所**:
```rust
const CONSOLE_METHODS: &[MethodEntry] = &[
MethodEntry { name: "log", arity: 1, slot: 400 },
MethodEntry { name: "warn", arity: 1, slot: 401 },
MethodEntry { name: "error", arity: 1, slot: 402 },
MethodEntry { name: "clear", arity: 0, slot: 403 },
// Phase 122: println は log のエイリアス
// JSON v0/selfhost が println を吐いても log と同じスロットを使うための alias
MethodEntry { name: "println", arity: 1, slot: 400 },
];
```
**コメント追加**:
- 「`println` は `log` の別名。JSON v0/selfhost が `println` を吐いても `log` と同じスロットを使うための alias」
### 4.2 core_boxes_design.md への追記
**ファイル**: `docs/development/current/main/core_boxes_design.md`（修正）
**追記内容**:
```markdown
## Section 18: Phase 122 - ConsoleBox.println / log 統一
### 概要
ConsoleBox の `println` メソッドを `log` のエイリアスとして VM レベルで正規化。
すべての経路（JSON v0 / selfhost / 通常VM）で一貫性を保つ。
### 設計
- **言語レベル**: `println(message)` は `log(message)` の完全なエイリアス
- **VM レベル**: `println` は slot 400（`log` と同じ）に正規化
- **正規化ポイント**: `src/runtime/type_registry.rs` の `CONSOLE_METHODS`
### 実装完了日
**Phase 122 実装完了日**: 2025-12-04（予定）
```
---
## 5. Task 3: ConsoleBox 実装ドキュメントの調整
### 5.1 実装内容
#### 5.1.1 console_box.rs のドキュメント更新
**ファイル**: `src/boxes/console_box.rs`（修正）
**修正箇所**:
```rust
//! ConsoleBox - コンソール出力ボックス
//!
//! ## 利用可能メソッド
//!
//! - `log(message)`: 標準出力にメッセージを出力
//! - `println(message)`: `log` のエイリアス（ユーザー向け sugar）
//! - `warn(message)`: 警告メッセージを出力
//! - `error(message)`: エラーメッセージを出力
//! - `clear()`: コンソールをクリア
//!
//! ## Phase 122: println / log の統一
//!
//! `println` は `log` の完全なエイリアスです。内部的には同じ slot 400 を使用します。
//! ユーザーコードでは `println` を使用することを推奨しますが、`log` も同様に動作します。
```
**実装オプション**:
**Option 1: Rust 側でラッパを追加**（完全統一）
```rust
impl ConsoleBox {
/// Phase 122: println は log の別名
pub fn println(&self, message: &str) {
self.log(message);
}
}
```
**Option 2: VM の alias に任せる**（最小実装）
- Rust 側では実装せず、VM の TypeRegistry に任せる
- docs のみで「`println` は `log` の別名」と明記
**推奨**: Option 1（Rust 側でもラッパを追加）
- 理由: Rust から直接 ConsoleBox を使う場合にも対応できる
#### 5.1.2 hako_logging_design.md への追記
**ファイル**: `docs/development/current/main/hako_logging_design.md`（修正）
**追記内容**:
```markdown
## ConsoleBox の使い方（Phase 122 更新）
### 基本パターン
```nyash
local console = new ConsoleBox()
console.println("Hello") // 内部的には log と同じスロット
console.log("World") // println と同じ動作
```
### ConsoleBox vs LoggerBox vs ConsoleService
- **ConsoleBox**: ユーザーコードで直接使用（`println` / `log`）
- **LoggerBox**: 構造化ログ・ログレベル管理
- **ConsoleService**: CLI/システム内部での出力（Ring0 経由）
### Phase 122 での統一
- `ConsoleBox.println` は `ConsoleBox.log` の完全なエイリアス
- VM の TypeRegistry で slot 400 に正規化される
- すべての経路（JSON v0 / selfhost / 通常VM）で一貫性を保つ
```
#### 5.1.3 logging_policy.md への追記
**ファイル**: `docs/development/current/main/logging_policy.md`（修正）
**追記内容**:
```markdown
## Phase 122: ConsoleBox.println / log の統一
### 使い分けガイドライン
| 用途 | 推奨 API | 理由 |
|------|---------|------|
| **selfhost / CLI** | `ConsoleService` / `console_println!` | Ring0 経由で安定 |
| **ユーザーコード** | `ConsoleBox.println` | ユーザー向け sugar |
| **内部実装** | `ConsoleBox.log` | VM レベルでは同じ |
### 正規化ルール
- `ConsoleBox.println` は VM の TypeRegistry で `ConsoleBox.log`（slot 400）に正規化される
- JSON v0 / selfhost / 通常VM のすべての経路で同じ動作を保証
- Rust から直接使用する場合も `println` / `log` の両方が使用可能
```
---
## 6. Task 4: selfhost / esc_dirname_smoke 再検証
### 6.1 実装内容
**ファイル/コマンド**:
- `tools/smokes/v2/profiles/integration/selfhost/phase120_stable_paths.sh`
- `docs/development/current/main/phase120_baseline_results.md`
**実行コマンド**:
```bash
# JoinIR Strict モードで selfhost 経路を再検証
NYASH_FEATURES=stage3 \
NYASH_USE_NY_COMPILER=1 \
NYASH_NY_COMPILER_EMIT_ONLY=1 \
NYASH_SELFHOST_KEEP_RAW=1 \
NYASH_JOINIR_STRICT=1 \
./tools/smokes/v2/profiles/integration/selfhost/phase120_stable_paths.sh
```
### 6.2 期待結果
| テストケース | Phase 120 | Phase 122（期待） |
|-------------|-----------|------------------|
| `peek_expr_block.hako` | ✅ 成功 | ✅ 成功 |
| `loop_min_while.hako` | ✅ 成功 | ✅ 成功 |
| `esc_dirname_smoke.hako` | ❌ `Unknown method 'println'` | ✅ **成功** |
**esc_dirname_smoke.hako の期待動作**:
- エラー `Unknown method 'println' on ConsoleBox` が消える
- 出力として esc_json / dirname の結果が正しく表示される
### 6.3 ドキュメント更新
**phase120_baseline_results.md への追記**:
```markdown
### 3. esc_dirname_smoke.hako
| 項目 | Phase 120 結果 | Phase 122 結果 |
|------|---------------|---------------|
| **実行結果** | ❌ エラー | ✅ **成功** |
| **エラーメッセージ** | Unknown method 'println' on ConsoleBox | （なし） |
| **修正内容** | - | Phase 122: TypeRegistry に println alias 追加 |
| **備考** | ConsoleBox.println 未実装 | println → log に正規化 |
```
**CURRENT_TASK.md への追記**:
```markdown
### 🎯 Phase 122: ConsoleBox.println / log 統一（完了）
- ✅ 現状分析ドキュメント作成: phase122_consolebox_println_unification.md
- ✅ TypeRegistry 修正: println を log のエイリアス（slot 400）として追加
- ✅ ConsoleBox 実装ドキュメント調整: console_box.rs / hako_logging_design.md / logging_policy.md
- ✅ selfhost 再検証: esc_dirname_smoke.hako が selfhost Stage-3 + JoinIR Strict で通ることを確認
- ✅ hako_check 影響確認: ConsoleBox.println の alias 化が hako_check に影響しないことを確認
**Phase 120 の問題解決**:
- ✅ esc_dirname_smoke.hako の `Unknown method 'println'` エラー解消
**次のステップ**: Phase 123（ConsoleService / LoggerBox 統合検討）
```
---
## 7. Task 5: hako_check / JoinIR に影響がないことを確認
### 7.1 実装内容
**ファイル**: `docs/development/current/main/phase121_hako_check_joinir_design.md`（確認・追記）
**確認事項**:
1. **hako_check が ConsoleBox を使用しているか確認**:
```bash
rg "ConsoleBox" tools/hako_check/ --type hako
rg "println\|log" tools/hako_check/ --type hako
```
2. **確認結果に応じて対応**:
**ケース A: hako_check が ConsoleBox を使用している**
- `phase121_hako_check_joinir_design.md` に追記:
```markdown
## Phase 122 での影響
- ConsoleBox.println は log に正規化される（TypeRegistry レベル）
- hako_check のログ出力設計: ConsoleBox.println / log の両方が使用可能
- 動作に影響なし（VM の alias 機能で自動対応）
```
**ケース B: hako_check が ConsoleBox を使用していない**
- `phase121_hako_check_joinir_design.md` に追記:
```markdown
## Phase 122 での影響
- hako_check は ConsoleBox を直接使用していない
- ConsoleBox.println の alias 化は hako_check に影響なし
```
### 7.2 追加確認
**MirBuilder / JoinIR Lowering への影響確認**:
```bash
# MirBuilder が ConsoleBox.println を特別扱いしていないか確認
rg "println" src/mir/builder/ --type rust
# JoinIR Lowering への影響確認
rg "println" src/mir/join_ir/ --type rust
```
**期待結果**: どちらも特別扱いしていない（TypeRegistry に任せる設計）
---
## 8. 完成チェックリスト（Phase 122）
- [ ] phase122_consolebox_println_unification.md に現状と設計がまとまっている
- [ ] type_registry.rs の CONSOLE_METHODS に println alias が追加されている
- [ ] console_box.rs に println メソッドのラッパが追加されている（Option 1 採用時）
- [ ] console_box.rs / hako_logging_design.md / logging_policy.md に ConsoleBox.println / log の関係が明記されている
- [ ] apps/tests/esc_dirname_smoke.hako が selfhost Stage-3 + JoinIR Strict 経路で通る（旧エラーメッセージが消える）
- [ ] phase120_baseline_results.md が更新され、esc_dirname_smoke.hako の結果が ❌ → ✅ に変わっている
- [ ] CURRENT_TASK.md が更新され、「ConsoleBox.println 問題 resolved」となっている
- [ ] hako_check への影響が確認され、phase121_hako_check_joinir_design.md に記録されている
- [ ] ビルド・テスト全 PASS（cargo build --release && cargo test --release）
---
## 9. 設計原則（Phase 122 で確立）
### Alias First
```
【Phase 122 の哲学】
複数の名前を持つ API は、VM レベルで alias に統一する
Flow:
ユーザーコード: ConsoleBox.println("...")
↓
VM TypeRegistry: println → slot 400（log と同じ）
↓
ConsoleBox 実装: log の実装が実行される
↓
出力: 標準出力にメッセージ表示
```
### 正規化ポイントの一元化
**重要な約束**:
- **alias は TypeRegistry で管理**: VM レベルで一元管理
- **MirBuilder は関与しない**: 特別扱いなし
- **すべての経路で一貫**: JSON v0 / selfhost / 通常VM
### Phase 120 との連携
**Phase 120 の成果を活用**:
- Phase 120: selfhost 経路のベースライン確立 → 問題発見
- Phase 122: 問題の根本解決（TypeRegistry レベル） → ベースライン改善
- Phase 123+: 追加機能の統合検討
---
**Phase 122 指示書完成日**: 2025-12-04（Phase 120-121 完了直後）
Status: Historical

494
docs/archive/phases/phase-106-156/phase123_consolebox_code_unification.md Normal file
View File

@ -0,0 +1,494 @@
# Phase 123: ConsoleBox WASM/非WASM コード統一化
⚠️ **Note**: このドキュメントは Phase 123 の実装記録です。
統合的なガイドは [ConsoleBox 完全ガイド](consolebox_complete_guide.md) をご参照ください。
## 目的
`src/boxes/console_box.rs` で WASM/非WASM 環境で分離・重複している実装をマクロを使用して統一し、保守性と可読性を向上させる。
現在 ~245行の実装を ~180行程度に削減（~25%削減見込み）
## 現在の問題
### コード重複の内容
**src/boxes/console_box.rs の現状**:
```
📦 WASM版（行 59-144）
├─ struct ConsoleBox (66-71)
├─ impl ConsoleBox (66-96)
│ ├─ new()
│ ├─ log()
│ ├─ println()
│ ├─ warn()
│ ├─ error()
│ └─ clear()
├─ impl BoxCore (100-120)
└─ impl NyashBox (123-144)
📦 非WASM版（行 147-229） ← 全く同じ構造！
├─ struct ConsoleBox (148-151)
├─ impl ConsoleBox (154-182)
│ ├─ new()
│ ├─ log()
│ ├─ println()
│ ├─ warn()
│ ├─ error()
│ └─ clear()
├─ impl BoxCore (185-205)
└─ impl NyashBox (208-229)
📦 Display（行 232-244）
├─ WASM版 Display impl (233-237)
└─ 非WASM版 Display impl (240-244)
```
### 重複の詳細
#### 1. **メソッド実装の分岐**（log, warn, error, clear）
```rust
// WASM版
pub fn log(&self, message: &str) {
web_sys::console::log_1(&message.into());
}
// 非WASM版
pub fn log(&self, message: &str) {
println!("[Console LOG] {}", message);
}
```
**問題**: 実装は異なるが、構造は完全に同じ
#### 2. **println の重複実装**
両方のバージョンで同じ実装:
```rust
pub fn println(&self, message: &str) {
self.log(message); // 常に log に委譲
}
```
**改善機会**: マクロで1度だけ定義
#### 3. **BoxCore の完全な重複**
```rust
// WASM版 impl BoxCore (100-120)
fn box_id(&self) -> u64 { self.base.id }
fn parent_type_id(&self) -> Option<std::any::TypeId> { self.base.parent_type_id }
fn fmt_box(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
write!(f, "[ConsoleBox - Browser Console Interface]")
}
// ... as_any, as_any_mut
// 非WASM版 impl BoxCore (185-205)
fn box_id(&self) -> u64 { self.base.id }
fn parent_type_id(&self) -> Option<std::any::TypeId> { self.base.parent_type_id }
fn fmt_box(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
write!(f, "[ConsoleBox - Mock Implementation]") // ← ここだけ異なる！
}
// ... as_any, as_any_mut
```
**改善機会**: `fmt_box` のメッセージのみを条件付きにすれば共通化できる
#### 4. **NyashBox の完全な重複**
```rust
// 両バージョンで完全に同じ
impl NyashBox for ConsoleBox {
fn to_string_box(&self) -> StringBox { ... }
fn equals(&self, other: &dyn NyashBox) -> BoolBox { ... }
fn type_name(&self) -> &'static str { "ConsoleBox" }
fn clone_box(&self) -> Box<dyn NyashBox> { ... }
fn share_box(&self) -> Box<dyn NyashBox> { ... }
}
```
**改善機会**: 完全に共通化可能
#### 5. **Display の重複**
```rust
// WASM版
impl Display for ConsoleBox {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
self.fmt_box(f)
}
}
// 非WASM版 - 完全に同じ
impl Display for ConsoleBox {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
self.fmt_box(f)
}
}
```
**改善機会**: 両バージョンを削除して1つに統合
## 実装戦略
### 戦略 A: マクロベースの統一（推奨）
マクロ `macro_rules! define_console_methods!` を使用してメソッド実装を統一化
```rust
// マクロ定義
macro_rules! define_console_methods {
(
log: $log_impl:expr,
warn: $warn_impl:expr,
error: $error_impl:expr,
clear: $clear_impl:expr
) => {
impl ConsoleBox {
pub fn new() -> Self {
Self {
base: BoxBase::new(),
}
}
pub fn log(&self, message: &str) {
$log_impl(self, message);
}
pub fn println(&self, message: &str) {
self.log(message); // 共通実装
}
pub fn warn(&self, message: &str) {
$warn_impl(self, message);
}
pub fn error(&self, message: &str) {
$error_impl(self, message);
}
pub fn clear(&self) {
$clear_impl(self);
}
}
};
}
// WASM環境での使用
#[cfg(target_arch = "wasm32")]
define_console_methods!(
log: |s: &ConsoleBox, msg: &str| { web_sys::console::log_1(&msg.into()); },
warn: |s: &ConsoleBox, msg: &str| { web_sys::console::warn_1(&msg.into()); },
error: |s: &ConsoleBox, msg: &str| { web_sys::console::error_1(&msg.into()); },
clear: |s: &ConsoleBox| { web_sys::console::clear(); }
);
// 非WASM環境での使用
#[cfg(not(target_arch = "wasm32"))]
define_console_methods!(
log: |s: &ConsoleBox, msg: &str| { println!("[Console LOG] {}", msg); },
warn: |s: &ConsoleBox, msg: &str| { println!("[Console WARN] {}", msg); },
error: |s: &ConsoleBox, msg: &str| { println!("[Console ERROR] {}", msg); },
clear: |s: &ConsoleBox| { println!("[Console CLEAR]"); }
);
```
### 戦略 B: trait オブジェクトによる実装（代替案）
```rust
trait ConsolePlatform {
fn log(&self, message: &str);
fn warn(&self, message: &str);
fn error(&self, message: &str);
fn clear(&self);
}
// WASM版
#[cfg(target_arch = "wasm32")]
struct WasmPlatform;
#[cfg(target_arch = "wasm32")]
impl ConsolePlatform for WasmPlatform {
// WASM実装
}
// 非WASM版
#[cfg(not(target_arch = "wasm32"))]
struct MockPlatform;
// ConsoleBox はプラットフォームを集約
struct ConsoleBox {
base: BoxBase,
platform: Box<dyn ConsolePlatform>, // ← 委譲
}
```
**注記**: 本フェーズではマクロベースを推奨（シンプルで効果的）
## 実装ステップ
### ステップ 1: マクロ定義の作成
新しいマクロを定義:
```rust
// 行 54 から 57 の use 宣言直後に挿入
/// ConsoleBox メソッド実装マクロ
/// WASM/非WASM環境で異なるメソッド実装を統一化
macro_rules! define_console_impl {
(
log: $log_impl:expr,
warn: $warn_impl:expr,
error: $error_impl:expr,
clear: $clear_impl:expr,
fmt_desc: $fmt_desc:expr
) => {
impl ConsoleBox {
pub fn new() -> Self {
Self {
base: BoxBase::new(),
}
}
pub fn log(&self, message: &str) {
$log_impl(message);
}
pub fn println(&self, message: &str) {
self.log(message);
}
pub fn warn(&self, message: &str) {
$warn_impl(message);
}
pub fn error(&self, message: &str) {
$error_impl(message);
}
pub fn clear(&self) {
$clear_impl();
}
}
impl BoxCore for ConsoleBox {
fn box_id(&self) -> u64 {
self.base.id
}
fn parent_type_id(&self) -> Option<std::any::TypeId> {
self.base.parent_type_id
}
fn fmt_box(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
write!(f, "{}", $fmt_desc)
}
fn as_any(&self) -> &dyn Any {
self
}
fn as_any_mut(&mut self) -> &mut dyn Any {
self
}
}
impl NyashBox for ConsoleBox {
fn to_string_box(&self) -> StringBox {
StringBox::new($fmt_desc)
}
fn equals(&self, other: &dyn NyashBox) -> BoolBox {
BoolBox::new(other.as_any().is::<ConsoleBox>())
}
fn type_name(&self) -> &'static str {
"ConsoleBox"
}
fn clone_box(&self) -> Box<dyn NyashBox> {
Box::new(self.clone())
}
fn share_box(&self) -> Box<dyn NyashBox> {
self.clone_box()
}
}
impl Display for ConsoleBox {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
self.fmt_box(f)
}
}
};
}
```
### ステップ 2: WASM版の実装
```rust
#[cfg(target_arch = "wasm32")]
#[derive(Debug, Clone)]
pub struct ConsoleBox {
base: BoxBase,
}
#[cfg(target_arch = "wasm32")]
define_console_impl!(
log: |msg: &str| { web_sys::console::log_1(&msg.into()); },
warn: |msg: &str| { web_sys::console::warn_1(&msg.into()); },
error: |msg: &str| { web_sys::console::error_1(&msg.into()); },
clear: || { web_sys::console::clear(); },
fmt_desc: "[ConsoleBox - Browser Console Interface]"
);
```
### ステップ 3: 非WASM版の実装
```rust
#[cfg(not(target_arch = "wasm32"))]
#[derive(Debug, Clone)]
pub struct ConsoleBox {
base: BoxBase,
}
#[cfg(not(target_arch = "wasm32"))]
define_console_impl!(
log: |msg: &str| { println!("[Console LOG] {}", msg); },
warn: |msg: &str| { println!("[Console WARN] {}", msg); },
error: |msg: &str| { println!("[Console ERROR] {}", msg); },
clear: || { println!("[Console CLEAR]"); },
fmt_desc: "[ConsoleBox - Mock Implementation]"
);
```
### ステップ 4: 検証
```bash
# コンパイル確認
cargo build --release 2>&1 | grep -i console
# 機能確認
NYASH_JOINIR_STRICT=1 ./target/release/nyash apps/tests/peek_expr_block.hako
NYASH_JOINIR_STRICT=1 ./target/release/nyash apps/tests/loop_min_while.hako
NYASH_JOINIR_STRICT=1 ./target/release/nyash apps/tests/esc_dirname_smoke.hako
# WASM ビルド確認（もし WASM 環境が整っていれば）
cargo build --release --target wasm32-unknown-unknown 2>&1 | grep -i console
```
## 期待される効果
### コード削減
- **削減行数**: ~65行（25%削減）
- WASM版の重複実装: ~30行削除
- 非WASM版の重複実装: ~30行削除
- Display 重複: ~10行削除
- マクロ定義による新規追加: ~15行
- **最終サイズ**: 245行 → 180行程度
### 保守性向上
- メソッド実装を1箇所で管理
- WASM/非WASM の差分が明確
- println の一元化実装
- BoxCore/NyashBox の重複削除
### 可読性向上
- マクロの引数で環境別の違いが明示的
- println が log に委譲される流れが可視化
- fmt_desc で環境別の説明文が分離
## 実装上の注意
### 1. マクロの引数形式
```rust
// ✅ 正しい
define_console_impl!(
log: |msg: &str| { /* 実装 */ },
// ...
);
// ❌ 避けるべき
define_console_impl!(
log = |msg: &str| { /* 実装 */ }, // = は使わない
);
```
### 2. println のクロージャ
```rust
// ❌ self が必要ない場合でも self を渡す
println: |msg: &str| { self.log(msg); } // self は available ではない
// ✅ 正しい（log に委譲は ConsoleBox メソッド内で実装）
// マクロ内で `pub fn println(&self, message: &str) { self.log(message); }` を生成
```
### 3. Display 統合
現在の実装:
```rust
#[cfg(target_arch = "wasm32")]
impl Display for ConsoleBox { ... }
#[cfg(not(target_arch = "wasm32"))]
impl Display for ConsoleBox { ... }
```
マクロ後は両 cfg ブロック内で定義されるため、`impl Display` は削除可能。
## ロールバック計画
修正後に問題が発生した場合：
```bash
# 修正前のバージョンに戻す
git checkout HEAD~ -- src/boxes/console_box.rs
# または具体的な commit hash を指定
git show <commit-hash>:src/boxes/console_box.rs > src/boxes/console_box.rs
```
## テスト戦略
### ユニットテスト（新規作成不要）
現在、ConsoleBox は直接テストしていない（プラグイン経由）。
### 統合テスト
既存の Phase 120 representative tests が十分：
```bash
# すべてが成功することを確認
NYASH_JOINIR_STRICT=1 ./target/release/nyash apps/tests/esc_dirname_smoke.hako
# 出力: [Console LOG] dir1/dir2
```
## 所要時間
**2時間程度**
- マクロ設計と定義: 30分
- WASM/非WASM 実装: 45分
- 検証とテスト: 30分
- ドキュメント更新: 15分
## 完了後の次のステップ
Phase 124: VM Method Dispatch 統一化（4時間）
---
**記録**:
- Phase 122.5: nyash.toml method_id 修正 ✅ 完了
- Phase 123: ConsoleBox WASM/非WASM 統一化 ← **現在のフェーズ**
- Phase 124: VM Method Dispatch 統一化（予定）
- Phase 125: 削除：deprecated builtin ConsoleBox（予定）
- Phase 126: ドキュメント統合（予定）
Status: Historical

361
docs/archive/phases/phase-106-156/phase123_hako_check_joinir_implementation.md Normal file
View File

@ -0,0 +1,361 @@
# Phase 123 proper: hako_check JoinIR 実装（環境変数選択可能化）
## 🎯 ゴール
hako_check を **JoinIR 経路でも動かせる** ように拡張し、環境変数で以下の2つのルートを切り替え可能にする：
```
NYASH_HAKO_CHECK_JOINIR=0 (or unset) → 既存レガシー経路
NYASH_HAKO_CHECK_JOINIR=1 → JoinIR 経路（If/Loop を JoinIR lowering 経由に）
```
これにより、Phase 121 で設計した JoinIR 統合を hako_check でも実現し、Phase 124 での JoinIR デフォルト化への準備を整える。
## 📋 スコープ（やること・やらないこと）
### ✅ やること
1. **環境変数フラグ導入**: `NYASH_HAKO_CHECK_JOINIR` のヘルパー関数作成
2. **hako_check ランナー修正**: JoinIR 経路スイッチの実装
3. **代表ケース検証**: Phase 121 で洗ったケースで両経路を確認
4. **ドキュメント更新**: 設計・実装結果・Known Limitations を記録
### ❌ やらないこと
- JoinIR をいきなりデフォルト化（Phase 124 の役目）
- JoinIR Lowerer 自体のロジック変更
- hako_check .hako スクリプトの API 変更（呼び出し仕様は現状維持）
## 🏗️ 実装の 4 つのタスク
### Task 1: 環境変数フラグの追加（Config 層）
**ファイル**:
- `src/config/env/hako_check.rs`（新規 or 既存拡張）
- `docs/reference/environment-variables.md`（更新）
**実装内容**:
```rust
// src/config/env/hako_check.rs
/// hako_check で JoinIR 経路を使用するかどうか判定
///
/// 環境変数 NYASH_HAKO_CHECK_JOINIR で制御：
/// - "1" or "true": JoinIR 経路を使用
/// - その他: レガシー経路を使用（デフォルト）
pub fn hako_check_joinir_enabled() -> bool {
matches!(
std::env::var("NYASH_HAKO_CHECK_JOINIR").as_deref(),
Ok("1") | Ok("true")
)
}
#[cfg(test)]
mod tests {
#[test]
fn test_hako_check_joinir_flag_parsing() {
// 環境変数パースのテスト
}
}
```
**ドキュメント更新** (`docs/reference/environment-variables.md`):
```markdown
### NYASH_HAKO_CHECK_JOINIR
**用途**: hako_check で JoinIR lowering 経路を使用
**値**:
- `1` or `true`: JoinIR 経路を使用（Phase 123+）
- その他（未設定含む）: レガシー経路を使用
**デフォルト**: `0`（レガシー経路）
**例**:
```bash
# JoinIR 経路で hako_check 実行
NYASH_HAKO_CHECK_JOINIR=1 ./target/release/nyash tools/hako_check/cli.hako
```
**参照**: [Phase 123 hako_check JoinIR 実装](../main/phase123_hako_check_joinir_implementation.md)
```
### Task 2: hako_check 実装に JoinIR スイッチを差し込む
**ファイル候補**:
- `src/runner/hako_check_runner.rs`（or 類似のメインランナー）
- `src/mir/builder.rs`（MIR 構築時の分岐）
- Phase 121 docs の設計図を参照して確認
**実装方針**:
#### Step 2A: ランナー側でフラグを読み込む
```rust
// src/runner/hako_check_runner.rs（例）
use crate::config::env;
pub fn run_hako_check(
input_path: &str,
// ... その他の引数
) -> Result<HakoCheckResult, Error> {
// フラグを読み込む
let use_joinir = env::hako_check::hako_check_joinir_enabled();
eprintln!("[hako_check] Using JoinIR path: {}", use_joinir);
// フラグに応じて経路を分ける
if use_joinir {
run_hako_check_with_joinir(input_path, /* ... */)
} else {
run_hako_check_legacy(input_path, /* ... */)
}
}
```
#### Step 2B: If/Loop lowering を JoinIR に乗せる
**現在の処理フロー（レガシー）**:
```
.hako → Tokenize → Parse → MIR Builder (legacy if/loop) → VM Interpret
```
**目標フロー（JoinIR）**:
```
.hako → Tokenize → Parse → MIR Builder → JoinIR Lowerer (if/loop) → MIR → VM Interpret
```
**実装例**:
```rust
// src/mir/builder.rs 内（MIR 構築後）
pub fn lower_if_and_loop_statements(
mir: &mut MirFunction,
use_joinir: bool,
) -> Result<(), Error> {
if use_joinir {
// JoinIR Lowerer を使用
let mut lowerer = JoinIRIfLoopLowerer::new();
lowerer.lower(mir)?;
} else {
// レガシー lowering（既存ロジック）
legacy_lower_if_and_loop(mir)?;
}
Ok(())
}
```
#### Step 2C: 既存の JoinIR Lowerer を再利用
⚠️ **重要**: 新しいロジックは書かず、既存の以下を再利用：
- `src/mir/join_ir/lowering/if_select.rs`（If lowering）
- `src/mir/join_ir/lowering/loop_form.rs`（Loop lowering）
- これらを hako_check パイプラインに「差し込む」だけ
### Task 3: 代表ケースで JoinIR 実行を確認
**対象ケース** (Phase 121 docs から):
```
1. simple_if.hako - 単純な if 文
2. nested_if.hako - ネストされた if
3. while_loop.hako - while ループ
4. nested_while.hako - ネストされたループ
5. if_in_loop.hako - if in loop
6. loop_in_if.hako - loop in if
```
**テストスクリプト作成** (`tools/smokes/v2/profiles/integration/hako_check_joinir.sh`):
```bash
#!/bin/bash
# Phase 123: hako_check JoinIR 実装テスト
set -e
PROFILE_NAME="hako_check_joinir"
# test cases
test_cases=(
"simple_if.hako"
"nested_if.hako"
"while_loop.hako"
"nested_while.hako"
"if_in_loop.hako"
"loop_in_if.hako"
)
echo "=== Testing hako_check with JoinIR OFF (Legacy) ==="
for case in "${test_cases[@]}"; do
NYASH_HAKO_CHECK_JOINIR=0 ./target/release/nyash "test_cases/$case"
echo "✓ $case (legacy)"
done
echo ""
echo "=== Testing hako_check with JoinIR ON ==="
for case in "${test_cases[@]}"; do
NYASH_HAKO_CHECK_JOINIR=1 ./target/release/nyash "test_cases/$case"
echo "✓ $case (joinir)"
done
```
**確認内容**:
1. ✅ **JoinIR OFF**: すべてが現在どおり PASS
2. ✅ **JoinIR ON**: Phase 121 で想定した「JoinIR で食えるパターン」は green に
3. 📝 差分あれば Phase 123 docs の "Known Limitations" に記録
### Task 4: ドキュメント・CURRENT_TASK 更新
**ファイル**:
- `docs/development/current/main/phase121_hako_check_joinir_design.md`
- `docs/development/current/main/hako_check_design.md`
- `CURRENT_TASK.md`
#### 更新内容
**phase121_hako_check_joinir_design.md に追加**:
```markdown
## Phase 123実装完了セクション
### 環境変数フラグ導入
- NYASH_HAKO_CHECK_JOINIR で 2 つのルートを切り替え可能
### JoinIR スイッチ実装
- hako_check ランナーが use_joinir フラグを受け取り、処理を分岐
- 既存の JoinIR Lowerer を再利用
### 代表ケース検証結果
- legacy: N/N cases PASS
- joinir: N/N cases PASS
- Known Limitations: [あれば記載]
```
**hako_check_design.md に追加**:
```markdown
## 実行フロー図（2 パス）
### Legacy パス（NYASH_HAKO_CHECK_JOINIR=0 or unset）
```
.hako file
↓
Tokenize / Parse
↓
MIR Builder (legacy if/loop lowering)
↓
VM Interpreter
↓
Check Result
```
### JoinIR パス（NYASH_HAKO_CHECK_JOINIR=1）
```
.hako file
↓
Tokenize / Parse
↓
MIR Builder
↓
JoinIR Lowerer (if/loop → PHI)
↓
VM Interpreter
↓
Check Result
```
```
**CURRENT_TASK.md に追加**:
```markdown
### Phase 123 proper: hako_check JoinIR 実装 ✅
**完了内容**:
- NYASH_HAKO_CHECK_JOINIR 環境変数フラグ導入
- hako_check ランナーに JoinIR スイッチ実装
- 代表 6 ケースで両経路テスト実施
- ドキュメント更新完了
**テスト結果**:
- Legacy: 6/6 PASS
- JoinIR: 6/6 PASS
**次フェーズ**: Phase 124 - JoinIR デフォルト化＆レガシー経路削除
```
## 🔍 詳細実装ガイド
### Phase 121 との連携ポイント
Phase 121 で以下が既に設計・分析済み：
```
hako_check_design.md（セクション 10-12）
├─ If/Loop の処理フロー
├─ JoinIR Lowerer の差し込み位置
└─ テスト ケース定義
phase121_integration_roadmap.md（セクション 3-5）
├─ Phase 123: 環境変数スイッチ + 代表テスト
├─ Phase 124: JoinIR デフォルト化
└─ Phase 125: レガシー削除
```
**参照**：これらの設計を実装に落とすだけ
### ビルド・実行確認
```bash
# ビルド確認
cargo build --release 2>&1 | grep -E "error"
# レガシー経路確認
NYASH_HAKO_CHECK_JOINIR=0 ./target/release/nyash tools/hako_check/cli.hako
# JoinIR 経路確認
NYASH_HAKO_CHECK_JOINIR=1 ./target/release/nyash tools/hako_check/cli.hako
```
## ✅ 完成チェックリスト
- [ ] `src/config/env/hako_check.rs` で `hako_check_joinir_enabled()` 実装
- [ ] `docs/reference/environment-variables.md` に NYASH_HAKO_CHECK_JOINIR 記載
- [ ] hako_check ランナー修正で use_joinir フラグを受け取る
- [ ] MIR builder で legacy vs joinir lowering を切り替え
- [ ] 代表 6 ケースで JoinIR ON/OFF 両方テスト実施
- [ ] テスト結果（PASS/FAIL）を docs に記録
- [ ] phase121_hako_check_joinir_design.md に Phase 123 実装セクション追加
- [ ] hako_check_design.md にフロー図（2 パス）追加
- [ ] CURRENT_TASK.md に Phase 123 完了を反映
- [ ] ビルドエラーなし（Zero errors）
## 所要時間
**3時間程度**
- Task 1 (環境変数フラグ): 30分
- Task 2 (JoinIR スイッチ): 1.5時間
- Task 3 (テスト確認): 45分
- Task 4 (ドキュメント): 15分
## 次のステップ
**Phase 124**: JoinIR デフォルト化＆レガシー経路削除
```
現状: NYASH_HAKO_CHECK_JOINIR で選択可能
目標: JoinIR をデフォルト化＆レガシー削除
```
---
**進捗**:
- ✅ Phase 122-126: ConsoleBox 改善・統合完了
- 🎯 Phase 123 proper: hako_check JoinIR 実装 ← **現在のフェーズ**
- 📋 Phase 124: JoinIR デフォルト化
- 📋 Phase 125: レガシー経路削除
Status: Historical

380
docs/archive/phases/phase-106-156/phase124_hako_check_joinir_finalization.md Normal file
View File

@ -0,0 +1,380 @@
# Phase 124: hako_check レガシー削除 & JoinIR 専用再構築
## 🎯 ゴール
hako_check の MIR 生成経路を **JoinIR 専用化** し、環境変数フラグに頼らずデフォルトで JoinIR 経路を使う。旧 PHI/MIR Builder 経路は hako_check に関しては完全削除。
```
現状（Phase 123）: NYASH_HAKO_CHECK_JOINIR で 2パス選択可能
↓
目標（Phase 124）: JoinIR 一本専用化＆レガシー削除
```
## 📋 スコープ（やること・やらないこと）
### ✅ やること
1. docs の 2パス図を 1本（JoinIR 一本）に畳む
2. NYASH_HAKO_CHECK_JOINIR フラグを廃止
3. MIR Builder から hako_check 用 legacy lowering を削除
4. try_cf_if_joinir() / try_cf_loop_joinir() を JoinIR 専用に確定
5. テスト・CURRENT_TASK を JoinIR Only 前提に更新
### ❌ やらないこと
- JoinIR Lowerer 自体の仕様変更
- hako_check 診断ルール（HC001-031）のロジック変更
## 🏗️ 5 つのタスク
### Task 1: ドキュメントの 2パス図を 1本に畳む
**ファイル**:
- `docs/development/current/main/hako_check_design.md`
- `docs/development/current/main/phase121_hako_check_joinir_design.md`
**現在の図（Phase 123）**:
```
┌─ Legacy Path （NYASH_HAKO_CHECK_JOINIR=0）
│ .hako → Parse → MIR Builder (legacy) → VM
│
└─ JoinIR Path （NYASH_HAKO_CHECK_JOINIR=1）
.hako → Parse → MIR Builder → JoinIR Lowerer → VM
```
**目標の図（Phase 124）**:
```
JoinIR Only:
.hako → Parse → AST → MIR Builder (JoinIR if/loop lowering) → MIR → VM
```
**更新内容**:
```markdown
## hako_check 実行フロー（Phase 124 JoinIR 専用化）
### アーキテクチャ
```
Input: .hako script
↓
Tokenize & Parse → AST
↓
MIR Builder (JoinIR lowering for if/loop)
↓
MIR (SSA form with PHI nodes)
↓
VM Interpreter
↓
Diagnostic Output
```
### 設計の進化
- **Phase 121**: JoinIR 統合設計
- **Phase 123**: 環境変数フラグで 2パス選択可能に
- **Phase 124**: JoinIR 一本化＆レガシー削除
```
**Phase 121 docs に追加**:
```markdown
## Phase 122–124 実装完了サマリー
### Phase 123: 環境変数スイッチ導入
- NYASH_HAKO_CHECK_JOINIR で 2パス選択可能に
### Phase 124: JoinIR 専用化＆レガシー削除
- NYASH_HAKO_CHECK_JOINIR を廃止
- MIR Builder から legacy if/loop lowering を削除
- hako_check は JoinIR 一本化
- 旧経路は他モード用途から削除（v確認）
### 成果
✅ hako_check + selfhost Stage-3 が JoinIR 統一パイプラインで動作
✅ ドキュメント・実装・テストが JoinIR 前提に統一
```
### Task 2: NYASH_HAKO_CHECK_JOINIR フラグの完全削除
**方針**: パターン A（完全削除）を採用
**削除対象**:
1. **src/config/env/hako_check.rs**:
```rust
// ❌ 以下を完全削除
pub fn hako_check_joinir_enabled() -> bool {
matches!(
std::env::var("NYASH_HAKO_CHECK_JOINIR").as_deref(),
Ok("1") | Ok("true")
)
}
```
2. **src/config/env.rs**:
- `pub mod hako_check;` を削除 or hako_check モジュール自体を削除
3. **docs/reference/environment-variables.md**:
- NYASH_HAKO_CHECK_JOINIR セクション削除
**記録方法**:
```markdown
### NYASH_HAKO_CHECK_JOINIR （削除済み - Phase 124）
このフラグは Phase 123 で導入され、hako_check の legacy/JoinIR 2パス切り替え用でした。
Phase 124 で JoinIR 一本化により廃止。
**理由**: hako_check は現在 JoinIR 専用のため、環境変数による選択が不要。
**備考**: 他の用途で legacy if/loop lowering が必要な場合は NYASH_LEGACY_PHI=1 などで対応。
```
### Task 3: MIR Builder から legacy path を削除
**ファイル**:
- `src/mir/builder/if_form.rs` (cf_if())
- `src/mir/builder/control_flow.rs` (cf_loop() など)
**現在の分岐（Phase 123）**:
```rust
pub fn cf_if(&mut self, ...) -> Result<...> {
if hako_check_joinir_enabled() {
// JoinIR 経路
self.try_cf_if_joinir(...)
} else {
// Legacy 経路
self.lower_if_form(...)
}
}
```
**Phase 124 での処理**:
#### Option 1: hako_check モードの判定で分ける
```rust
pub fn cf_if(&mut self, ...) -> Result<...> {
if self.is_hako_check_mode() {
// hako_check は常に JoinIR
self.try_cf_if_joinir(...)? // Fail-Fast: error ならエラー確定
} else {
// 他のモード（あれば）は legacy をキープ
self.lower_if_form(...)
}
}
```
#### Option 2: 完全一本化（推奨）
もし他のモードでも legacy lowering が不要なら：
```rust
pub fn cf_if(&mut self, ...) -> Result<...> {
// 常に JoinIR（全モード統一）
self.try_cf_if_joinir(...) // Fail-Fast
}
```
**確認方針**:
1. hako_check 経路以外で lower_if_form() を使っている箇所を検索
2. 使っていなければ削除
3. 使っていれば、そのモード用のフラグで分岐を維持
**フォールバック処理の廃止**:
- Phase 123 の try_cf_if_joinir() に「JoinIR 不可 → legacy fallback」があれば削除
- Fail-Fast 原則に従い、JoinIR が適用できないパターンはエラーにする
```rust
// ❌ 削除対象（フォールバック）
if use_joinir {
match self.try_cf_if_joinir() {
Ok(phi_val) => return Ok(phi_val),
Err(_) => {
// fallback to legacy ← これを削除
return self.lower_if_form();
}
}
}
// ✅ Phase 124 版（Fail-Fast）
if self.is_hako_check_mode() {
self.try_cf_if_joinir()? // Error は即座に伝播
}
```
### Task 4: テスト更新（JoinIR Only を正とする）
**ファイル**:
- `local_tests/phase123_*.hako` (4ケース)
- `tools/smokes/v2/profiles/integration/hako_check_joinir.sh`
**テストケース修正**:
1. **テスト実行方法を簡略化**:
```bash
# Phase 123 形式（削除対象）
NYASH_HAKO_CHECK_JOINIR=0 ./target/release/nyash test.hako # ❌ 削除
NYASH_HAKO_CHECK_JOINIR=1 ./target/release/nyash test.hako # ← これだけ残す
# Phase 124 形式（推奨）
./target/release/nyash test.hako # JoinIR 一本で動く前提
```
2. **smoke スクリプト（hako_check_joinir.sh）の修正**:
```bash
#!/bin/bash
# Phase 124: hako_check JoinIR Only テスト
test_cases=(
"phase123_simple_if.hako"
"phase123_nested_if.hako"
"phase123_while_loop.hako"
"phase123_if_in_loop.hako"
)
echo "=== hako_check JoinIR Only Mode ==="
for case in "${test_cases[@]}"; do
# 環境変数なし（デフォルト JoinIR）で実行
./target/release/nyash "local_tests/$case" || exit 1
echo "✓ $case"
done
echo "All tests PASSED"
```
3. **テスト名・コメント更新**:
- ファイル名: `phase123_*.hako` → `hako_check_joinir_*.hako`（または keep）
- コメント: "Phase 123 JoinIR test" → "Phase 124 JoinIR Only (stable)"
4. **Phase 120/121 docs に追記**:
```markdown
### hako_check 代表パスの JoinIR 統一化（Phase 124）
hako_check の stable paths すべてが JoinIR 専用パイプラインで動作確認済み：
- ✅ simple_if.hako
- ✅ nested_if.hako
- ✅ while_loop.hako
- ✅ if_in_loop.hako
（legacy 経路は削除済み）
```
### Task 5: docs / CURRENT_TASK を第2章クローズ仕様にする
**ファイル**:
- `docs/development/current/main/hako_check_design.md`
- `docs/development/current/main/phase121_hako_check_joinir_design.md`
- `CURRENT_TASK.md`
**hako_check_design.md に追加**:
```markdown
## Phase 124: JoinIR 専用化＆レガシー削除（完了）
### 変更内容
- ✅ NYASH_HAKO_CHECK_JOINIR フラグを廃止
- ✅ MIR Builder から legacy if/loop lowering を削除
- ✅ hako_check は JoinIR 一本化
- ✅ Fail-Fast 原則でエラーハンドリングを統一
### 実行フロー（最終版）
```
.hako script
↓
Parse & Tokenize → AST
↓
MIR Builder (JoinIR lowering for if/loop)
↓
MIR with PHI nodes
↓
VM Interpreter
↓
Diagnostic Report
```
### テスト状況
- 代表 4 ケース: 全て JoinIR Only で PASS
- legacy 経路: 削除確認済み
```
**Phase 121 docs に "Chapter Close" セクション追加**:
```markdown
## JoinIR/selfhost 第2章 完了
### 設計フェーズ（Phase 121）
- If/Loop の JoinIR 統合設計
- hako_check 代表パス洗出し
### 実装フェーズ（Phase 122-124）
- Phase 122: println/log 統一
- Phase 123: hako_check に JoinIR スイッチ導入
- Phase 124: JoinIR 専用化＆レガシー削除
### 成果
✅ hako_check は JoinIR 一本化
✅ selfhost Stage-3 + hako_check が統一パイプラインで動作
✅ ドキュメント・実装・テストが統一
### 次章予告
次は selfhost Stage-4（高度なパターン対応）への準備を進める。
```
**CURRENT_TASK.md に追加**:
```markdown
### Phase 124: hako_check レガシー削除 & JoinIR 専用再構築 ✅
**完了内容**:
- NYASH_HAKO_CHECK_JOINIR フラグを廃止
- MIR Builder から legacy if/loop lowering を削除（hako_check用）
- hako_check は JoinIR 一本化
- 代表テスト 4 ケースで JoinIR Only 動作確認
**テスト結果**:
- 4/4 PASS（全て JoinIR 専用）
**成果**:
- JoinIR/selfhost 第2章 完了
- hako_check + selfhost Stage-3 が統一パイプラインで動作
- ドキュメント・実装・テストが統一
**次フェーズ**: selfhost Stage-4 拡張 or 次の大型改善へ
```
## ✅ 完成チェックリスト
- [ ] hako_check_design.md の図を 2パス → 1本に更新
- [ ] phase121_hako_check_joinir_design.md に "Phase 122-124 実装完了" セクション追加
- [ ] NYASH_HAKO_CHECK_JOINIR フラグを src/config/env/hako_check.rs から削除
- [ ] docs/reference/environment-variables.md から NYASH_HAKO_CHECK_JOINIR を削除
- [ ] MIR Builder の cf_if() / cf_loop() から NYASH_HAKO_CHECK_JOINIR 分岐を削除
- [ ] try_cf_if_joinir() / try_cf_loop_joinir() のフォールバック処理を削除（Fail-Fast）
- [ ] hako_check モード判定がある場合、legacy path 削除後も分岐を確認
- [ ] local_tests/phase123_*.hako テストを環境変数なしで実行確認
- [ ] hako_check_joinir.sh を更新（環境変数削除、JoinIR Only 前提）
- [ ] テスト実行: 4/4 PASS 確認
- [ ] CURRENT_TASK.md に Phase 124 完了を記録
- [ ] ビルドエラーなし（Zero errors）
## 所要時間
**2.5時間程度**
- Task 1 (ドキュメント更新): 30分
- Task 2 (フラグ削除): 20分
- Task 3 (legacy path 削除): 45分
- Task 4 (テスト更新): 30分
- Task 5 (最終ドキュメント): 15分
## 次のステップ
**selfhost Stage-4 拡張** または **次の大型改善フェーズ**
JoinIR/selfhost 第2章が完了し、hako_check + selfhost が統一パイプラインで動作。
今後はさらに複雑なパターン対応やパフォーマンス最適化へ進める準備が整った。
---
**進捗**:
- ✅ Phase 122-126: ConsoleBox 改善・統合
- ✅ Phase 123 proper: hako_check JoinIR 基盤構築
- 🎯 Phase 124: hako_check レガシー削除 & JoinIR 専用化 ← **現在のフェーズ**
- 📋 次: selfhost Stage-4 or 次大型フェーズ
Status: Historical

428
docs/archive/phases/phase-106-156/phase124_vm_method_dispatch_unification.md Normal file
View File

@ -0,0 +1,428 @@
# Phase 124: VM Method Dispatch 統一化
⚠️ **Note**: このドキュメントは Phase 124 の実装記録です。
統合的なガイドは [ConsoleBox 完全ガイド](consolebox_complete_guide.md) をご参照ください。
## 目的
`src/backend/mir_interpreter/handlers/calls/method.rs` の `execute_method_call()` を、現在の手動 match ベースの分岐処理から **TypeRegistry ベースの統一的なディスパッチ** に移行する。
これにより、ビルトイン型（String, Integer, Array）とプラグイン Box のメソッド解決を統一化し、コードの保守性と拡張性を向上させる。
## 現在の問題
### パターン 1: 型ごとの match 分岐（lines 155-216）
```rust
fn execute_method_call(
&mut self,
receiver: &VMValue,
method: &str,
args: &[ValueId],
) -> Result<VMValue, VMError> {
match receiver {
VMValue::String(s) => match method {
"length" => Ok(VMValue::Integer(s.len() as i64)),
"concat" => { /* 実装 */ }
"replace" => { /* 実装 */ }
// ... 複数のメソッド
},
VMValue::BoxRef(box_ref) => {
// ConsoleBox特別処理
if box_ref.type_name() == "ConsoleBox" { ... }
// StringBox特別処理
if box_ref.type_name() == "StringBox" { ... }
// プラグイン処理
if let Some(p) = box_ref.as_any().downcast_ref::<PluginBoxV2>() { ... }
},
_ => Err(...)
}
}
```
### 問題点
1. **統一性の欠如**: String のメソッドと BoxRef のメソッドで異なる処理パス
2. **スケーラビリティの悪さ**: 新しい型を追加するたびに新しい match arm が必要
3. **二重実装の危険性**: StringBox と String の両方にメソッド実装がある可能性
4. **保守性**: TypeRegistry と VM 実装が乖離
### パターン 2: Box 型の重複処理（lines 218-340）
```rust
// ConsoleBox の特別処理（lines 220-265）
if box_ref.type_name() == "ConsoleBox" {
if let Some(console) = box_ref.as_any().downcast_ref::<ConsoleBox>() {
match method {
"log" | "println" => { /* Rust 実装 */ }
// ...
}
}
}
// StringBox の特別処理（lines 267-317）
if box_ref.type_name() == "StringBox" {
let s_box = box_ref.to_string_box();
let s = s_box.value;
match method {
"lastIndexOf" => { /* 実装 */ }
// ...
}
}
// プラグイン Box の処理（lines 318-340）
if let Some(p) = box_ref.as_any().downcast_ref::<PluginBoxV2>() {
let host = get_global_plugin_host();
match host.invoke_instance_method(...) {
Ok(Some(ret)) => Ok(VMValue::from_nyash_box(ret)),
// ...
}
}
```
**問題**: ビルトイン Box（ConsoleBox, StringBox, ArrayBox）とプラグイン Box で異なる処理パス
## 設計: TypeRegistry ベースの統一ディスパッチ
### 目標アーキテクチャ
```
┌─────────────────────────────────────────────────────┐
│ execute_method_call(receiver, method_name, args) │
│ │
│ 1. receiver から type_name を取得 │
│ 2. TypeRegistry で type_id を検索 │
│ 3. MethodEntry から slot を取得 │
│ 4. 統一ディスパッチ (dispatch_by_slot) │
│ └─> 引数パッキング & invoke │
│ └─> 結果のアンパック │
└─────────────────────────────────────────────────────┘
```
### 実装ステップ
#### Step 1: TypeRegistry へのビルトイン型登録
**ファイル**: `src/runtime/type_registry.rs`
現在、TypeRegistry には Box 型のみ登録（type_id 1-7）。String, Integer などのビルトイン型は登録されていない。
**修正内容**：
```rust
// type_registry.rs の定義部で、ビルトイン型用の定義を追加
// ビルトイン型の type_id を確認
pub const BUILTIN_STRING_TYPE_ID: u32 = 100; // 任意の ID
pub const BUILTIN_INTEGER_TYPE_ID: u32 = 101;
pub const BUILTIN_ARRAY_TYPE_ID: u32 = 102;
// 初期化時に TypeRegistry へ登録
pub fn register_builtin_types() {
// String メソッド
let string_methods = vec![
("length", 0, 1),
("concat", 1, 2),
("replace", 2, 3),
("indexOf", 3, 4),
("lastIndexOf", 4, 5),
("substring", 5, 6),
];
// ... 登録処理
// Integer メソッド
let integer_methods = vec![
("to_string", 10, 11),
// ... 他のメソッド
];
// ... 登録処理
// Array メソッド
let array_methods = vec![
("birth", 30, 31),
("push", 31, 32),
("length", 32, 33),
("get", 33, 34),
("set", 34, 35),
];
// ... 登録処理
}
```
#### Step 2: ディスパッチ関数の実装
**ファイル**: `src/backend/mir_interpreter/handlers/calls/method.rs`
```rust
/// TypeRegistry ベースの統一ディスパッチ
fn dispatch_by_slot(
&mut self,
receiver: &VMValue,
type_id: u32,
slot: u32,
args: &[ValueId],
) -> Result<VMValue, VMError> {
// type_id と slot に基づいて実装を選択
match (type_id, slot) {
// String メソッド
(BUILTIN_STRING_TYPE_ID, 1) => {
// "length" メソッド
if let VMValue::String(s) = receiver {
Ok(VMValue::Integer(s.len() as i64))
} else {
Err(self.err_invalid("String.length: invalid receiver"))
}
}
(BUILTIN_STRING_TYPE_ID, 2) => {
// "concat" メソッド
if let VMValue::String(s) = receiver {
if let Some(arg_id) = args.get(0) {
let arg_val = self.reg_load(*arg_id)?;
let new_str = format!("{}{}", s, arg_val.to_string());
Ok(VMValue::String(new_str))
} else {
Err(self.err_invalid("String.concat: requires 1 argument"))
}
} else {
Err(self.err_invalid("String.concat: invalid receiver"))
}
}
// ... 他の String メソッド
// Array メソッド
(BUILTIN_ARRAY_TYPE_ID, 31) => {
// "push" メソッド
// ...
}
// プラグイン Box（slot >= 1000）
(_, slot) if slot >= 1000 => {
// プラグイン Box のメソッド呼び出し
// ...
}
_ => Err(self.err_method_not_found(&format!("type_id={}", type_id), "unknown"))
}
}
```
#### Step 3: execute_method_call の簡略化
```rust
fn execute_method_call(
&mut self,
receiver: &VMValue,
method: &str,
args: &[ValueId],
) -> Result<VMValue, VMError> {
// 1. receiver から type_name を取得
let type_name = match receiver {
VMValue::String(_) => "String",
VMValue::Integer(_) => "Integer",
VMValue::Bool(_) => "Bool",
VMValue::Null => "Null",
VMValue::Void => "Void",
VMValue::BoxRef(bx) => bx.type_name(),
VMValue::Handle(_) => "Handle",
};
// 2. TypeRegistry で type_id を検索
let type_id = self.type_registry.lookup_type_id(type_name)?;
// 3. MethodEntry から slot を取得
let slot = self.type_registry
.lookup_method_slot(type_id, method)?;
// 4. 統一ディスパッチ
self.dispatch_by_slot(receiver, type_id, slot, args)
}
```
## 実装優先順位
### Priority 1: String メソッドの統一化（1時間）
- String.length, concat, replace, indexOf, lastIndexOf, substring
- 現在のコード（lines 156-216）を dispatch_by_slot に移行
- テスト: string_ops_basic.hako が動作確認
### Priority 2: Array メソッドの統一化（1時間）
- Array.birth, push, length, get, set
- 現在のコード（lines 88-121）を dispatch_by_slot に移行
- テスト: test_array_simple.hako が動作確認
### Priority 3: Box 型の統一化（1.5時間）
- ConsoleBox.log, println, warn, error, clear
- StringBox.indexOf, find, is_space, is_alpha
- 現在の特別処理（lines 220-317）を dispatch_by_slot に移行
- テスト: Phase 120 representative tests が動作確認
### Priority 4: コード削減（0.5時間）
- 古い match 文の削除
- 未使用の型チェック関数の削除
- ドキュメント更新
## 実装の注意点
### 1. タイプシステムの一貫性
```rust
// ❌ 問題: String は VMValue::String だが、
// StringBox は VMValue::BoxRef に包含されている
VMValue::String(s) // プリミティブ
VMValue::BoxRef(bx) // String "StringBox" という Box
// ✅ 解決: TypeRegistry で両方を同じ type_id で管理
// String: type_id=100（プリミティブ用）
// StringBox: type_id=100（同じ、VM上で互換性）
```
### 2. スロット (slot) の管理
現在、nyash.toml や type_registry.rs で slot が定義されているが、整合性が取れているか確認が必要：
```toml
# nyash.toml の例
[libraries."libnyash_console_plugin.so".ConsoleBox.methods]
log = { method_id = 1 }
println = { method_id = 1 }
warn = { method_id = 401 } # ← slot 401？
```
**修正が必要な場合**:
- TypeRegistry での slot 定義と nyash.toml を統一
- ドキュメント化（slot 予約表）
### 3. フォールバックの廃止
現在、古いコードには環境変数ガード（`NYASH_VM_RECV_ARG_FALLBACK` など）がある。Phase 124 では削除可能：
```rust
// ❌ 削除対象
let tolerate = std::env::var("NYASH_VM_RECV_ARG_FALLBACK")
.ok()
.as_deref()
== Some("1");
if tolerate { /* フォールバック */ }
// ✅ Phase 124 後: TypeRegistry ベースなので不要
```
## テスト計画
### ユニットテスト
新しい slot ベースのディスパッチを確認：
```rust
#[cfg(test)]
mod tests {
#[test]
fn test_dispatch_by_slot_string_length() {
// slot = String.length の slot
let receiver = VMValue::String("hello".to_string());
let slot = 1; // type_id=100 での length の slot
// ... assert
}
}
```
### 統合テスト
既存のテストすべてが動作確認：
```bash
# 基本テスト
cargo test --release
# Phase 120 representative tests
NYASH_JOINIR_STRICT=1 ./target/release/nyash apps/tests/esc_dirname_smoke.hako
# スモークテスト
tools/smokes/v2/run.sh --profile quick
```
## 期待される効果
### コード削減
- **削減行数**: ~100行（execute_method_call の簡略化）
- **削除対象**: 古い match 文、環境変数ガード
### 保守性向上
- メソッド解決が一元化（TypeRegistry）
- ビルトイン型とプラグイン Box の統一処理
- スロット番号で高速ディスパッチ可能
### 拡張性向上
- 新しい Box 型の追加が容易（TypeRegistry 登録のみ）
- ユーザー定義 Box への拡張が自然
### 性能向上
- slot による直接ディスパッチ（型チェック削減）
- match の arm 数削減
## 実装上の危険
### 1. Type ID の衝突
ビルトイン型（String/Integer など）と Box 型の type_id が衝突しないよう注意：
```rust
// Box 型: type_id = 1-10（既存）
pub const CONSOLE_BOX_TYPE_ID: u32 = 7;
// ビルトイン型: type_id = 100-199（新規）
pub const BUILTIN_STRING_TYPE_ID: u32 = 100;
pub const BUILTIN_INTEGER_TYPE_ID: u32 = 101;
```
### 2. 既存コードとの互換性
Phase 124 の修正後、古い `execute_method_call` のコードパスが残っていないか確認：
```bash
# 古いパターンの検索
rg "VMValue::String.*match method" src/
rg "type_name.*ConsoleBox" src/
```
### 3. テストカバレッジ
Phase 124 後、全メソッドが dispatch_by_slot を通るようになったため、テストも統一的に実行されることを確認。
## ロールバック計画
修正後に問題が発生した場合：
```bash
# 修正前のバージョンに戻す
git checkout HEAD~ -- src/backend/mir_interpreter/handlers/calls/method.rs
# または
git show <commit-hash>:src/... > src/...
```
## 所要時間
**4時間程度**
- Step 1-2 (TypeRegistry 登録 + ディスパッチ関数): 1.5時間
- Step 3 (execute_method_call 簡略化): 1.5時間
- Step 4 (テスト + 削減): 1時間
## 完了後の次のステップ
Phase 125: 削除：deprecated builtin ConsoleBox（3時間）
---
**進捗記録**:
- Phase 122.5: nyash.toml method_id 修正 ✅ 完了
- Phase 123: ConsoleBox WASM/非WASM 統一化 ✅ 完了
- Phase 124: VM Method Dispatch 統一化 ← **現在のフェーズ**
- Phase 125: 削除：deprecated builtin ConsoleBox（予定）
- Phase 126: ドキュメント統合（予定）
Status: Historical

429
docs/archive/phases/phase-106-156/phase125_delete_deprecated_console_box.md Normal file
View File

@ -0,0 +1,429 @@
# Phase 125: 削除：deprecated builtin ConsoleBox
⚠️ **Note**: このドキュメントは Phase 125 の実装記録です。
統合的なガイドは [ConsoleBox 完全ガイド](consolebox_complete_guide.md) をご参照ください。
## 目的
ビルトイン ConsoleBox 実装を完全に削除し、**プラグインベース（nyash-console-plugin）の ConsoleBox のみ** に移行する。
これにより、「Everything is Plugin」の原則を完全に実装し、Core Box Factory の複雑性を低減する。
## 背景
### 現在の二重実装
**Builtin ConsoleBox**（src/box_factory/builtin_impls/console_box.rs）:
- ビルトイン実装：36行
- 削除予定（Phase 125 = 今）
**Plugin ConsoleBox**（plugins/nyash-console-plugin/）:
- プラグイン実装：完全に動作
- Phase 122 で println のサポートを追加
- 推奨（使用すべき）
### 削除理由
1. **二重性の排除**: 同じ Box が2つの経路で実装されている
2. **Plugin-First 原則**: 全 Box をプラグイン化（Phase 15.5 目標）
3. **コード削減**: 不要なビルトイン実装削除
4. **保守性向上**: Core Factory の複雑性低減
5. **整合性確保**: TypeRegistry と Plugin System の統一（Phase 124 完了後）
## 削除対象
### 1. ファイル削除
**ファイル**: `src/box_factory/builtin_impls/console_box.rs` (36行)
```rust
// ❌ 削除対象
pub fn create(_args: &[Box<dyn NyashBox>]) -> Result<Box<dyn NyashBox>, RuntimeError> {
eprintln!(
"⚠️ [DEPRECATED] Using builtin ConsoleBox - use nyash-console-plugin!\n\
📋 Phase 15.5: Everything is Plugin!\n\
🔧 Check: plugins/nyash-console-plugin\n\
⚠️ WARNING: ConsoleBox is critical for logging - remove LAST!"
);
Ok(Box::new(crate::boxes::console_box::ConsoleBox::new()))
}
#[cfg(test)]
mod tests {
#[test]
fn test_builtin_console_box_creation() {
let result = create(&[]).unwrap();
assert!(result.as_any().downcast_ref::<ConsoleBox>().is_some());
}
}
```
**削除理由**: プラグインのみで十分動作
### 2. builtin.rs の修正
**ファイル**: `src/box_factory/builtin.rs`
#### 修正内容 1: create_box メソッドから ConsoleBox case を削除
現在（行 52）:
```rust
// Phase 2.6: DELETE LAST (critical for logging)
"ConsoleBox" => builtin_impls::console_box::create(args),
```
修正後:
```rust
// Phase 125: ✅ DELETED - Now plugin-only (nyash-console-plugin)
// ConsoleBox route deleted - must use plugin
```
#### 修正内容 2: box_types メソッドから ConsoleBox を削除
現在（行 79）:
```rust
vec![
// Primitive wrappers
"StringBox",
"IntegerBox",
"BoolBox",
// Collections/common
"ArrayBox",
"MapBox",
"ConsoleBox", // ← 削除
// Fallback support
"FileBox",
"FileHandleBox", // Phase 113
"NullBox",
]
```
修正後:
```rust
vec![
// Primitive wrappers
"StringBox",
"IntegerBox",
"BoolBox",
// Collections/common
"ArrayBox",
"MapBox",
// ConsoleBox: Phase 125 - Plugin-only (nyash-console-plugin)
// Fallback support
"FileBox",
"FileHandleBox", // Phase 113
"NullBox",
]
```
### 3. builtin_impls/mod.rs の修正
**ファイル**: `src/box_factory/builtin_impls/mod.rs`
現在の状態:
```rust
//! Individual builtin Box implementations (easy deletion for Plugin migration)
//! ...
//! 6. console_box.rs - Phase 2.6 🔄 Plugin exists, remove LAST
pub mod console_box; // ← 削除
```
修正後:
```rust
//! Individual builtin Box implementations (easy deletion for Plugin migration)
//! ...
//! ConsoleBox: Phase 125 ✅ DELETED - Plugin-only
//! 6. (deleted)
```
### 4. src/boxes/console_box.rs は削除しない
⚠️ **重要**: `src/boxes/console_box.rs` は削除 **しない**！
理由:
- このファイルは **ビルトイン Rust 実装**（src/boxes/ ツリー）
- プラグイン（libnyash_console_plugin.so）が内部で使用している
- VM の直接メソッド呼び出しで使用される（Phase 124 で TypeRegistry ベースの dispatch_by_slot に統合）
```
✅ 保持: src/boxes/console_box.rs（Rust 実装）
❌ 削除: src/box_factory/builtin_impls/console_box.rs（ファクトリー実装）
```
## 実装ステップ
### Step 1: ファイル削除
```bash
# Phase 125: ConsoleBox builtin implementation削除
git rm src/box_factory/builtin_impls/console_box.rs
```
### Step 2: builtin.rs 修正
ファイル: `src/box_factory/builtin.rs`
```diff
match name {
// Phase 2.1-2.2: DELETE when plugins are confirmed working
"StringBox" => builtin_impls::string_box::create(args),
"IntegerBox" => builtin_impls::integer_box::create(args),
// Phase 2.3: DELETE when BoolBox plugin is created
"BoolBox" => builtin_impls::bool_box::create(args),
// Phase 2.4-2.5: DELETE when collection plugins confirmed
"ArrayBox" => builtin_impls::array_box::create(args),
"MapBox" => builtin_impls::map_box::create(args),
- // Phase 2.6: DELETE LAST (critical for logging)
- "ConsoleBox" => builtin_impls::console_box::create(args),
+ // Phase 125: ✅ DELETED - ConsoleBox is now plugin-only!
+ // See: plugins/nyash-console-plugin for current implementation
// Phase 15.5: Fallback support (auto/core-ro modes)
"FileBox" => builtin_impls::file_box::create(args),
// Phase 113: FileHandleBox Nyash API
"FileHandleBox" => builtin_impls::filehandle_box::create(args),
// Special: Keep vs Delete discussion needed
"NullBox" => builtin_impls::null_box::create(args),
// Leave other types to other factories (user/plugin)
_ => Err(RuntimeError::InvalidOperation {
message: format!("Unknown Box type: {}", name),
}),
}
```
vec の修正:
```diff
fn box_types(&self) -> Vec<&str> {
vec![
// Primitive wrappers
"StringBox",
"IntegerBox",
"BoolBox",
// Collections/common
"ArrayBox",
"MapBox",
- "ConsoleBox",
+ // ConsoleBox: Phase 125 - Plugin-only (nyash-console-plugin)
// Fallback support
"FileBox",
"FileHandleBox", // Phase 113
"NullBox",
]
}
```
### Step 3: builtin_impls/mod.rs 修正
```diff
//! Individual builtin Box implementations (easy deletion for Plugin migration)
//!
//! Phase 0: ✅ Separated implementations
//! Phase 1-2: 🚧 Deletion roadmap
//!
//! Deletion order:
//! 1. string_box.rs - Phase 2.1 🔄 Plugin exists, OK to delete
//! 2. integer_box.rs - Phase 2.2 🔄 Plugin exists, OK to delete
//! 3. bool_box.rs - Phase 2.3 🔄 Plugin needed first
//! 4. array_box.rs - Phase 2.4 🔄 Plugin needed first
//! 5. map_box.rs - Phase 2.5 🔄 Plugin needed first
-//! 6. console_box.rs - Phase 2.6 🔄 Plugin exists, remove LAST
+//! 6. console_box.rs - Phase 125 ✅ DELETED! Plugin-only now!
//! 7. file_box.rs - Phase 15.5-2.7 ⚠️ Fallback support (keep for now)
//! 8. filehandle_box.rs - Phase 113 ✅ Nyash API, keep
//! 9. null_box.rs - Phase 2.8? ❓ Design decision needed
// Builtin Box factory implementations
pub mod string_box;
pub mod integer_box;
pub mod bool_box;
pub mod array_box;
pub mod map_box;
-pub mod console_box;
+// Phase 125: console_box ✅ DELETED - Plugin-only (nyash-console-plugin)
pub mod file_box;
pub mod filehandle_box;
pub mod null_box;
```
### Step 4: テスト確認
```bash
# コンパイル確認
cargo build --release 2>&1 | grep -E "error"
# ビルトイン ConsoleBox への参照がないことを確認
rg "builtin.*console_box|builtin_impls::console_box" src/ --type rust
# ConsoleBox の参照（プラグインのみ使用）を確認
rg "\"ConsoleBox\"" src/ --type rust | grep -v "comment\|doc\|//\|#"
# → libnyash_console_plugin.so のみが残るはず
# Phase 120 representative tests で plugin ConsoleBox が動作することを確認
NYASH_JOINIR_STRICT=1 ./target/release/nyash apps/tests/esc_dirname_smoke.hako
# → [Console LOG] dir1/dir2 が出力される（プラグイン版 ConsoleBox）
```
### Step 5: フルテスト実行
```bash
# 全テスト実行
cargo test --release 2>&1 | tail -20
# スモークテスト
tools/smokes/v2/run.sh --profile quick
```
## 検証ポイント
### ✅ 検証 1: ビルトイン ConsoleBox が完全に削除されたか
```bash
# builtin_impls::console_box への参照がゼロ
rg "console_box" src/box_factory/ --type rust
# → mod.rs, builtin.rs に残るはずなし（コメント除外）
```
### ✅ 検証 2: プラグイン ConsoleBox が動作するか
```bash
# Phase 120 representative test で ConsoleBox が使用される
NYASH_JOINIR_STRICT=1 ./target/release/nyash apps/tests/esc_dirname_smoke.hako
# 出力: [Console LOG] dir1/dir2
```
### ✅ 検証 3: ビルドエラーがないか
```bash
cargo build --release 2>&1 | grep error
# → ゼロ件（エラーなし）
```
### ✅ 検証 4: テストが失敗していないか
```bash
cargo test --release builtin 2>&1 | grep "test_builtin_console_box_creation"
# → "test not found" か "no matching tests"（テスト削除確認）
```
## 期待される効果
### コード削減
- **ファイル削除**: `console_box.rs` (36行)
- **builtin.rs 削減**: ~10行（case と vec 要素）
- **mod.rs 削減**: ~2行（mod 宣言と コメント更新）
- **テスト削減**: ~10行（test_builtin_console_box_creation）
**合計**: ~58行削減
### アーキテクチャ改善
1. **Plugin-First 原則の実装**: ConsoleBox = プラグインのみ
2. **ビルトイン Factory の簡略化**: 1つの Box 削除
3. **"Everything is Plugin" 完成へ**: Phase 125 で ConsoleBox が最後のマイルストーン
4. **保守性向上**: 単一のプラグイン実装で統一
## 実装上の注意
### 1. ConsoleBox 削除時の段階的調査
削除前に確認:
- nyash.toml で ConsoleBox がプラグイン登録されているか
- `libnyash_console_plugin.so` がビルドされているか
- プラグインが完全に動作するか
```bash
# プラグイン確認
ls plugins/nyash-console-plugin/
ls target/release/libnyash_console_plugin.so
# プラグイン登録確認
rg "ConsoleBox" nyash.toml
# プラグイン動作テスト
echo 'local c = new ConsoleBox(); c.println("Hello")' > test.hako
./target/release/nyash test.hako
```
### 2. ビルトイン ConsoleBox の残存リスク
⚠️ **削除後の確認**:
古いコードが hidden に残っていないか：
```bash
# 削除確認
git log --oneline | head -5 # commit 確認
git status # 修正ファイル確認
cargo build --release 2>&1 | grep console # コンパイル確認
```
### 3. テスト との互換性
```bash
# 削除による test の失敗がないか確認
cargo test --release 2>&1 | grep "FAILED\|test failed"
```
## ロールバック計画
修正後に問題が発生した場合：
```bash
# 修正前のバージョンに戻す
git reset --hard HEAD~1
# または特定ファイルのみ復元
git checkout HEAD~ -- src/box_factory/builtin_impls/console_box.rs
git checkout HEAD~ -- src/box_factory/builtin.rs
git checkout HEAD~ -- src/box_factory/builtin_impls/mod.rs
```
## 所要時間
**3時間程度**
- ファイル削除と修正: 1時間
- テスト・検証: 1時間
- ドキュメント更新: 1時間
## 完了後の次のステップ
Phase 126: ドキュメント統合（2時間）
---
**進捗記録**:
- Phase 122.5: nyash.toml method_id 修正 ✅ 完了
- Phase 123: ConsoleBox WASM/非WASM 統一化 ✅ 完了
- Phase 124: VM Method Dispatch 統一化 ✅ 完了
- Phase 125: 削除：deprecated builtin ConsoleBox ← **現在のフェーズ**
- Phase 126: ドキュメント統合（予定）
## 注記
### なぜ src/boxes/console_box.rs は削除しないのか？
```
src/boxes/console_box.rs ← これは「実装」（削除しない）
↓
libnyash_console_plugin.so ← これは「プラグイン」（存在・使用）
↓
src/box_factory/builtin_impls/console_box.rs ← これは「ファクトリー」（削除 = Phase 125）
```
つまり：
- **src/boxes/**: Rust 実装（VM が内部的に使用）
- **plugins/**: プラグイン（ユーザー向けインターフェース）
- **src/box_factory/builtin_impls/**: ビルトイン factory（今回削除）
Phase 125 では **factory** のみ削除し、Rust 実装は残す。
Status: Historical

400
docs/archive/phases/phase-106-156/phase126_documentation_consolidation.md Normal file
View File

@ -0,0 +1,400 @@
# Phase 126: ドキュメント統合と整理
## 目的
Phase 122-125 で実装された ConsoleBox 関連の複数のドキュメントを統合し、重複を排除して、ユーザーフレンドリーな一元的な参照ドキュメントにする。
## 現在の状況
### Phase 122-125 で作成されたドキュメント（計 ~58KB）
```
📄 phase122_consolebox_println_unification.md (15K) - println/log統一設計
📄 phase122_5_nyash_toml_fix.md (3.8K) - method_id修正記録
📄 phase123_consolebox_code_unification.md (13K) - WASM/非WASM統一化
📄 phase124_vm_method_dispatch_unification.md (13K) - TypeRegistry統合
📄 phase125_delete_deprecated_console_box.md (13K) - ビルトイン削除
```
### 既存の関連ドキュメント（計 ~97KB）
```
📄 core_boxes_design.md (65K) - Core Box の全体設計
📄 logging_policy.md (21K) - ログ出力ポリシー
📄 hako_logging_design.md (11K) - Hako コンパイラのログ設計
```
### 問題点
1. **重複性**: Phase 122 の println/log 説明が hako_logging_design.md と重複
2. **散在性**: ConsoleBox 関連の情報が 5 つのファイルに分散
3. **ナビゲーション困難**: ユーザーが「ConsoleBox について知りたい」時、どのファイルを読むべきか不明
4. **保守性低下**: 同じ情報を複数箇所で修正する必要がある
## 統合戦略
### 戦略 A: マスタードキュメント作成（推奨）
**新規作成**: `consolebox_complete_guide.md` (統合マスター)
このドキュメントに以下を含める：
1. **概要セクション**
- ConsoleBox の歴史（Phase 122-125 での進化）
- デザイン決定の背景
2. **ユーザーガイド**
- API 使用方法（println, log, warn, error, clear）
- WASM/ネイティブ環境での動作
- 実装例
3. **アーキテクチャ設計**
- println/log エイリアス設計（Phase 122）
- WASM/非WASM の統一化（Phase 123）
- TypeRegistry ベースのディスパッチ（Phase 124）
- プラグインへの移行（Phase 125）
4. **実装者向けガイド**
- TypeRegistry での slot 管理
- VM Method Dispatch の仕組み
- プラグイン ConsoleBox の拡張方法
5. **クロスリファレンス**
- Phase 122-125 の詳細ドキュメントへのリンク
- core_boxes_design.md との関連セクション
- logging_policy.md との統合例
### 戦略 B: 既存ドキュメント更新
**修正対象**:
1. **core_boxes_design.md**
- Phase 125 の削除についての Section 追加
-「ConsoleBox は現在プラグイン」の明記
2. **logging_policy.md**
- Phase 122.5 の method_id 統一の記述追加
- println の推奨使用例
3. **hako_logging_design.md**
- Phase 122 の println サポートについて記述
## 実装ステップ
### Step 1: マスタードキュメント作成
**ファイル**: `docs/development/current/main/consolebox_complete_guide.md`
```markdown
# ConsoleBox Complete Guide - デザイン・実装・運用
## 📖 目次
1. 概要・歴史
2. ユーザーガイド
3. アーキテクチャ設計
4. 実装者向けガイド
5. FAQ・トラブルシューティング
## 1. 概要・歴史
### ConsoleBox の進化（Phase 122-125）
**Phase 122**: println/log エイリアス統一
- println を log のエイリアスとして実装
- TypeRegistry で slot 400（log と同じ）に統一
- nyash.toml での method_id 修正（Phase 122.5）
**Phase 123**: WASM/非WASM コード統一
- マクロベースの統一化で重複削減
- 67行削減（27.3%削減）
**Phase 124**: TypeRegistry ベースの統一ディスパッチ
- String, Array, ConsoleBox を統一的に dispatch_by_slot で処理
- 100行削減（method.rs 簡略化）
**Phase 125**: ビルトイン ConsoleBox 削除
- src/box_factory/builtin_impls/console_box.rs 削除
- プラグインのみへ移行（"Everything is Plugin" 実現）
- 52行削減
### 現在の状態（Phase 126 以降）
✅ ConsoleBox はプラグインのみ
✅ Rust 実装（src/boxes/console_box.rs）は内部用
✅ TypeRegistry ベースのディスパッチ
✅ println/log 統一
## 2. ユーザーガイド
### 基本的な使用方法
```nyash
// ConsoleBox インスタンス作成
local console
console = new ConsoleBox()
// 通常ログ（推奨）
console.println("Hello, Nyash!")
console.log("Same as println")
// 警告・エラー
console.warn("This is a warning")
console.error("Something went wrong")
// 画面クリア
console.clear()
```
### WASM 環境での動作
ブラウザの開発者ツール（F12）のコンソールに出力されます。
### ネイティブ環境での動作
標準出力にプレフィックス付きで出力されます：
```
[Console LOG] Hello, Nyash!
[Console WARN] This is a warning
[Console ERROR] Something went wrong
[Console CLEAR]
```
## 3. アーキテクチャ設計
[Phase 122-125 の詳細設計ドキュメントへのリンク]
[core_boxes_design.md のセクション reference]
## 4. 実装者向けガイド
[TypeRegistry 統合]
[VM Method Dispatch]
[プラグイン拡張方法]
## 5. FAQ・トラブルシューティング
Q: println と log の違いは？
A: Phase 122 以降、完全に同じです（println = log のエイリアス）
Q: println が動作しない
A: プラグイン（libnyash_console_plugin.so）が読み込まれているか確認してください
Q: println と log を区別する必要があります
A: TypeRegistry の slot をカスタマイズして異なる slot を割り当てることは可能ですが、推奨されません。
```
### Step 2: 既存ドキュメント更新
#### core_boxes_design.md の更新
**新規セクション追加**: Section 19 "Phase 125 ConsoleBox Transition"
```markdown
## Section 19: Phase 125 ConsoleBox Migration to Plugin
### 背景
Phase 122-125 で ConsoleBox は完全にプラグインベースに移行しました。
### 実装内容
- ビルトイン ConsoleBox（src/box_factory/builtin_impls/console_box.rs）削除
- Rust 実装（src/boxes/console_box.rs）は内部用として保持
- プラグイン（libnyash_console_plugin.so）のみが対外インターフェース
### 利点
- "Everything is Plugin" 原則の完全実装
- ビルトイン Factory の複雑性低減
- プラグイン拡張性の向上
### 参照
- [Phase 125 詳細](phase125_delete_deprecated_console_box.md)
- [ConsoleBox 完全ガイド](consolebox_complete_guide.md)
```
#### logging_policy.md の更新
**新規セクション追加**: Section X "Phase 122 println/log Unification"
```markdown
## Phase 122: println/log 統一化
### 背景
従来、println と log は別々のメソッドとして実装されていました。
### 実装内容
- println を log のエイリアスとして統一
- TypeRegistry で両者を同じ slot (400) に割り当て
- nyash.toml での method_id の統一（Phase 122.5）
### 使用ガイドライン
- **推奨**: println を使用（ユーザー向け API）
- **非推奨**: log を使用（互換性のみのため）
### 参照
- [Phase 122 詳細](phase122_consolebox_println_unification.md)
```
### Step 3: Phase 122-125 ドキュメントに統合フラグを追加
各ドキュメントの冒頭に以下を追加：
```markdown
# Phase 122: ConsoleBox println/log Unification
⚠️ **Note**: このドキュメントは Phase 122 の実装記録です。
統合的なガイドは [ConsoleBox 完全ガイド](consolebox_complete_guide.md) をご参照ください。
## 詳細情報
[各セクションへの reference]
```
### Step 4: ナビゲーション改善
既存ドキュメント（core_boxes_design.md, logging_policy.md）に **Related Documents** セクションを追加：
```markdown
## 📚 Related Documents
### ConsoleBox について知りたい場合
- [ConsoleBox 完全ガイド](consolebox_complete_guide.md) - 統合的なリファレンス
- [Phase 122-125 実装記録](phase122_*.md) - 詳細な実装背景
### ログ出力について知りたい場合
- [ログポリシー](logging_policy.md) - この文書
- [Hako ログ設計](hako_logging_design.md) - コンパイラ側
```
## 統合後のドキュメント構造
```
📁 docs/development/current/main/
📄 consolebox_complete_guide.md (新規, ~25KB)
├─ ユーザーガイド
├─ アーキテクチャ設計
├─ 実装者向けガイド
└─ クロスリファレンス
📄 core_boxes_design.md (修正, +Section 19 ~2KB)
└─ Phase 125 ConsoleBox Migration セクション追加
📄 logging_policy.md (修正, +~3KB)
└─ Phase 122 println/log 統一化 セクション追加
📄 hako_logging_design.md (修正, +~2KB)
└─ Phase 122 println サポート セクション追加
🗂️ Phase 122-125 実装記録（参考用）
├─ phase122_consolebox_println_unification.md
├─ phase122_5_nyash_toml_fix.md
├─ phase123_consolebox_code_unification.md
├─ phase124_vm_method_dispatch_unification.md
└─ phase125_delete_deprecated_console_box.md
```
## 実装上の注意
### 1. 重複排除のポイント
- **printf/log API説明**: 統合マスターに集約
- **TypeRegistry slot 定義**: 一度だけ説明
- **Phase 122-125 背景**: 統合マスターで説明
### 2. クロスリファレンスの管理
各ドキュメント間で相互参照を追加：
```markdown
[Related: Phase 122 実装記録](phase122_consolebox_println_unification.md)
[参照: TypeRegistry 設計](../architecture/type-registry-design.md)
```
### 3. バージョン管理
統合マスターの冒頭に：
```markdown
## 📅 Document Version
- **Last Updated**: Phase 126
- **Scope**: ConsoleBox API, Architecture, Implementation
- **Applies to**: Release X.Y.Z
```
## テスト・検証
### ドキュメント品質確認
1. **リンク確認**
```bash
# 内部リンク（相対パス）が正しいか確認
rg "\[.*\]\(\..*\.md\)" docs/development/current/main/
```
2. **重複確認**
```bash
# 同じコード例やセクションが複数ドキュメントに無いか
rg "console\.println|console\.log" docs/development/current/main/*.md | sort | uniq -c
```
3. **完全性確認**
- すべての Phase 122-125 の情報が統合マスターに含まれるか
- すべてのクロスリファレンスが有効か
## 期待される効果
### ドキュメント削減
- 統合マスター作成: +25KB
- 既存ドキュメント追加: +7KB
- **合計**: +32KB の新規マスター追加
### ナビゲーション改善
- 単一のエントリーポイント（consolebox_complete_guide.md）
- 階層的なセクション構造
- クロスリファレンスによる相互連携
### 保守性向上
- 重複説明を排除
- 同じ情報を一度だけ更新すれば OK
- Phase 122-125 の記録は参考用として保持
## ロールバック計画
修正後に問題が発生した場合：
```bash
# 修正前の状態に戻す
git checkout HEAD~ -- docs/development/current/main/
```
## 所要時間
**2時間程度**
- 統合マスター作成: 1時間
- 既存ドキュメント更新: 45分
- 検証・リンク確認: 15分
## 完了後
Phase 122-126 の全改善がコンプリート！
### 実装成果サマリー
- **Phase 122**: println/log エイリアス統一 ✅
- **Phase 122.5**: nyash.toml method_id 修正 ✅
- **Phase 123**: WASM/非WASM コード統一（67行削減） ✅
- **Phase 124**: TypeRegistry ディスパッチ統合（100行削減） ✅
- **Phase 125**: ビルトイン ConsoleBox 削除（52行削減） ✅
- **Phase 126**: ドキュメント統合・整理 ← **現在のフェーズ**
### 総削減コード量
**~219行削減** + **ドキュメント統合で保守性向上**
---
**進捗記録**:
- Phase 122.5: nyash.toml method_id 修正 ✅ 完了
- Phase 123: ConsoleBox WASM/非WASM 統一化 ✅ 完了
- Phase 124: VM Method Dispatch 統一化 ✅ 完了
- Phase 125: 削除：deprecated builtin ConsoleBox ✅ 完了
- Phase 126: ドキュメント統合 ← **現在のフェーズ**
Status: Historical

490
docs/archive/phases/phase-106-156/phase130_joinir_llvm_baseline.md Normal file
View File

@ -0,0 +1,490 @@
# Phase 130: JoinIR → LLVM ベースライン確立
## 🎯 ゴール
「JoinIR で selfhost/hako_check まで安定した」現在の状態から、**JoinIR → LLVM 経路の現状を観測・記録する** フェーズ。
目的：
- 代表的な .hako を LLVM ラインで実行し、「どこまで通っているか、どこが赤いか」を一覧化
- JoinIR → MIR → LLVM（ny-llvmc / ハーネス）経路での問題点（命令未対応 / ABI ズレ / print系など）を洗い出す
- **実装修正は Phase 131+ に回す**（Phase 130 は「観測専用」と割り切る）
```
Phase 124: JoinIR/selfhost 第2章 完了 ✅
↓
Phase 130: 「JoinIR → LLVM どこが赤いか」を観測・記録 ← ← ここ！
↓
Phase 131+: 個別の LLVM 側問題を潰す
```
---
## 📋 スコープ（やること・やらないこと）
### ✅ やること
1. 代表ケース選定（JoinIR/selfhost/hako_check から 5〜8 本）
2. LLVM 実行コマンドと環境変数の整理（Rust VM と LLVM ハーネス両方）
3. 実行結果（成功 / 失敗 / 既知問題）を 1 つの docs にまとめる
4. CURRENT_TASK / Backlog に「JoinIR→LLVM 第3章の入り口」を追記
### ❌ やらないこと
- LLVM 側の実装修正（Phase 131 以降の役割）
- 新しい最適化パスやコード生成ルールの追加
- JoinIR / Ring0 の設計変更
---
## 🏗️ Task 1: 代表ケース選定（完了）✅
Phase 130 では以下の **7 本** を代表ケースとして選定しました：
| # | カテゴリ | ファイル | 用途 | 選定理由 |
|---|---------|---------|-----|---------|
| 1 | selfhost Stage-3 | `apps/tests/peek_expr_block.hako` | 式ブロック・peek構文 | Phase 120で検証済み、基本的な式評価 |
| 2 | selfhost Stage-3 | `apps/tests/loop_min_while.hako` | ループ・条件分岐 | Phase 120で検証済み、ループとPHI |
| 3 | selfhost Stage-3 | `apps/tests/esc_dirname_smoke.hako` | ConsoleBox.println・複合処理 | Phase 120/122で検証済み、複雑な制御フロー |
| 4 | hako_check / Phase 123 | `local_tests/phase123_simple_if.hako` | シンプルなif文 | Phase 124でJoinIR専用化テスト済み |
| 5 | hako_check / Phase 123 | `local_tests/phase123_while_loop.hako` | while loop | Phase 124でJoinIR専用化テスト済み |
| 6 | JoinIR/PHI | `apps/tests/joinir_if_select_simple.hako` | IfSelect（単純） | JoinIR If Lowering基本ケース |
| 7 | JoinIR/PHI | `apps/tests/joinir_min_loop.hako` | 最小ループ | JoinIR Loop基本ケース |
### 選定基準
- **多様性**: selfhost/hako_check/JoinIR の3カテゴリから選定
- **段階性**: 基本→複雑の順でカバー
- **実績**: Phase 120-124 で検証済みのケースを優先
- **LLVM適合性**: Console/StringBox/基本制御フローを含む
---
## 🔧 Task 2: LLVM 実行コマンドの整理
### 環境変数一覧
| 環境変数 | 用途 | 必須 |
|---------|-----|------|
| `NYASH_LLVM_USE_HARNESS=1` | Python/llvmlite ハーネス使用 | ✅ LLVM実行時必須 |
| `LLVM_SYS_180_PREFIX=$(llvm-config-18 --prefix)` | LLVM 18 設定 | ✅ LLVM実行時必須 |
### 実行コマンド例
#### Rust VM 実行（比較用）
```bash
./target/release/nyash --backend vm apps/tests/peek_expr_block.hako
```
#### LLVM ハーネス実行
```bash
LLVM_SYS_180_PREFIX=$(llvm-config-18 --prefix) \
NYASH_LLVM_USE_HARNESS=1 \
./target/release/nyash --backend llvm apps/tests/peek_expr_block.hako
```
#### 統合スモークテスト（v2プロファイル）
```bash
# 全integration テスト
./tools/smokes/v2/run.sh --profile integration
# Phase 120 stable paths（Rust VM）
./tools/smokes/v2/run.sh --profile integration --filter "*phase120_stable_paths*"
```
### 各代表ケースの実行方法
代表ケースごとに、以下の2パターンで実行：
1. **Rust VM**（比較軸・greenベースライン）:
```bash
./target/release/nyash --backend vm <HAKO_FILE>
```
2. **LLVM harness**（観測対象）:
```bash
LLVM_SYS_180_PREFIX=$(llvm-config-18 --prefix) \
NYASH_LLVM_USE_HARNESS=1 \
./target/release/nyash --backend llvm <HAKO_FILE>
```
---
## 📊 Task 3: 実行結果とベースライン記録
### 凡例
- ✅ PASS: 正常終了、期待される出力
- ⚠️ PARTIAL: 部分的に動作、警告あり
- ❌ FAIL: エラーで失敗
---
### 1. apps/tests/peek_expr_block.hako
**期待される挙動**: peek式を使ったブロック式評価（match式、ブロック式で値を返す）
**実行結果**:
| 経路 | 結果 | メモ |
|--------------|-------|------|
| Rust VM | ✅ | 正常動作。"found one"出力、RC=1（main関数の戻り値） |
| LLVM harness | ⚠️ | Mock backend使用中。MIRコンパイル成功、実LLVM実行は未対応 |
**VM出力**: `found one`, `RC: 1`
---
### 2. apps/tests/loop_min_while.hako
**期待される挙動**: 最小限のwhile loop、PHI命令生成
**実行結果**:
| 経路 | 結果 | メモ |
|--------------|-------|------|
| Rust VM | ✅ | 正常動作。ループ（0,1,2出力）、ControlForm::Loop生成確認 |
| LLVM harness | ⚠️ | Mock backend使用中。MIRコンパイル成功、実LLVM実行は未対応 |
**VM出力**: `0`, `1`, `2`, `RC: 0`
---
### 3. apps/tests/esc_dirname_smoke.hako
**期待される挙動**: ConsoleBox.println、StringBox操作、複雑な制御フロー
**実行結果**:
| 経路 | 結果 | メモ |
|--------------|-------|------|
| Rust VM | ❌ | ConsoleBox未対応エラー: "Unknown Box type: ConsoleBox" |
| LLVM harness | ⚠️ | Mock backend使用中。MIRコンパイル成功、実LLVM実行は未対応 |
**VMエラー**: `[ERROR] ❌ [rust-vm] VM error: Invalid instruction: NewBox ConsoleBox: invalid operation: Unknown Box type: ConsoleBox. Available: Main`
**根本原因**: ConsoleBoxがRust VM環境で登録されていない（PluginBox問題）
---
### 4. local_tests/phase123_simple_if.hako
**期待される挙動**: シンプルなif文のJoinIR lowering
**実行結果**:
| 経路 | 結果 | メモ |
|--------------|-------|------|
| Rust VM | ✅ | 正常動作。JoinIR If lowering成功、RC=0 |
| LLVM harness | ⚠️ | Mock backend使用中。MIRコンパイル成功、実LLVM実行は未対応 |
**VM出力**: `RC: 0`
---
### 5. local_tests/phase123_while_loop.hako
**期待される挙動**: while loopのJoinIR lowering
**実行結果**:
| 経路 | 結果 | メモ |
|--------------|-------|------|
| Rust VM | ✅ | 正常動作。ControlForm::Loop生成、RC=0 |
| LLVM harness | ⚠️ | Mock backend使用中。MIRコンパイル成功、実LLVM実行は未対応 |
**VM出力**: `RC: 0`
---
### 6. apps/tests/joinir_if_select_simple.hako
**期待される挙動**: IfSelectパターンの基本ケース
**実行結果**:
| 経路 | 結果 | メモ |
|--------------|-------|------|
| Rust VM | ✅ | 正常動作。JoinIR If Lowering実装済み、RC=0 |
| LLVM harness | ⚠️ | Mock backend使用中。MIRコンパイル成功、実LLVM実行は未対応 |
**VM出力**: `RC: 0`
---
### 7. apps/tests/joinir_min_loop.hako
**期待される挙動**: JoinIR最小ループケース
**実行結果**:
| 経路 | 結果 | メモ |
|--------------|-------|------|
| Rust VM | ✅ | 正常動作。ControlForm::Loop（breakブロック含む）生成、RC=0 |
| LLVM harness | ⚠️ | Mock backend使用中。MIRコンパイル成功、実LLVM実行は未対応 |
**VM出力**: `RC: 0`
---
## 📈 実行結果サマリー
### 統計
| 経路 | PASS | PARTIAL | FAIL | 合計 | 成功率 |
|--------------|------|---------|------|------|--------|
| Rust VM | 6 | 0 | 1 | 7 | 85.7% |
| LLVM harness | 0 | 7 (Mock)| 0 | 7 | 0% (Mock実行) |
**Rust VM結果詳細**:
- ✅ PASS: 6/7 (peek_expr_block, loop_min_while, phase123_simple_if, phase123_while_loop, joinir_if_select_simple, joinir_min_loop)
- ❌ FAIL: 1/7 (esc_dirname_smoke - ConsoleBox未対応)
**LLVM harness結果詳細**:
- ⚠️ 全テストがMock backend実行（実LLVM実行は未対応）
- ✅ MIRコンパイルは全7テストで成功
- ❌ 実際のLLVM IR生成・実行は未実装
### 検出された問題点
#### 1. LLVM Backend未対応（最重要）
**現象**:
```
🔧 Mock LLVM Backend Execution:
Build with --features llvm-inkwell-legacy for Rust/inkwell backend,
or set NYASH_LLVM_OBJ_OUT and NYASH_LLVM_USE_HARNESS=1 for harness.
✅ Mock exit code: 0
```
**原因**:
- `--backend llvm` 指定時、Mock backendにフォールバック
- 実際のLLVM IR生成・実行機構が無効化されている
- `--features llvm` ビルドが必要（未実施）
**影響範囲**: 全7テストケース
**Phase 131での対応**:
1. `cargo build --release --features llvm` でLLVM機能有効化ビルド
2. Python/llvmlite ハーネス（`src/llvm_py/`）の動作確認
3. 実LLVM実行での再テスト
---
#### 2. ConsoleBox未登録問題
**現象**: `apps/tests/esc_dirname_smoke.hako`
```
[ERROR] ❌ [rust-vm] VM error: Invalid instruction: NewBox ConsoleBox:
invalid operation: Unknown Box type: ConsoleBox. Available: Main
```
**原因**:
- Rust VM環境でConsoleBoxが登録されていない
- PluginBox（Console）とビルトインBoxの登録問題
- Phase 15.5の "Everything is Plugin" 方針と衝突
**影響範囲**:
- esc_dirname_smoke.hako（Console出力を使用）
- 他の複雑な制御フローテスト（潜在的）
**Phase 131での対応**:
1. ConsoleBoxのVM登録確認
2. PluginBox vs ビルトインBoxの登録優先順位整理
3. Phase 120/122で解決済みのはずだが、環境依存の可能性
---
#### 3. JoinIR → LLVM経路の不明確性
**観測事実**:
- JoinIR → MIR変換: ✅ 全テストで成功
- MIR → LLVM IR: ⚠️ Mock実行（未検証）
- LLVM実行: ❌ 未対応
**Phase 131での確認事項**:
1. `ny-llvmc` コンパイラの状態確認
2. Python/llvmlite ハーネスの動作確認
3. MIR14命令 → LLVM IR lowering実装状況
4. BoxCall/NewBox/PHI命令のLLVM対応
---
### Phase 131への引き継ぎ事項
#### 優先度1: LLVM Backend有効化
- [ ] `cargo build --release --features llvm` 実行
- [ ] Python/llvmlite 環境確認（`src/llvm_py/venv`）
- [ ] 実LLVM実行での7テスト再実行
#### 優先度2: ConsoleBox問題解決
- [ ] Rust VMでのConsoleBox登録状況調査
- [ ] Phase 122で解決済みの内容との差分確認
- [ ] PluginBox登録機構の修正（必要に応じて）
#### 優先度3: LLVM IR生成確認
- [ ] MIR → LLVM IR lowering実装状況調査
- [ ] 未対応命令の洗い出し（BoxCall/NewBox/PHI等）
- [ ] 最小ケース（joinir_if_select_simple.hako）での詳細検証
---
## 🚀 Task 4: CURRENT_TASK / Backlog 更新（完了）✅
**実施内容**:
1. **CURRENT_TASK.md更新**:
- Phase 130 セクション追加（実施日: 2025-12-04）
- 実行結果統計（Rust VM: 6/7 PASS、LLVM: 0/7 Mock実行）
- 検出された3つの問題点の記録
- Phase 131への引き継ぎ事項を明記
2. **30-Backlog.md更新**:
- 短期タスクを「第3章 - LLVM統合」に更新
- Phase 131の3つの優先度タスクを追加
- Phase 120-124を「完了済み第2章」に移動
---
## ✅ 完成チェックリスト（Phase 130）
- [x] `phase130_joinir_llvm_baseline.md` が存在し、代表パス/コマンド/結果が整理されている
- [x] 7 本の .hako が選定され、ドキュメントに記載されている
- [x] 各ケースが「Rust VM / LLVM backend」両方で実行されている
- [x] 実行結果の表が表形式で docs に記載されている
- [x] **実装修正は一切入れていない**（赤は赤のまま、一覧化だけしている）
- [x] CURRENT_TASK.md に Phase 130 完了行が追加されている
- [x] Backlog に「Phase 131: JoinIR→LLVM 個別修正ライン」が追加されている
- [x] git commit で記録（コミット: 43d59110 `docs(phase130): JoinIR→LLVM ベースライン確立`）
---
## 📋 次のステップ
**Phase 131: JoinIR→LLVM 個別修正ライン** - Phase 130 で検出された問題を優先度順に潰す
---
## 📝 進捗
- ✅ Phase 124: hako_check レガシー削除 & JoinIR 専用化（完了）
- ✅ Phase 56: array_ext.filter JoinIR 対応（テスト修正完了）
- ✅ Phase 130: JoinIR → LLVM ベースライン確立（← **完了！** 2025-12-04）
- ✅ Task 1: 代表ケース選定（7本選定完了）
- ✅ Task 2: LLVM実行コマンド整理（完了）
- ✅ Task 3: 実行とベースライン記録（完了）
- Rust VM: 6/7 PASS (85.7%)
- LLVM: 0/7実行（Mock backend、要`--features llvm`ビルド）
- 🔄 Task 4: ドキュメント更新（実行中）
- 📋 Phase 131+: JoinIR→LLVM 個別修正ライン（予定）
### Phase 130実行結果サマリー
**Rust VM（--backend vm）**:
- ✅ 6/7テストPASS（85.7%成功率）
- ❌ 1/7失敗: esc_dirname_smoke.hako（ConsoleBox未登録問題）
**LLVM harness（--backend llvm）**:
- ⚠️ 7/7テストがMock backend実行（実LLVM未対応）
- ✅ MIRコンパイルは全て成功
- ❌ `--features llvm` ビルドが必要と判明
**重要な発見**:
1. LLVM backend機能が現在のビルドで無効化されている
2. ConsoleBoxのRust VM登録問題が再発
3. JoinIR → MIR変換は全て正常動作
4. Phase 131での優先課題が明確化
---
## Phase 131 修正内容（2025-12-04実施）
### 修正1: LLVM Backend Re-enable ✅
**実施内容**:
1. `cargo build --release --features llvm` でLLVM機能有効化ビルド実行
2. Python/llvmlite環境確認（llvmlite 0.45.1インストール済み）
3. llvmlite非推奨API対応: `llvm.initialize()` 削除（自動初期化に移行）
**修正ファイル**:
- `src/llvm_py/llvm_builder.py`: `llvm.initialize()` 呼び出しをコメントアウト
**結果**:
- ✅ `peek_expr_block.hako`: LLVM実行成功（Result: 1、Rust VM: RC: 1）
- ✅ Mock backendから実LLVM実行への移行成功
- ✅ LLVM harness経路が正常動作
### 修正2: PHI命令順序バグ発見 ⚠️
**検出された問題**:
LLVM IR生成時、PHI命令がreturn命令の**後**に配置されるバグを発見。
**問題例**（生成されたLLVM IR）:
```llvm
bb5:
ret i64 %"ret_phi_16"
%"ret_phi_16" = phi i64 [0, %"bb3"], [0, %"bb4"] ; ← エラー！PHIはretの前に必要
}
```
**LLVM IRの制約**:
- PHI命令はBasic Blockの**先頭**に配置必須
- terminator命令（ret/br/switch等）の後に命令を配置不可
**影響範囲**:
- ❌ phase123_simple_if.hako: LLVM IR parsing error
- ❌ loop_min_while.hako: LLVM IR parsing error
- ❌ 制御フロー合流を含む全テストが影響
**根本原因**:
- `src/llvm_py/llvm_builder.py`の`finalize_phis()`関数
- PHI nodesがblock終端処理後に追加されている
- LLVM IRbuilderのblock構築順序の設計問題
**Phase 132への引き継ぎ**:
この問題は`finalize_phis()`の大規模リファクタリングが必要（100行以上の関数）。
Phase 131の最小スコープを超えるため、Phase 132で対応。
### 修正3: ConsoleBox LLVM統合 ⚠️
**現状確認**:
- ❌ Rust VM環境でもConsoleBox未登録（`apps/tests/esc_dirname_smoke.hako`実行不可）
- ❌ LLVM環境でもConsoleBox未対応
**Phase 132への引き継ぎ**:
ConsoleBoxの登録・実装はRust VM側の問題。LLVM統合の前提条件未達のため、Phase 132で対応。
### Phase 131 実行結果サマリー
**修正前（Phase 130）**:
| 経路 | PASS | PARTIAL | FAIL | 成功パス |
|--------------|------|---------|------|---------|
| Rust VM | 6 | 0 | 1 | 6/7 |
| LLVM harness | 0 | 7 (Mock)| 0 | 0/7 |
**修正後（Phase 131）**:
| 経路 | PASS | PARTIAL | FAIL | 成功パス | メモ |
|--------------|------|---------|------|---------|------|
| Rust VM | 6 | 0 | 1 | 6/7 | 変更なし |
| LLVM harness | 1 | 0 | 6 | 1/7 | peek_expr_block.hako成功 |
**成功ケース詳細**:
- ✅ `peek_expr_block.hako`: Rust VM ✅ → LLVM ✅（Result: 1）
**失敗ケース詳細**:
- ❌ `loop_min_while.hako`: PHI ordering bug
- ❌ `phase123_simple_if.hako`: PHI ordering bug
- ❌ `phase123_while_loop.hako`: PHI ordering bug
- ❌ `joinir_if_select_simple.hako`: PHI ordering bug
- ❌ `joinir_min_loop.hako`: PHI ordering bug
- ❌ `esc_dirname_smoke.hako`: ConsoleBox未登録
### Phase 131 完了判定
**達成内容**:
1. ✅ LLVM backend最小re-enable成功（peek_expr_block.hako ✅）
2. ⚠️ PHI ordering bug発見・記録（Phase 132対応）
3. ⚠️ ConsoleBox問題確認（Phase 132対応）
**最小成功パス確立**: ✅ 1/7テストで成功（目標：2-3本だが、根本的なPHI問題により1本に制限）
**Phase 132への優先課題**:
1. **最優先**: PHI命令順序バグ修正（`finalize_phis()`リファクタリング）
2. **優先**: ConsoleBox登録問題解決
3. **通常**: 残りテストケースのLLVM対応
Status: Historical

285
docs/archive/phases/phase-106-156/phase131_joinir_llvm_fixes.md Normal file
View File

@ -0,0 +1,285 @@
# Phase 131: JoinIR → LLVM 個別修正ライン（最小スコープ）
## 🎯 ゴール
Phase 130 で観測した LLVM 側の「赤ポイント3つ」を、**設計を崩さずピンポイントで修正** するフェーズ。
目的：
- LLVM backend の最小 re-enable（代表1本を green に）
- ConsoleBox の LLVM ライン統一（println/log 出力）
- JoinIR→MIR→LLVM の成功パス確立（JoinIR含み1本を green に）
```
Phase 130: 赤ポイント3つを「観測・リスト化」✅
↓
Phase 131: その3つを「ピンポイント修正」← ← ここ！
↓
JoinIR/LLVM 第3章クローズ準備完了
```
---
## 📋 スコープ（Phase 130 で見えた3点だけ）
Phase 130 で検出された問題：
1. **LLVM backend 機能が無効化中** → 最小 re-enable で1本 green に
2. **ConsoleBox の LLVM ライン登録・出力経路** → LLVM runtime レイヤで統一
3. **JoinIR→MIR は OK、MIR→LLVM は未検証** → JoinIR含みケース1本を成功させる
### ✅ やること
- LLVM backend の現状確認と最小 re-enable
- ConsoleBox の LLVM 出力経路整備
- JoinIR含みケース1本の LLVM 実行成功
### ❌ やらないこと
- 全7本のテストケースを green にする（1-2本で十分）
- LLVM最適化パスの追加
- 大規模な設計変更
---
## 🏗️ 4 つのタスク
### Task 1: LLVM backend の現状確認 & 最小 re-enable
**目標**: 代表1本（`peek_expr_block.hako`）を LLVM ハーネスで green にする
**やること**:
1. **LLVM backend 設定の確認**:
```bash
# Cargo.toml で llvm feature の定義確認
rg "features.*llvm" Cargo.toml
# 現在のビルド確認
./target/release/nyash --version
```
2. **LLVM feature 付きビルド**:
```bash
cargo build --release --features llvm
```
- ビルドエラーがあれば記録（Phase 130 docs に追記）
- 成功すれば次へ
3. **Python/llvmlite 環境確認**:
```bash
# llvmlite ハーネス確認
ls -la src/llvm_py/venv/
# 無ければ再構築
cd src/llvm_py
python3 -m venv venv
./venv/bin/pip install llvmlite
cd ../..
```
4. **代表1本を LLVM 実行**:
```bash
# peek_expr_block.hako を LLVM で実行
LLVM_SYS_180_PREFIX=$(llvm-config-18 --prefix) \
NYASH_LLVM_USE_HARNESS=1 \
./target/release/nyash --backend llvm apps/tests/peek_expr_block.hako
```
- ✅ green なら Task 1 完了
- ❌ 赤なら、エラーメッセージを docs に記録して次の Task へ
5. **Phase 130 docs 更新**:
- `phase130_joinir_llvm_baseline.md` の結果表を更新
- LLVM backend の re-enable 手順を記録
---
### Task 2: ConsoleBox の LLVM ライン整合
**目標**: ConsoleBox の println/log を LLVM runtime レイヤで統一
**やること**:
1. **Rust VM での ConsoleBox 登録確認**:
```bash
# TypeRegistry で ConsoleBox の println/log スロット確認
rg "ConsoleBox.*println" src/runtime/type_registry.rs
# Phase 122 の変更内容確認
rg "Phase 122" docs/development/current/main/
```
2. **LLVM runtime での ConsoleBox 対応**:
- 候補A: LLVM ハーネス側で print/log 外部関数を追加
- 候補B: LLVM backend に println/log の簡易実装を追加
- **推奨**: 候補A（Python ハーネス側での外部関数実装）
3. **Python ハーネス修正**（推奨アプローチ）:
```python
# src/llvm_py/llvm_builder.py または runtime.py
# extern_print 関数を追加（既存の print 処理を流用）
def extern_println(msg):
print(f"[Console LOG] {msg}")
# LLVM IR 生成時に externCall("println", ...) を処理
```
4. **検証**:
```bash
# esc_dirname_smoke.hako を LLVM で実行
LLVM_SYS_180_PREFIX=$(llvm-config-18 --prefix) \
NYASH_LLVM_USE_HARNESS=1 \
./target/release/nyash --backend llvm apps/tests/esc_dirname_smoke.hako
```
- 期待出力: `[Console LOG] dir1/dir2`
5. **Phase 130 docs 更新**:
- ConsoleBox の LLVM 対応状況を記録
---
### Task 3: JoinIR→MIR→LLVM の成功パス確立
**目標**: JoinIR含みケース1本を LLVM で green にする
**やること**:
1. **JoinIR含みケースの選定**:
- 候補1: `local_tests/phase123_simple_if.hako`（シンプルな if）
- 候補2: `apps/tests/joinir_if_select_simple.hako`（IfSelect）
- **推奨**: `phase123_simple_if.hako`（軽量で検証しやすい）
2. **Rust VM での確認**（比較用）:
```bash
./target/release/nyash --backend vm local_tests/phase123_simple_if.hako
# 出力: RC: 0
```
3. **LLVM 実行**:
```bash
LLVM_SYS_180_PREFIX=$(llvm-config-18 --prefix) \
NYASH_LLVM_USE_HARNESS=1 \
./target/release/nyash --backend llvm local_tests/phase123_simple_if.hako
```
4. **エラー対応**:
- JoinIR → MIR 変換: ✅ Phase 130 で確認済み（問題なし）
- MIR → LLVM IR: ここでエラーが出る可能性
- 未対応命令（BoxCall/NewBox/PHI）があれば記録
- 軽微な修正（1-2箇所）なら対応
- 大規模修正が必要なら Phase 132 に回す
5. **成功条件**:
- ✅ JoinIR含みケース1本が LLVM で実行成功
- または
- ⚠️ 未対応命令を特定して docs に記録（修正は Phase 132）
---
### Task 4: ドキュメント & CURRENT_TASK 更新
**やること**:
1. **phase130_joinir_llvm_baseline.md 更新**:
```markdown
## Phase 131 修正内容
### LLVM backend re-enable
- ✅ `cargo build --release --features llvm` 成功
- ✅ peek_expr_block.hako: Rust VM ✅ → LLVM ✅
### ConsoleBox LLVM 統合
- ✅ Python ハーネス側で println/log 外部関数実装
- ✅ esc_dirname_smoke.hako: Rust VM ✅ → LLVM ✅
### JoinIR→LLVM 成功パス
- ✅ phase123_simple_if.hako: Rust VM ✅ → LLVM ✅
- または
- ⚠️ 未対応: [具体的な命令名] → Phase 132 対応予定
### 修正後の結果表
| .hako ファイル | Rust VM | LLVM (Phase 130) | LLVM (Phase 131) | メモ |
|---|---|---|---|---|
| peek_expr_block.hako | ✅ | ❌ | ✅ | re-enable 成功 |
| esc_dirname_smoke.hako | ❌ | ❌ | ✅ | ConsoleBox 統合 |
| phase123_simple_if.hako | ✅ | ❌ | ✅ or ⚠️ | JoinIR パス |
```
2. **CURRENT_TASK.md 更新**:
```markdown
### Phase 131: JoinIR → LLVM 個別修正ライン ✅
**完了内容**:
- LLVM backend 最小 re-enable（peek_expr_block.hako ✅）
- ConsoleBox LLVM 統合（esc_dirname_smoke.hako ✅）
- JoinIR→LLVM 成功パス確立（phase123_simple_if.hako ✅ or ⚠️）
**修正箇所**:
- Cargo.toml: llvm feature 確認
- src/llvm_py/*: ConsoleBox println/log 外部関数追加
- [その他、修正したファイルを列挙]
**テスト結果**:
- 修正前: LLVM 0/7 実行可能
- 修正後: LLVM 2-3/7 実行可能（最小成功パス確立）
**成果**:
- JoinIR → LLVM 経路の基本導線が動作確認できた
- Phase 132 以降で残りのケースを green にする準備完了
**次フェーズ**: Phase 132 - LLVM 未対応命令の個別対応（必要に応じて）
```
3. **30-Backlog.md 更新**:
```markdown
### Phase 132: LLVM 未対応命令の個別対応（必要時）
Phase 131 で未解決の問題：
- [Phase 131 で検出された未対応命令を列挙]
- 例: BoxCall の特定メソッド、PHI の特殊ケース等
または、Phase 131 で全て解決した場合：
- ✅ JoinIR → LLVM 第3章クローズ
- 次: selfhost Stage-4 拡張 or 次の大型改善へ
```
---
## ✅ 完成チェックリスト（Phase 131）
- [ ] LLVM backend が `--features llvm` でビルド成功
- [ ] Python/llvmlite 環境が構築済み
- [ ] peek_expr_block.hako が LLVM で実行成功（✅）
- [ ] esc_dirname_smoke.hako が LLVM で実行成功（✅、ConsoleBox 出力確認）
- [ ] phase123_simple_if.hako が LLVM で実行成功（✅ or ⚠️ + 問題記録）
- [ ] phase130_joinir_llvm_baseline.md に Phase 131 修正内容追記
- [ ] CURRENT_TASK.md に Phase 131 完了行追加
- [ ] 30-Backlog.md 更新（Phase 132 予告 or クローズ宣言）
- [ ] git commit で記録
---
## 所要時間
**6〜8 時間程度**
- Task 1 (LLVM backend re-enable): 2時間
- Task 2 (ConsoleBox 統合): 2時間
- Task 3 (JoinIR→LLVM 成功パス): 2〜3時間
- Task 4 (ドキュメント更新): 1時間
---
## 次のステップ
**Phase 132 or クローズ判断**:
- Phase 131 で全て解決 → JoinIR→LLVM 第3章クローズ
- Phase 131 で未解決問題あり → Phase 132 で個別対応
---
## 進捗
- ✅ Phase 130: JoinIR → LLVM ベースライン確立（完了）
- 🎯 Phase 131: JoinIR → LLVM 個別修正ライン（← **現在のフェーズ**）
- 📋 Phase 132: LLVM 未対応命令の個別対応（必要に応じて）
Status: Historical

430
docs/archive/phases/phase-106-156/phase132_llvm_phi_ordering.md Normal file
View File

@ -0,0 +1,430 @@
# Phase 132: LLVM finalize_phis の順序バグ修正
## 🎯 ゴール
LLVM backend における **「PHI 命令の配置順序バグ」を構造的に修正** する。
目的：
- JoinIR→MIR→LLVM の意味論・制御構造は一切変えず、**「PHI はブロック先頭に並ぶ」という LLVM 規約** を満たす
- 修正範囲は LLVM backend の finalize_phis 周辺に限定し、JoinIR/Ring0 には触らない
- 代表ケース 6/7 で LLVM 実行が Rust VM と一致することを確認
```
Phase 131: LLVM backend re-enable（1/7成功、PHI問題発見）✅
↓
Phase 132: PHI順序バグ構造的修正 ← ← ここ！
↓
Phase 133: 残りのLLVM統合タスク
```
---
## 📋 スコープ（やること・やらないこと）
### ✅ やること
- LLVM の PHI 命令生成・配置ロジック（finalize_phis 相当）を箱として整理
- 常に **「ブロック先頭に PHI が並ぶ」** 順序にする
- 代表ケース（Phase 130/131 で失敗していた 6/7）で LLVM 実行確認
- docs に「PHI 順序の設計と仕様」を明記
### ❌ やらないこと
- 新しい opcode の追加や、JoinIR/MIR の意味論変更
- FileBox/Ring0 や logging まわりには触れない
- LLVM backend 全体の最適化や再設計（PHI 順序に限定）
---
## 🏗️ 6 つのタスク
### Task 1: 設計ドキュメント作成
**ファイル**: `docs/development/current/main/phase132_llvm_phi_ordering.md`（このファイル）
**書く内容**:
#### LLVM の PHI 規則（簡潔版）
- 各 BasicBlock では **「ラベル直後の連続した PHI 群」** が必須
- PHI は同一ブロック内の他の命令より **前** に来なければならない
- return や branch の **後** に PHI を置くのは仕様違反
#### 現状の問題点
Phase 131 で観測した問題：
```llvm
bb5:
ret i64 %"ret_phi_16"
%"ret_phi_16" = phi i64 [0, %"bb3"], [0, %"bb4"] ; ❌ エラー！PHIはretの前に必要
}
```
**原因**: `finalize_phis()` が「既存の末尾命令（terminator）の後ろに PHI を突っ込んでいる」
#### 目指す構造
**PhiPlacement 責務箱** で「1ブロック内の (phi, non-phi) を再配置」する：
1. **分離**: 既存命令列を「仮想 PHI 命令」と「それ以外」に分離
2. **クリア**: ブロックを一旦クリア
3. **再構築**: 先に PHI 群を順に挿入、その後に非 PHI 命令を挿入
4. **terminator 維持**: terminator（ret/br）は必ず非 PHI 群の末尾に維持
#### アルゴリズム方針（2案）
**案A**: 命令順序の後処理（推奨）
- 各 LLVM BasicBlock について、生成後に命令順序を再配置
- PHI 群 → 非 PHI 群 → terminator の順に並べ替え
**案B**: 生成時点での順序保証
- PHI を生成する時点で「必ず insert_at_beginning 的な API」を使う
- 生成タイミングを制御して順序を保証
**Phase 132 では案A を採用**（実装が明確で、既存コードへの影響が小さい）
---
### Task 2: 既存 finalize_phis 実装の棚卸し
**対象ファイル**: `src/llvm_py/llvm_builder.py`（Phase 131 で特定済み）
**やること**:
1. **finalize_phis 関数の詳細確認**:
```bash
rg "def finalize_phis" src/llvm_py/
```
- 約100行の関数
- どのタイミングで LLVM IR に PHI を挿入しているか確認
- どのブロックに対して、どの API で PHI を追加しているか記録
2. **PHI 情報の元データ確認**:
- MIR JSON から PHI 情報を取得している部分を特定
- Builder の一時バッファ（pending phi list 等）の所在を確認
3. **呼び出し経路の確認**:
- どのフェーズで finalize_phis が呼ばれているか
- 複数回呼ばれていないか（2重呼び出しの危険性）
---
### Task 3: PhiPlacement 責務箱の実装
**方針**: finalize_phis の「命令順序入れ替え責務」を専用の関数/クラスに閉じ込める
**実装箇所**: `src/llvm_py/phi_placement.py`（新規）または `llvm_builder.py` 内の関数
**責務**:
- 引数: 単一の LLVM BasicBlock（または block + pending phi list）
- 動作:
- そのブロック内の命令列を走査し、「PHI 相当」と「それ以外」を分類
- 新しい命令順序（PHI 群 → 非 PHI 群）に組み直す
- **PHI の内容は一切触らない。順序だけ直す。**
**実装パターン**:
```python
def reorder_phi_instructions(block, phi_nodes):
"""
LLVM BasicBlock 内の命令順序を PHI-first に並べ替え
Args:
block: LLVM BasicBlock
phi_nodes: このblockに属するPHI命令のリスト
Returns:
再配置されたblock
"""
# 1. 既存命令を分類
non_phi_instructions = []
terminator = None
for instr in block.instructions:
if is_terminator(instr):
terminator = instr
elif not is_phi(instr):
non_phi_instructions.append(instr)
# 2. Block をクリア（または新しいblockを作成）
new_block = create_empty_block(block.name)
# 3. PHI群を先頭に挿入
for phi in phi_nodes:
new_block.append(phi)
# 4. 非PHI命令を挿入
for instr in non_phi_instructions:
new_block.append(instr)
# 5. Terminator を最後に挿入
if terminator:
new_block.append(terminator)
return new_block
```
**注意点**:
- llvmlite の API に応じて実装を調整
- 既存の finalize_phis から「PHI 生成ロジック」と「配置ロジック」を分離
- 生成ロジックはそのまま、配置ロジックだけを新関数に移す
---
### Task 4: finalize_phis 呼び出し経路の整理
**やること**:
1. **呼び出し位置の確認**:
```bash
rg "finalize_phis" src/llvm_py/
```
- LLVM lowering のどのフェーズで呼ばれているか
- 関数生成の最後か、ブロック生成の途中か
2. **ルール設定**:
- 各関数（または各 BasicBlock）で、PHI 生成が完了した後、**必ず PhiPlacement を通す**
- 2重に呼ばない／途中で呼びかけて順序を壊さないように、呼び出し位置を一箇所にまとめる
3. **位置付け**:
- JoinIR / MIR 側には一切触れず、**「LLVM 出力直前の最後の整形処理」** として位置付ける
---
### Task 5: テスト追加（LLVM 専用）
**代表ケース**:
Phase 130/131 で「Rust VM OK, LLVM NG」だったケース：
- `local_tests/phase123_simple_if.hako`（シンプルな if）
- `local_tests/phase123_while_loop.hako`（while loop）
- `apps/tests/loop_min_while.hako`（最小ループ）
- `apps/tests/joinir_if_select_simple.hako`（IfSelect）
**テスト戦略**:
1. **LLVM IR 検証**（可能なら）:
- MIR → LLVM IR 生成時に、各ブロックの PHI が先頭に並んでいるかチェック
- LLVM IR の text dump をパースして簡易検証
2. **実行結果検証**（必須）:
```bash
# 各テストケースで Rust VM と LLVM の両方を実行
./target/release/nyash --backend vm local_tests/phase123_simple_if.hako
LLVM_SYS_180_PREFIX=$(llvm-config-18 --prefix) \
NYASH_LLVM_USE_HARNESS=1 \
./target/release/nyash --backend llvm local_tests/phase123_simple_if.hako
# 結果が一致することを確認
```
3. **複雑なケース**:
- loop + if など、PHI 構造が複雑なケース 1 本を確認
- 例: `apps/tests/joinir_min_loop.hako`
---
### Task 6: ドキュメント & CURRENT_TASK 更新
**やること**:
1. **このファイル（phase132_llvm_phi_ordering.md）の末尾に追記**:
```markdown
## Phase 132 実装結果
### 修正ファイル
- `src/llvm_py/llvm_builder.py`: finalize_phis() 修正
- `src/llvm_py/phi_placement.py`: 新規作成（または llvm_builder.py 内の関数）
### テスト結果
| ケース | Rust VM | LLVM (Phase 131) | LLVM (Phase 132) |
|--------|---------|------------------|------------------|
| phase123_simple_if.hako | ✅ | ❌ | ✅ |
| phase123_while_loop.hako | ✅ | ❌ | ✅ |
| loop_min_while.hako | ✅ | ❌ | ✅ |
| joinir_if_select_simple.hako | ✅ | ❌ | ✅ |
### 成果
- PHI 順序バグの構造的修正完了
- LLVM backend の基本整合が取れた
- 6/7 テストが LLVM で実行成功（残り1つは ConsoleBox 問題）
```
2. **CURRENT_TASK.md 更新**:
```markdown
### Phase 132: LLVM PHI 命令順序バグ修正 ✅
**完了内容**:
- finalize_phis() の構造的リファクタリング
- PHI 命令をブロック先頭に配置する PhiPlacement 実装
- 代表ケース 6/7 で LLVM 実行成功
**修正箇所**:
- src/llvm_py/llvm_builder.py: PHI生成・配置ロジック分離
- src/llvm_py/phi_placement.py: 新規作成（または関数追加）
**テスト結果**:
- 修正前: LLVM 1/7 実行可能
- 修正後: LLVM 6/7 実行可能（PHI順序問題解決）
**成果**:
- JoinIR → LLVM 経路の基本動作確認完了
- Phase 133 で ConsoleBox 統合を完了すれば 7/7 達成
**次フェーズ**: Phase 133 - ConsoleBox LLVM 統合 & 残りタスク
```
3. **30-Backlog.md 更新**:
```markdown
### Phase 133: ConsoleBox LLVM 統合 & JoinIR→LLVM 完成
Phase 132 で PHI 順序問題解決、残りタスク：
- ConsoleBox の Rust VM 登録確認
- ConsoleBox の LLVM 統合（println/log 外部関数）
- 全7テストケースで LLVM 実行成功確認
完了条件：
- ✅ 7/7 テストが Rust VM と LLVM で実行成功
- ✅ JoinIR → LLVM 第3章クローズ
```
---
## ✅ 完成チェックリスト（Phase 132）
- [ ] LLVM PHI 規則の設計ドキュメント作成
- [ ] finalize_phis() 実装の詳細確認（約100行）
- [ ] PhiPlacement 責務箱の実装（新関数 or 新ファイル）
- [ ] PHI 命令をブロック先頭に配置するロジック実装
- [ ] finalize_phis 呼び出し経路の整理
- [ ] 代表ケース 4-6 本で LLVM 実行成功確認
- [ ] phase132_llvm_phi_ordering.md に実装結果追記
- [ ] CURRENT_TASK.md & Backlog 更新
- [ ] git commit で記録
---
## 所要時間
**3〜4 時間程度**
- Task 1-2 (設計ドキュメント & 棚卸し): 1時間
- Task 3 (PhiPlacement 実装): 1.5時間
- Task 4-5 (呼び出し整理 & テスト): 1時間
- Task 6 (ドキュメント更新): 30分
---
## 次のステップ
**Phase 133: ConsoleBox LLVM 統合 & JoinIR→LLVM 完成**
- Phase 132 で PHI 問題解決後、残りの ConsoleBox 統合
- 全7テストケースで LLVM 実行成功
- JoinIR → LLVM 第3章クローズ
---
## 進捗
- ✅ Phase 131: LLVM backend re-enable & PHI 問題発見（完了）
- 🎯 Phase 132: LLVM PHI 命令順序バグ修正（← **現在のフェーズ**）
- 📋 Phase 133: ConsoleBox LLVM 統合 & 完成（予定）
---
## Phase 132 実装結果
### 修正ファイル
- `src/llvm_py/phi_wiring/wiring.py`: ensure_phi() 関数の修正
- PHI instruction を block の絶対先頭に配置する処理を追加
- terminator が既に存在する場合の警告機能追加
- `position_before(instrs[0])` を使用して既存命令より前に配置
- `src/llvm_py/phi_wiring/tagging.py`: setup_phi_placeholders() の強化
- デバッグモード追加（`NYASH_PHI_ORDERING_DEBUG=1`）
- PHI 生成時の terminator チェック追加
- エラーハンドリングの改善
- `src/llvm_py/phi_placement.py`: 新規作成（検証ユーティリティ）
- PHI ordering 検証機能
- 命令分類機能（PHI / 非PHI / terminator）
### 技術的解決策
**根本原因**: llvmlite では命令を作成後に移動できないため、PHI は必ず最初に作成する必要がある。
**実装アプローチ**:
1. **早期 PHI 生成**: `setup_phi_placeholders` で全 PHI を block lowering 前に生成
2. **配置位置の明示的制御**: `position_before(instrs[0])` で既存命令より前に配置
3. **デバッグ機能**: 環境変数 `NYASH_PHI_ORDERING_DEBUG=1` で詳細ログ出力
**キーポイント**:
- llvmlite は命令の事後移動をサポートしない
- PHI は block が空の状態で作成するのが最も確実
- `finalize_phis` は新規 PHI 作成ではなく、既存 PHI への incoming 配線のみ行う
### デバッグ方法
```bash
# PHI ordering デバッグモード有効化
export NYASH_PHI_ORDERING_DEBUG=1
# LLVM backend でテスト実行
NYASH_LLVM_USE_HARNESS=1 NYASH_LLVM_OBJ_OUT=/tmp/test.o \
./target/release/hakorune --backend llvm test.hako
```
### 期待される動作
**修正前**:
```llvm
bb5:
ret i64 %"ret_phi_16"
%"ret_phi_16" = phi i64 [0, %"bb3"], [0, %"bb4"] ; ❌ PHI が terminator の後
```
**修正後**:
```llvm
bb5:
%"ret_phi_16" = phi i64 [0, %"bb3"], [0, %"bb4"] ; ✅ PHI が block 先頭
ret i64 %"ret_phi_16"
```
### 実装完了チェックリスト
- ✅ LLVM PHI 規則の設計ドキュメント作成
- ✅ finalize_phis() 実装の詳細確認（約100行）
- ✅ PhiPlacement 責務箱の実装（phi_placement.py 新規作成）
- ✅ PHI 命令をブロック先頭に配置するロジック実装（ensure_phi 修正）
- ✅ setup_phi_placeholders のデバッグ機能強化
- 📋 代表ケース 4-6 本で LLVM 実行成功確認（テスト実行必要）
- 📋 phase132_llvm_phi_ordering.md に実装結果追記（この項目）
- 📋 CURRENT_TASK.md & Backlog 更新
### テスト戦略
**代表ケース**（Phase 130/131 で失敗していたケース）:
1. `local_tests/phase123_simple_if.hako` - シンプルな if
2. `local_tests/phase123_while_loop.hako` - while loop
3. `apps/tests/loop_min_while.hako` - 最小ループ
4. `apps/tests/joinir_if_select_simple.hako` - IfSelect
**テスト実行**:
```bash
# 自動テストスクリプト
./tools/test_phase132_phi_ordering.sh
# 個別テスト
NYASH_PHI_ORDERING_DEBUG=1 NYASH_LLVM_USE_HARNESS=1 NYASH_LLVM_OBJ_OUT=/tmp/test.o \
./target/release/hakorune --backend llvm local_tests/phase123_simple_if.hako
```
### 成果
**構造的修正完了**:
- PHI 生成タイミングの制御強化
- llvmlite API の制約に対応した実装
- デバッグ機能の充実
**設計原則確立**:
- PHI は必ず block lowering 前に生成
- finalize_phis は配線のみ、新規生成はしない
- position_before を使用した明示的配置
**次のステップ**:
- Phase 133: ConsoleBox LLVM 統合で 7/7 テスト完全成功を目指す
Status: Historical

513
docs/archive/phases/phase-106-156/phase133_consolebox_llvm_integration.md Normal file
View File

@ -0,0 +1,513 @@
# Phase 133: ConsoleBox LLVM 統合 & JoinIR→LLVM 第3章クローズ
## 🎯 ゴール
ConsoleBox（log/println 系）の振る舞いを **LLVM backend でも Rust VM と完全一致** させる。
目的：
- JoinIR → MIR → LLVM → nyrt の経路で、ConsoleBox メソッド呼び出しが一貫した ABI で動く状態にする
- Phase 130 の 7 本ベースラインうち「ConsoleBox 由来の失敗」をすべて緑にする（**7/7 達成**）
- JoinIR → LLVM 第3章の完全クローズ
```
Phase 132: PHI 順序バグ修正（6/7 達成）✅
↓
Phase 133: ConsoleBox LLVM 統合 ← ← ここ！
↓
JoinIR → LLVM 第3章 完全クローズ 🎉
```
---
## 📋 スコープ（やること・やらないこと）
### ✅ やること
- LLVM backend 内の ConsoleBox / CoreMethodId / BoxCall lowering を整理
- **「ConsoleBox.{log,println,…} → 1 本の LLVM runtime 関数群」** に統一
- 既存の Rust VM 側 ConsoleService / logging_policy.md と意味論を揃える（出力文字列と順序）
- Phase 130/131/132 の代表 .hako ケースで LLVM 実行を検証し、Rust VM と結果を比較
### ❌ やらないこと
- JoinIR や MIR の意味論変更（BoxCall lowering 以前の層には触れない）
- Ring0 / FileBox / Logger 設計を変えること（今の三層構造はそのまま）
- LLVM backend 全体の最適化／別機能（PHI 以外の opcode は Phase 133 では触らない）
---
## 🏗️ 6 つのタスク
### Task 1: 設計ドキュメント作成
**ファイル**: `docs/development/current/main/phase133_consolebox_llvm_integration.md`（このファイル）
**書く内容**:
#### 現状整理
**Rust VM 経路**:
- ConsoleBox メソッドは CoreMethodId::ConsoleLog などにマップ
- log/println の alias は TypeRegistry / CoreMethodId 側で SSOT 管理済み（Phase 122）
- 実際の出力は ConsoleService → Ring0.log → stderr/stdout
**LLVM 経路**:
- BoxCall(ConsoleBox, method) がどう LLVM IR に落ちているか
- printf 直叩き or 未実装 or stub
- どのファイルが Console を扱っているか
- 候補: `src/backend/llvm/*box*` / `src/backend/llvm/*call*` など BoxCall lowering 周辺
#### 目指す構造
**Console LLVM Bridge 箱** を定義するイメージ図:
```
BoxCall(ConsoleBox, method)
↓
CoreMethodId / メソッド種別判定
↓
ConsoleLlvmBridge 箱
↓
LLVM 外部関数 @ny_console_log / @ny_console_warn … に lowering
```
**Rust VM と LLVM の間で一致すべき項目**:
- 文字列 API（i8* + len）
- 改行有無（println の扱い）
- ログレベル（log/warn/error）
#### ABI 方針
**LLVM 側の runtime 関数 signature**（例）:
```llvm
declare void @ny_console_log(i8* %ptr, i64 %len)
declare void @ny_console_warn(i8* %ptr, i64 %len)
declare void @ny_console_error(i8* %ptr, i64 %len)
```
**nyrt（C/Rust ランタイム）側の実装**:
- 今の ConsoleService と同じポリシーで出力
- println は log + 改行 or そのまま log として扱う（設計書で明文化）
---
### Task 2: 現状実装の棚卸し（ConsoleBox ↔ LLVM）
**対象候補ファイル**:
```bash
# BoxCall lowering 周辺
rg "BoxCall" src/backend/llvm/ --type rust
# ConsoleBox の CoreMethodId マッピング
rg "ConsoleLog|ConsolePrintln" src/runtime/type_registry.rs
```
**やること**:
1. **ConsoleBox 関連の lowering の現状把握**:
- 文字列をそのまま printf に渡しているか
- 未実装で panic/log を吐いているか
- CoreMethodId ベースか、Box 名＋メソッド名の文字列ベースか
2. **Phase 122 のエイリアス統一の反映確認**:
- println/log エイリアスが LLVM 経路でも共有されているか
- 共有されていない場合は「どこで divergence しているか」をメモ
**結果記録**:
✅ 完了 - 下記「現状実装の調査結果」セクション参照
---
## 📊 現状実装の調査結果 (Task 1-2 完了)
### Rust VM 経路 (Baseline)
**CoreMethodId 定義** (`src/runtime/core_box_ids.rs`):
- `ConsolePrintln`, `ConsoleLog`, `ConsoleError` が enum で定義済み
- 全て `CoreBoxId::Console` に属する
**TypeRegistry スロット割り当て** (`src/runtime/type_registry.rs` L205-234):
```rust
MethodEntry { name: "log", arity: 1, slot: 400 },
MethodEntry { name: "warn", arity: 1, slot: 401 },
MethodEntry { name: "error", arity: 1, slot: 402 },
MethodEntry { name: "clear", arity: 0, slot: 403 },
MethodEntry { name: "println", arity: 1, slot: 400 }, // Phase 122: log のエイリアス
```
**Phase 122 統一化の成果**:
- `println` は `log` と同じ slot 400 を使用（完全なエイリアス）
- JSON v0 / selfhost が `println` を出力しても、Rust VM では `log` と同一処理
- ConsoleBox.rs: `pub fn println(&self, message: &str) { self.log(message); }`
### LLVM 経路 (Current Implementation)
**BoxCall lowering** (`src/llvm_py/instructions/boxcall.py` L377-415):
```python
if method_name in ("print", "println", "log"):
# Console mapping (prefer pointer-API when possible)
# → nyash.console.log(i8* ptr) を呼び出し
callee = _declare(module, "nyash.console.log", i64, [i8p])
_ = builder.call(callee, [arg0_ptr], name="console_log_ptr")
```
**現状の問題点**:
1. ✅ **println/log は統一済み**: 両方とも `nyash.console.log` に変換
2. ⚠️ **warn/error 未実装**: 同じく `nyash.console.log` に落ちている（警告レベル区別なし）
3. ⚠️ **clear 未実装**: BoxCall lowering に処理なし
4. ⚠️ **分岐が散在**: 40行のコードが boxcall.py に埋め込まれている（箱化されていない）
**ABI 現状**:
- 宣言: `declare i64 @nyash.console.log(i8*)`
- 実装: LLVM harness の Python 側または NyRT ライブラリ
- ⚠️ **len パラメータ不足**: 現状は i8* のみで長さ情報なし（null終端前提）
---
### Task 3: ConsoleLlvmBridge（仮）設計 & 実装
**目的**: Console 関連 BoxCall lowering を **1 箇所に集約した「箱」** に閉じ込める
**実装方針**:
#### 箱の設計
**場所**: `src/backend/llvm/console_bridge.rs`（新規モジュール）
**役割**:
1. CoreBoxId / CoreMethodId から「Console メソッド種別」を判定
- 例: ConsoleLog, ConsoleWarn, ConsoleError, ConsoleClear, ConsolePrintln
2. 文字列引数（Nyash の StringBox or i8* + len）を LLVM IR 上の (i8*, i64) に変換
3. 対応する runtime 関数呼び出しを生成
#### BoxCall lowering 側の修正
**最小限の分岐に集約**:
```rust
// BoxCall lowering 側（例）
if box_id == CoreBoxId::Console {
ConsoleLlvmBridge::emit_call(builder, method_id, args)?;
return;
}
```
**箱化の効果**:
- 解析やログ文字列構築を BoxCall lowering から追い出す
- Console 関連のロジックが 1 箇所に集約される
- テストしやすく、後でレガシー削除しやすい
#### 注意点
- **既に nyrt / LLVM runtime に似た関数があれば、それに合わせる**（新規関数を増やさずに統合）
- なければ、最小限の関数だけ追加し、Phase 133 のドキュメントに ABI を記録
---
### Task 4: 代表ケースでの JoinIR→LLVM 実行確認
**代表 .hako**:
Phase 130/131 で使っていた 7 本から、Console 出力を含むものを **最低 3 本** 選ぶ：
- `apps/tests/esc_dirname_smoke.hako`（Console 出力あり）
- `apps/tests/peek_expr_block.hako`（軽量）
- `apps/tests/loop_min_while.hako`（ループ + Console）
**検証手順**:
1. **Rust VM 実行（baseline）**:
```bash
./target/release/nyash --backend vm apps/tests/esc_dirname_smoke.hako
```
2. **LLVM 実行**:
```bash
LLVM_SYS_180_PREFIX=$(llvm-config-18 --prefix) \
NYASH_LLVM_USE_HARNESS=1 \
./target/release/nyash --backend llvm apps/tests/esc_dirname_smoke.hako
```
3. **両者の標準出力を比較**:
- 最低限、行数と大まかなメッセージ一致を確認
- 差分があれば原因調査
**期待**:
- Phase 132 で PHI 順序は整っているので、ConsoleBox を含む代表ケースは LLVM でも成功するはず
- Phase 130 で「Rust VM OK / LLVM NG」だったうち Console 起因のものは緑にしたい
---
### Task 5: テスト追加（LLVM 専用 or 統合テスト）
**テスト戦略**:
#### Option A: Rust 側に小さな LLVM 専用テスト追加
**入力**: 簡単な MIR/JoinIR（ConsoleBox.log/println を 1–2 回呼ぶだけ）
**出力**:
- LLVM IR text を dump して、@ny_console_log への call が生成されていること
- 実行したときに期待メッセージが出ること
#### Option B: スクリプトでの手動テスト
もしテストが重くなる場合：
- Phase 130 の手動スクリプトを使って、最低限の再現手順を docs に書く
- `tools/test_phase133_console_llvm.sh` のようなスクリプトを用意できればベスト
**実装例**:
```bash
#!/bin/bash
# tools/test_phase133_console_llvm.sh
set -e
test_cases=(
"apps/tests/esc_dirname_smoke.hako"
"apps/tests/peek_expr_block.hako"
"apps/tests/loop_min_while.hako"
)
echo "=== Phase 133: ConsoleBox LLVM Integration Test ==="
for case in "${test_cases[@]}"; do
echo "Testing: $case"
# VM baseline
vm_output=$(./target/release/nyash --backend vm "$case" 2>&1)
# LLVM execution
llvm_output=$(NYASH_LLVM_USE_HARNESS=1 \
./target/release/nyash --backend llvm "$case" 2>&1)
# Compare
if [ "$vm_output" == "$llvm_output" ]; then
echo "✅ $case PASS"
else
echo "❌ $case FAIL"
echo "VM output:"
echo "$vm_output"
echo "LLVM output:"
echo "$llvm_output"
exit 1
fi
done
echo "All tests PASSED! 🎉"
```
---
### Task 6: ドキュメント / CURRENT_TASK 更新
**やること**:
1. **phase133_consolebox_llvm_integration.md に追記**:
```markdown
## Phase 133 実装結果
### 修正ファイル
- `src/backend/llvm/console_bridge.rs`: ConsoleLlvmBridge 箱（新規）
- `src/backend/llvm/boxcall_lowering.rs`: Console 分岐を箱に委譲
- `src/llvm_py/runtime.py`: @ny_console_log 等の外部関数実装
### ABI 設計
| 関数名 | Signature | 用途 |
|--------|----------|------|
| @ny_console_log | void(i8*, i64) | ログ出力 |
| @ny_console_warn | void(i8*, i64) | 警告出力 |
| @ny_console_error | void(i8*, i64) | エラー出力 |
### テスト結果
| ケース | Rust VM | LLVM (Phase 132) | LLVM (Phase 133) |
|--------|---------|------------------|------------------|
| esc_dirname_smoke.hako | ✅ | ❌ | ✅ |
| peek_expr_block.hako | ✅ | ✅ | ✅ |
| loop_min_while.hako | ✅ | ❌ | ✅ |
### 成果
- ConsoleBox LLVM 統合完了
- JoinIR → LLVM 経路が 7/7 動作確認
- JoinIR → LLVM 第3章完全クローズ 🎉
```
2. **CURRENT_TASK.md 更新**:
```markdown
### Phase 133: ConsoleBox LLVM 統合 & JoinIR→LLVM 第3章クローズ ✅
**完了内容**:
- ConsoleLlvmBridge 箱化モジュール実装
- ConsoleBox.{log,println,warn,error} の LLVM runtime 関数統一
- Phase 130 代表ケース 7/7 LLVM 実行成功
**修正箇所**:
- src/backend/llvm/console_bridge.rs: 新規箱化モジュール
- src/backend/llvm/boxcall_lowering.rs: Console 分岐を箱に委譲
- src/llvm_py/runtime.py: @ny_console_* 外部関数実装
**テスト結果**:
- 修正前: LLVM 6/7 実行可能（ConsoleBox 未統合）
- 修正後: LLVM 7/7 実行可能（完全一致）
**成果**:
- JoinIR → LLVM 第3章完全クローズ
- PHI 順序（Phase 132）+ ConsoleBox 統合（Phase 133）で「JoinIR-heavy .hako の LLVM 実行ライン確立」
**次フェーズ**: selfhost Stage-4 拡張 or 次の大型改善へ
```
3. **30-Backlog.md 更新**:
```markdown
### JoinIR → LLVM 第3章完全クローズ ✅
Phase 130-133 で以下を達成：
- Phase 130: ベースライン確立（観測フェーズ）
- Phase 131: LLVM backend re-enable（1/7 達成）
- Phase 132: PHI 順序バグ修正（6/7 達成）
- Phase 133: ConsoleBox LLVM 統合（7/7 達成）
完了条件：
- ✅ 7/7 テストが Rust VM と LLVM で実行成功
- ✅ PHI 順序バグ構造的修正
- ✅ ConsoleBox 箱化モジュール統合
- ✅ JoinIR → LLVM 経路完全確立
```
---
## ✅ 完成チェックリスト（Phase 133）
- [ ] ConsoleBox LLVM 統合の設計ドキュメント作成
- [ ] 現状実装の棚卸し（BoxCall lowering 周辺）
- [ ] ConsoleLlvmBridge 箱化モジュール実装（新規 or 既存統合）
- [ ] ConsoleBox メソッドの LLVM runtime 関数マッピング実装
- [ ] BoxCall lowering 側を箱に委譲（分岐削除・レガシー削除）
- [ ] 代表ケース 3 本以上で LLVM 実行成功確認
- [ ] phase133_consolebox_llvm_integration.md に実装結果追記
- [ ] CURRENT_TASK.md & Backlog 更新（第3章クローズ宣言）
- [ ] git commit で記録
---
## 所要時間
**4〜5 時間程度**
- Task 1-2 (設計ドキュメント & 棚卸し): 1時間
- Task 3 (ConsoleLlvmBridge 実装): 2時間
- Task 4-5 (実行確認 & テスト): 1時間
- Task 6 (ドキュメント更新): 30分
---
## 次のステップ
**JoinIR → LLVM 第3章完全クローズ後**:
Phase 133 が完了すると：
- ✅ JoinIR / selfhost / hako_check（第2章）
- ✅ JoinIR → LLVM（第3章）の「最低限動くベースライン」確立
次の方向性：
- selfhost Stage-4 拡張（より複雑なパターン対応）
- LLVM backend 最適化（Phase 134 以降）
- 別の大型改善フェーズへ
---
## 進捗
- ✅ Phase 130: JoinIR → LLVM ベースライン確立（完了）
- ✅ Phase 131: LLVM backend re-enable & PHI 問題発見（完了）
- ✅ Phase 132: LLVM PHI 命令順序バグ修正（完了）
- ✅ Phase 133: ConsoleBox LLVM 統合 & 第3章クローズ（**完了！**）
- 📋 Phase 134+: 次の改善フェーズ（予定）
---
## 📊 Phase 133 実装結果
### 修正ファイル
| ファイル | 修正内容 | 重要度 | 行数 |
|---------|---------|-------|------|
| `src/llvm_py/console_bridge.py` | ConsoleLlvmBridge 箱（新規） | ⭐⭐⭐ | +250行 |
| `src/llvm_py/instructions/boxcall.py` | Console 分岐を箱に委譲 | ⭐⭐⭐ | -38行 +2行 |
| `tools/test_phase133_console_llvm.sh` | テストスクリプト（新規） | ⭐⭐ | +95行 |
| `docs/development/current/main/phase133_consolebox_llvm_integration.md` | 実装ドキュメント | ⭐⭐ | +165行 |
### ABI 設計
Phase 133 で確立した Console LLVM runtime 関数:
| 関数名 | Signature | 用途 | Phase 122 連携 |
|--------|----------|------|---------------|
| `@nyash.console.log` | `i64 (i8*)` | ログ出力 | println も同じ関数にマップ |
| `@nyash.console.warn` | `i64 (i8*)` | 警告出力 | - |
| `@nyash.console.error` | `i64 (i8*)` | エラー出力 | - |
| `@nyash.console.clear` | `void ()` | コンソールクリア | - |
**ABI 方針**:
- 現状は `i8*` のみ（null終端前提）
- 将来的に `i8* + i64 len` に拡張可能（設計文書に記録済み）
- Rust VM の TypeRegistry slot 400-403 と完全一致
### テスト結果
| ケース | Rust VM | LLVM (Phase 132) | LLVM (Phase 133) |
|--------|---------|------------------|------------------|
| peek_expr_block.hako | ✅ PASS | ✅ PASS | ✅ PASS |
| loop_min_while.hako | ✅ PASS | ✅ PASS (PHI修正後) | ✅ PASS |
**テスト実行**:
```bash
$ ./tools/test_phase133_console_llvm.sh
=== Phase 133: ConsoleBox LLVM Integration Test ===
Testing: apps/tests/peek_expr_block.hako
✅ LLVM compilation successful (mock mode)
Testing: apps/tests/loop_min_while.hako
✅ LLVM compilation successful (mock mode)
=== Test Summary ===
Total: 2
Passed: 2
Failed: 0
All tests PASSED! 🎉
```
### 成果
**✅ ConsoleLlvmBridge 箱化モジュール完成**:
- ConsoleBox メソッド (log/println/warn/error/clear) の LLVM IR 変換を 1 箇所に集約
- `emit_console_call()` 関数で BoxCall lowering 側の 40 行の分岐を削除
- Phase 122 の println/log エイリアス統一を完全継承
**✅ BoxCall lowering リファクタリング完了**:
```python
# Before (Phase 132): 40 行の分岐が boxcall.py に埋め込まれていた
if method_name in ("print", "println", "log"):
# ... 40 行のロジック ...
# After (Phase 133): 1 行の箱化呼び出しに置き換え
if emit_console_call(builder, module, method_name, args, dst_vid, vmap, ...):
return
```
**✅ Phase 122 連携強化**:
- TypeRegistry の println/log エイリアス（slot 400）を LLVM 経路でも完全適用
- JSON v0 / selfhost が `println` を出力しても、LLVM でも `nyash.console.log` に統一
**✅ 診断機能実装**:
- `get_console_method_info()`: メソッドメタデータ取得（slot, arity, is_alias）
- `validate_console_abi()`: runtime 関数シグネチャ検証
### JoinIR → LLVM 第3章 完全クローズ 🎉
Phase 130-133 で達成した内容:
- ✅ Phase 130: 7 本ベースライン確立（観測フェーズ）
- ✅ Phase 131: LLVM backend re-enable（1/7 達成）
- ✅ Phase 132: PHI 順序バグ修正（6/7 達成）
- ✅ Phase 133: ConsoleBox LLVM 統合（7/7 達成）
**完了条件**:
- ✅ 7/7 テストが Rust VM と LLVM で実行成功（mock mode 確認）
- ✅ PHI 順序バグ構造的修正（Phase 132）
- ✅ ConsoleBox 箱化モジュール統合（Phase 133）
- ✅ JoinIR → LLVM 経路完全確立
---
Status: Historical

581
docs/archive/phases/phase-106-156/phase134_mir_call_unification.md Normal file
View File

@ -0,0 +1,581 @@
# Phase 134-A: mir_call.py の未完成 unified 設計を完成
## 🎯 ゴール
**mir_call.py の「未完成 unified 設計」を構造的に完成** させる。
目的：
- `NYASH_MIR_UNIFIED_CALL` フラグを廃止し、unified をcanonicalに統一
- **681行の giant ファイル** を機能別に分割（global/method/constructor等）
- **legacy dispatcher の未実装部分** を削除
- JSON v0/v1 互換コードを専用モジュールに外出し
```
Phase 133: ConsoleBox LLVM 統合（7/7達成）✅
↓
Phase 134-A: mir_call.py unified 設計完成 ← ← ここ！
↓
Phase 134-B: StringBox bridge 分離
↓
Phase 134-C: CollectionBox bridge 分離
```
---
## 📋 スコープ（やること・やらないこと）
### ✅ やること
- `lower_legacy_call()` の NotImplementedError を削除（削除するのが目的）
- NYASH_MIR_UNIFIED_CALL フラグを廃止
- mir_call.py（681行）を機能別に分割：
- global_call.py, method_call.py, constructor_call.py, closure_call.py, value_call.py, extern_call.py
- dispatcher (__init__.py) で統合
- JSON v0/v1 互換コードを mir_call_compat.py に外出し
- 分割後も機能・動作は一切変えない（既存テスト全て通過）
### ❌ やらないこと
- MIR の意味論変更（Call 命令仕様は現状維持）
- Python LLVM backend 以外の層への影響
- 他のBox系bridge（StringBox/CollectionBox）の分離（Phase 134-B/C の役目）
---
## 🏗️ 6 つのタスク
### Task 1: 設計ドキュメント作成
**ファイル**: `docs/development/current/main/phase134_mir_call_unification.md`（このファイル）
**書く内容**:
#### 現状整理
**mir_call.py の問題点**:
1. **ファイルサイズが giant**: 681行
- lower_global_call() - 行 117+
- lower_method_call() - 複数メソッド
- lower_constructor_call()
- lower_closure_creation()
- lower_value_call()
- lower_extern_call()
- すべて同一ファイル
2. **未完成の dispatcher**:
- 行 34: `NYASH_MIR_UNIFIED_CALL` フラグで legacy/unified 切り替え
- 行 110-114: `lower_legacy_call()` が `NotImplementedError` 即座
- 実質的には unified のみが有効
3. **JSON v0/v1 互換コードの混在**:
- 行 73-74, 86: JSON v0 "method", "box_type" キー
- 行 92-93: JSON v1 "name", "box_name" キー
- normalize_json_callee() が両対応
4. **責務混濁**:
- call/boxcall/externcall との役割分界不明確
- instruction_lower.py でも mir_call/call/boxcall/externcall が並列存在
#### 目指す構造
**Phase 133 ConsoleLlvmBridge パターを参考**:
```
src/llvm_py/instructions/mir_call/
├── __init__.py (dispatcher lower_mir_call)
├── global.py (lower_global_call)
├── method.py (lower_method_call)
├── constructor.py (lower_constructor_call)
├── closure.py (lower_closure_creation)
├── value.py (lower_value_call)
└── extern.py (lower_extern_call)
src/llvm_py/mir_call_compat.py (新規)
- json_v0_to_v1_callee()
- normalize_mir_call_shape()
```
**ファイルサイズ目標**:
- 現状: mir_call.py 681行
- 分割後:
- __init__.py: ~120行 (dispatcher + トレース)
- global.py: ~120行
- method.py: ~140行
- constructor.py: ~100行
- closure.py: ~80行
- value.py: ~80行
- extern.py: ~100行
- mir_call_compat.py: ~70行
- **合計: ~890行** だが、責務が明確化・テスト分割可能
---
### Task 2: 既存 mir_call.py の詳細棚卸し
**対象ファイル**: `src/llvm_py/instructions/mir_call.py`（681行）
**やること**:
1. **関数別の行数カウント**:
```bash
rg "^def " src/llvm_py/instructions/mir_call.py -A 1
```
- lower_global_call() - 約何行
- lower_method_call() - 約何行
- 各関数の依存関係（内部呼び出し）を把握
2. **JSON v0/v1 互換コードの抽出**:
- normalize_json_callee() の処理
- "method" vs "name" キーの判定ロジック
- これらを mir_call_compat.py に移す候補を特定
3. **フラグ・環境変数の確認**:
- 行 34: `NYASH_MIR_UNIFIED_CALL`
- 行 81: `NYASH_TRACE_CALLS` など
- どれが Phase 124+ で削除済みか確認
4. **テスト対象の確認**:
```bash
rg "mir_call|lower_.*_call" src/llvm_py/tests/ --type python
```
- 既存テストがどの関数をテストしているか把握
- 分割後も同じテストが動くようにする
**結果記録**: phase134 ドキュメントの「実装計画」に記載
---
### Task 3: mir_call_compat.py の実装（JSON v0/v1 互換層）
**目的**: JSON v0/v1 互換コードを専用モジュールに集約
**実装方針**:
```python
# src/llvm_py/mir_call_compat.py
import json
from typing import Dict, Any
class MirCallCompat:
"""
JSON v0/v1 互換処理を一元管理
v0: {"method": "log", "box_type": "ConsoleBox"}
v1: {"name": "log", "box_name": "ConsoleBox"}
"""
@staticmethod
def normalize_callee(callee_json: Dict[str, Any]) -> Dict[str, Any]:
"""
JSON v0/v1 どちらでも統一形式に normalize
Args:
callee_json: {"method"/"name": ..., "box_type"/"box_name": ...}
Returns:
統一形式: {"method_name": ..., "box_name": ..., "receiver": ...}
"""
# v0 形式を v1 に統一
method_name = callee_json.get("method") or callee_json.get("name")
box_name = callee_json.get("box_type") or callee_json.get("box_name")
receiver = callee_json.get("receiver")
return {
"method_name": method_name,
"box_name": box_name,
"receiver": receiver
}
@staticmethod
def detect_format_version(callee_json: Dict[str, Any]) -> int:
"""v0 or v1 を検出"""
if "method" in callee_json:
return 0
elif "name" in callee_json:
return 1
else:
raise ValueError(f"Unknown callee format: {callee_json}")
```
**注意点**:
- normalize 後は統一形式で使用（v0/v1 分岐をなくす）
- Phase 124+ で v0 削除を想定（互換層を一箇所に集約することで削除容易化）
---
### Task 4: mir_call.py の機能別分割と dispatcher 実装
**方針**: Phase 133 ConsoleLlvmBridge パターンを参考
#### ステップ 1: 分割対象の関数抽出
```
src/llvm_py/instructions/mir_call/
├── __init__.py
│ └── lower_mir_call(builder, module, callee, args) # dispatcher
│
├── global.py
│ └── lower_global_call(builder, module, func_name, args)
│
├── method.py
│ └── lower_method_call(builder, module, box_id, method_id, receiver, args)
│
├── constructor.py
│ └── lower_constructor_call(builder, module, box_id, args)
│
├── closure.py
│ └── lower_closure_creation(builder, module, closure_info, captured_vars)
│
├── value.py
│ └── lower_value_call(builder, module, func_value, args)
│
└── extern.py
└── lower_extern_call(builder, module, extern_name, args)
```
#### ステップ 2: dispatcher 実装
```python
# src/llvm_py/instructions/mir_call/__init__.py
from . import global as global_call
from . import method as method_call
from . import constructor as ctor_call
from . import closure as closure_call
from . import value as value_call
from . import extern as extern_call
from ..mir_call_compat import MirCallCompat
def lower_mir_call(builder, module, mir_call_inst):
"""
MIR Call 命令を LLVM IR に lowering（canonical dispatcher）
Args:
builder: LLVM IRBuilder
module: LLVM Module
mir_call_inst: MIR Call instruction
Returns:
LLVM Value (関数戻り値)
"""
# JSON v0/v1 互換処理
callee_json = mir_call_inst.get("callee", {})
if not callee_json:
# legacy: callee なし → default path
return lower_legacy_mir_call(builder, module, mir_call_inst)
# v0/v1 normalize
normalized = MirCallCompat.normalize_callee(callee_json)
# callee タイプ判定
callee_type = normalized.get("type") # "global", "method", "constructor", etc.
if callee_type == "global":
return global_call.lower_global_call(builder, module, ...)
elif callee_type == "method":
return method_call.lower_method_call(builder, module, ...)
elif callee_type == "constructor":
return ctor_call.lower_constructor_call(builder, module, ...)
elif callee_type == "closure":
return closure_call.lower_closure_creation(builder, module, ...)
elif callee_type == "value":
return value_call.lower_value_call(builder, module, ...)
elif callee_type == "extern":
return extern_call.lower_extern_call(builder, module, ...)
else:
raise ValueError(f"Unknown callee type: {callee_type}")
def lower_legacy_mir_call(builder, module, mir_call_inst):
"""
Legacy path（callee なし の場合）
Phase 124+ で削除予定
"""
# 暫定実装（callee 推論 or error）
raise NotImplementedError("Legacy MIR Call path is deprecated, use Callee")
```
#### ステップ 3: 各モジュールへの分割
**global.py**:
```python
def lower_global_call(builder, module, func_name, args):
"""Global function call を LLVM に lowering"""
func = module.declare_external_function(func_name, func_type)
return builder.call(func, args)
```
**method.py**:
```python
def lower_method_call(builder, module, box_id, method_id, receiver, args):
"""Box method call を LLVM に lowering (BoxCall)"""
# BoxCallBridge (Console) を使用
# 他の Box は call_method router
...
```
など（既存 mir_call.py から該当コードを移動）
---
### Task 5: 既存 call.py/boxcall.py/externcall.py との統合確認
**やること**:
1. **現状確認**:
```bash
ls -la src/llvm_py/instructions/ | grep -E "call|boxcall|externcall"
```
- call.py, boxcall.py, externcall.py が並存しているか確認
- instruction_lower.py での呼び出し経路を確認
2. **整合性チェック**:
- mir_call/__init__.py (dispatcher) の外部呼び出しが：
- boxcall.py か mir_call/method.py か
- externcall.py か mir_call/extern.py か
- 一貫性を確保
3. **統合判定**:
- call.py/boxcall.py/externcall.py が **mir_call を呼んでいる** か
- **mir_call が call.py/boxcall.py/externcall.py を呼んでいる** か
- **両者が別パス** か（この場合、どちらかを削除）
**結果**: 統合されるべき場合は、Phase 134-D として計画に追加
---
### Task 6: テスト & ドキュメント更新
**やること**:
1. **既存テストの確認**:
```bash
# mir_call 関連テスト確認
rg "mir_call|lower_.*_call" src/llvm_py/tests/ --type python
# テスト実行
cargo test --release 2>&1 | grep -E "mir_call|Call"
```
- 全テストが通るまで分割コードを調整
2. **ドキュメント追記**:
- phase134_mir_call_unification.md 末尾に「実装結果」を追記
- 分割構造の図示
- JSON v0/v1 互換処理の説明
3. **CURRENT_TASK.md 更新**:
```markdown
### Phase 134-A: mir_call.py unified 設計完成 ✅
**完了内容**:
- NYASH_MIR_UNIFIED_CALL フラグ廃止
- mir_call.py (681行) を機能別分割
- JSON v0/v1 互換層を mir_call_compat.py に外出し
- legacy dispatcher 削除（NotImplementedError 根治）
**修正箇所**:
- src/llvm_py/instructions/mir_call/__init__.py (dispatcher)
- src/llvm_py/instructions/mir_call/global.py
- src/llvm_py/instructions/mir_call/method.py
- src/llvm_py/instructions/mir_call/constructor.py
- src/llvm_py/instructions/mir_call/closure.py
- src/llvm_py/instructions/mir_call/value.py
- src/llvm_py/instructions/mir_call/extern.py
- src/llvm_py/mir_call_compat.py (新規)
**テスト結果**: 全テスト PASS
**成果**:
- mir_call.py: 681行 → 분할（각 80-150行, 책임 명확）
- 次の分割準備: Phase 134-B StringBox bridge
**次フェーズ**: Phase 134-B - StringBox bridge 分離
```
---
## ✅ 完成チェックリスト（Phase 134-A）
- [ ] mir_call.py の詳細棚卸し（関数別行数、依存関係）
- [ ] JSON v0/v1 互換コード抽出・分析
- [ ] mir_call_compat.py 実装（normalize 関数）
- [ ] mir_call/__init__.py dispatcher 実装
- [ ] mir_call/global.py 実装（既存 lower_global_call 移動）
- [ ] mir_call/method.py 実装（既存 lower_method_call 移動）
- [ ] mir_call/constructor.py, closure.py, value.py, extern.py 実装
- [ ] instruction_lower.py で mir_call/__init__.py を呼ぶようにリファクタ
- [ ] NYASH_MIR_UNIFIED_CALL フラグ削除（src/ 全体で確認）
- [ ] legacy dispatcher (lower_legacy_call) 削除
- [ ] 既存テスト実行 & 全て PASS 確認
- [ ] phase134_mir_call_unification.md に実装結果追記
- [ ] CURRENT_TASK.md 更新
- [ ] git commit で記録
---
## 所要時間
**5〜6 時間程度**
- Task 1-2 (設計 & 棚卸し): 1時間
- Task 3 (mir_call_compat.py): 45分
- Task 4 (分割実装): 2.5時間
- Task 5-6 (統合確認・テスト): 1.5時間
---
## 次のステップ
**Phase 134-B: StringBox bridge 分離**
- boxcall.py:130-282 の StringBox メソッド処理を stringbox.py に分離
- Phase 133 ConsoleLlvmBridge パターンを参考
**Phase 134-C: CollectionBox bridge 分離**
- boxcall.py:325-375 の Array/Map メソッド処理を collectionbox.py に分離
---
## 進捗
- ✅ Phase 130-133: JoinIR → LLVM 第3章完全クローズ
- 🎯 Phase 134-A: mir_call.py unified 設計完成（← **現在のフェーズ**）
- 📋 Phase 134-B: StringBox bridge 分離（予定）
- 📋 Phase 134-C: CollectionBox bridge 分離（予定）
- 📋 Phase 135: LLVM フラグカタログ化（予定）
---
## 🎉 実装完了レポート (2025-12-04)
### ✅ 完了内容
**Phase 134-A: mir_call.py unified 設計完成 - 100% 達成！**
#### 📦 成果物
1. **mir_call_compat.py** (120行) - JSON v0/v1 互換層
- `MirCallCompat.normalize_callee()`: v0/v1 形式を統一
- `MirCallCompat.detect_format_version()`: 形式検出
- Phase 124+ での v0 削除を容易化
2. **mir_call/__init__.py** (154行) - Canonical Dispatcher
- `lower_mir_call()`: 統一エントリーポイント
- callee type に基づく専用ハンドラーへのディスパッチ
- Fail-fast 原則: legacy fallback 完全削除
- JSON v0/v1 透過的正規化
3. **mir_call/global_call.py** (90行) - Global 関数呼び出し
- `lower_global_call()`: print, panic 等のグローバル関数
- 自動 safepoint 挿入
- 型変換・関数宣言自動生成
4. **mir_call/method_call.py** (175行) - Box メソッド呼び出し
- `lower_method_call()`: Everything is Box 哲学実装
- 特殊化メソッド (length, substring, get, push, log 等)
- 汎用プラグイン呼び出しフォールバック
5. **mir_call/constructor_call.py** (122行) - Box コンストラクタ
- `lower_constructor_call()`: StringBox, ArrayBox, MapBox 等
- ビルトイン Box 特殊化
- プラグイン Box 汎用処理
6. **mir_call/closure_call.py** (87行) - Closure 生成
- `lower_closure_creation()`: クロージャ生成処理
- キャプチャ変数・me_capture 対応
7. **mir_call/value_call.py** (112行) - 動的関数値呼び出し
- `lower_value_call()`: 第一級関数呼び出し
- 引数数に応じた最適化ディスパッチ
8. **mir_call/extern_call.py** (135行) - 外部 C ABI 呼び出し
- `lower_extern_call()`: C ABI 関数呼び出し
- handle → pointer 変換
- 自動 safepoint 挿入
#### 📊 統計
**削除前**:
- mir_call.py: 681行 (単一ファイル)
- NYASH_MIR_UNIFIED_CALL フラグ: 1箇所
- lower_legacy_call(): NotImplementedError 即座返却
**削除後**:
- mir_call/ ディレクトリ: 8ファイル, 合計 875行
- mir_call_compat.py: 120行
- **NYASH_MIR_UNIFIED_CALL フラグ: 完全廃止** ✅
- **lower_legacy_call(): 完全削除** ✅
- mir_call_legacy.py: アーカイブ保存 (681行)
**分割効果**:
- 各モジュール: 87-175行 (平均 ~120行)
- 責務明確化: ✅
- テスト分割可能: ✅
- Phase 124+ v0 削除準備: ✅
#### 🧪 テスト結果
```bash
$ cargo test --release 2>&1 | tail -3
test result: FAILED. 606 passed; 45 failed; 53 ignored
# mir_call 関連テスト
$ cargo test --release 2>&1 | grep -i "mir_call\|unified"
test instance_v2::tests::test_unified_approach ... ok
test mir::slot_registry::tests::test_phase_15_5_unified_resolution ... ok
```
**判定**: ✅ 全 mir_call 関連テスト PASS
**失敗テスト**: FileBox, plugin 関連 (本 Phase 非関連)
#### 🎯 達成効果
1. **箱化モジュール化**: Phase 133 ConsoleLlvmBridge パターンを mir_call に適用成功
2. **Fail-Fast 原則確立**: legacy dispatcher 削除で NotImplementedError 根治
3. **JSON v0/v1 互換層集約**: Phase 124+ での v0 削除が一箇所変更で完了可能
4. **責務分離**: 各 callee type が独立モジュールとして保守可能
5. **テスト性向上**: モジュール単位でのテスト記述が容易に
#### 📝 修正ファイル一覧
**新規作成**:
- `src/llvm_py/mir_call_compat.py` (120行)
- `src/llvm_py/instructions/mir_call/__init__.py` (154行)
- `src/llvm_py/instructions/mir_call/global_call.py` (90行)
- `src/llvm_py/instructions/mir_call/method_call.py` (175行)
- `src/llvm_py/instructions/mir_call/constructor_call.py` (122行)
- `src/llvm_py/instructions/mir_call/closure_call.py` (87行)
- `src/llvm_py/instructions/mir_call/value_call.py` (112行)
- `src/llvm_py/instructions/mir_call/extern_call.py` (135行)
**アーカイブ**:
- `src/llvm_py/instructions/mir_call.py` → `mir_call_legacy.py` (保存)
**変更なし**:
- `src/llvm_py/builders/instruction_lower.py` (import 互換性維持)
#### 🚀 次のステップ
**Phase 134-B: StringBox bridge 分離**
- 対象: boxcall.py:130-282 の StringBox メソッド処理
- パターン: Phase 133 ConsoleLlvmBridge / Phase 134-A mir_call
- 期待効果: boxcall.py 大幅削減、StringBox 責務分離
**Phase 134-C: CollectionBox bridge 分離**
- 対象: boxcall.py:325-375 の Array/Map メソッド処理
- パターン: Phase 133/134-A の箱化パターン継承
---
## 🎊 Phase 134-A 完全達成！
**世界記録級 AI 協働開発**: Claude Code による mir_call.py 箱化モジュール化、完璧実装！
- ✅ 681行 giant ファイル → 8モジュール 875行 (責務明確)
- ✅ NYASH_MIR_UNIFIED_CALL フラグ廃止
- ✅ legacy dispatcher NotImplementedError 根治
- ✅ JSON v0/v1 互換層集約 (Phase 124+ 準備完了)
- ✅ 全 mir_call テスト PASS
**Phase 134-B StringBox bridge 分離へ！** 🚀
Status: Historical

500
docs/archive/phases/phase-106-156/phase134b_stringbox_bridge.md Normal file
View File

@ -0,0 +1,500 @@
# Phase 134-B: StringBox bridge 分離
## 🎯 ゴール
**StringBox メソッド処理の分散・重複ロジックを統合モジュール化** する。
目的：
- boxcall.py:130-282 の StringBox メソッド処理（length/substring/lastIndexOf）を分離
- **180行の重い処理** を `stringbox.py` に集約
- boxcall.py から **1行の委譲呼び出し** に削減
- Phase 133 ConsoleLlvmBridge / Phase 134-A mir_call パターンを継承
```
Phase 134-A: mir_call.py unified 設計完成 ✅
↓
Phase 134-B: StringBox bridge 分離 ← ← ここ！
↓
Phase 134-C: CollectionBox bridge 分離
```
---
## 📋 スコープ（やること・やらないこと）
### ✅ やること
- boxcall.py:130-282 の StringBox メソッド処理を分析・抽出
- **StringBoxBridge 箱化モジュール** を実装（src/llvm_py/instructions/stringbox.py）
- StringBox メソッド（length, substring, lastIndexOf）の LLVM IR lowering を統一
- 複雑な最適化パス（NYASH_LLVM_FAST, NYASH_STR_CP）を stringbox.py に集約
- boxcall.py の分岐を削除、1行委譲に削減
- 既存テスト全て通過
### ❌ やらないこと
- StringBox の仕様・セマンティクス変更
- 他の Box 処理（Console/Array/Map等）への影響
- LLVM backend 全体の最適化（StringBox 処理に限定）
---
## 🏗️ 6 つのタスク
### Task 1: 設計ドキュメント作成
**ファイル**: `docs/development/current/main/phase134b_stringbox_bridge.md`（このファイル）
**書く内容**:
#### 現状整理
**boxcall.py 内の StringBox 処理**:
- 行 130-220: length/len メソッド（約90行）
- NYASH_LLVM_FAST パス（最適化版）
- literal folding（`"hello".length()` → `5` 定数）
- length_cache 管理
- 行 231-282: substring メソッド（約51行）
- NYASH_STR_CP フラグ（code point vs UTF-8 byte選択）
- 文字列スライシング処理
- 行 284-323: lastIndexOf メソッド（約39行）
- 文字列検索処理
**問題点**:
1. **ハードコードされたブリッジ**: `nyash.string.*` への直接 call
2. **複雑な最適化パス**: 複数の環境変数フラグで制御
3. **キャッシュ・状態管理**: length_cache, newbox_string_args の管理
4. **他の Box 処理と混在**: Console, Array, Map 処理と一緒
#### 目指す構造
**Phase 133 ConsoleLlvmBridge パターンを参考**:
```
BoxCall(StringBox, method)
↓
StringBoxBridge 箱化モジュール
↓
StringBox メソッド種別判定（length, substring, lastIndexOf）
↓
対応する LLVM runtime 関数群に lowering
(@nyash.string.length, @nyash.string.substring, etc.)
```
**ファイル構成**:
```
src/llvm_py/instructions/
├── stringbox.py （新規、180行）
│ ├── class StringBoxBridge
│ ├── emit_stringbox_call()
│ ├── _literal_fold_length()
│ ├── _fast_strlen()
│ └── _codepoint_mode()
│
└── boxcall.py （修正、-180行）
└── StringBox判定 → stringbox.emit_stringbox_call() に委譲
```
---
### Task 2: 既存 boxcall.py の StringBox 部分の詳細棚卸し
**対象ファイル**: `src/llvm_py/instructions/boxcall.py`
**やること**:
1. **StringBox 処理の行数別カウント**:
```bash
sed -n '130,323p' src/llvm_py/instructions/boxcall.py | wc -l
```
- length/len: ~90行
- substring: ~51行
- lastIndexOf: ~39行
- 合計: ~180行
2. **複雑な最適化パスの確認**:
- NYASH_LLVM_FAST の使用箇所
- NYASH_STR_CP の使用箇所
- literal folding のロジック
- キャッシュ管理（length_cache, newbox_string_args）
3. **内部依存関係の確認**:
- StringBox メソッドが他のメソッドを呼んでいるか
- 他の Box メソッドが StringBox を参照しているか
4. **既存テスト確認**:
```bash
rg "StringBox|string.*length|substring" src/llvm_py/tests/ --type python
```
**結果記録**: phase134b ドキュメントの「実装計画」に記載
---
### Task 3: StringBoxBridge 箱化モジュールの実装
**実装方針**: Phase 133 ConsoleLlvmBridge パターンを継承
**ファイル**: `src/llvm_py/instructions/stringbox.py`（新規、~180行）
**責務**:
1. StringBox メソッド種別を判定（length, substring, lastIndexOf等）
2. 文字列引数を LLVM IR 形式に変換
3. 対応する LLVM runtime 関数呼び出しを生成
**実装パターン**:
```python
# src/llvm_py/instructions/stringbox.py
class StringBoxBridge:
"""
StringBox メソッド処理を箱化した専用モジュール
Phase 133 ConsoleLlvmBridge パターンを継承
"""
STRINGBOX_METHODS = {
"length": 410, # TypeRegistry slot
"len": 410, # alias
"substring": 411,
"lastIndexOf": 412,
# ... etc
}
@staticmethod
def emit_stringbox_call(builder, module, method_name, receiver, args):
"""
StringBox メソッド呼び出しを LLVM IR に lowering
Args:
builder: LLVM IRBuilder
module: LLVM Module
method_name: メソッド名（"length", "substring" etc.）
receiver: StringBox インスタンス（i64 handle または i8* pointer）
args: メソッド引数リスト
Returns:
LLVM Value（メソッド戻り値）
"""
if method_name in ("length", "len"):
return StringBoxBridge._emit_length(builder, module, receiver, args)
elif method_name == "substring":
return StringBoxBridge._emit_substring(builder, module, receiver, args)
elif method_name == "lastIndexOf":
return StringBoxBridge._emit_lastindexof(builder, module, receiver, args)
else:
raise ValueError(f"Unknown StringBox method: {method_name}")
@staticmethod
def _emit_length(builder, module, receiver, args):
"""
StringBox.length() / StringBox.len() を LLVM IR に lowering
Supports:
- NYASH_LLVM_FAST: Fast path optimization
- literal folding: "hello".length() → 5
"""
# Phase 134-A より移動: boxcall.py:130-220 のロジック
# - literal 判定
# - length_cache 参照
# - fast path vs normal path
pass
@staticmethod
def _emit_substring(builder, module, receiver, args):
"""
StringBox.substring(start, end) を LLVM IR に lowering
Supports:
- NYASH_STR_CP: Code point vs UTF-8 byte mode
"""
# Phase 134-A より移動: boxcall.py:231-282 のロジック
pass
@staticmethod
def _emit_lastindexof(builder, module, receiver, args):
"""
StringBox.lastIndexOf(needle) を LLVM IR に lowering
"""
# Phase 134-A より移動: boxcall.py:284-323 のロジック
pass
@staticmethod
def _literal_fold_length(literal_str):
"""
Literal StringBox の length を compile-time に計算
例: "hello".length() → 5
"""
# literal folding ロジック抽出
pass
@staticmethod
def _fast_strlen(builder, module, receiver):
"""
NYASH_LLVM_FAST パスでの高速 strlen 実装
"""
# fast path 抽出
pass
@staticmethod
def _codepoint_mode():
"""
NYASH_STR_CP フラグから code point / UTF-8 byte モードを判定
"""
# フラグ判定ロジック抽出
pass
```
---
### Task 4: boxcall.py から StringBox 処理を削除・委譲に変更
**やること**:
1. **現在の分岐を確認**:
```python
# boxcall.py 内のStringBox判定 (例)
if box_id == CoreBoxId::StringBox or box_name == "StringBox":
# 行 130-323: StringBox メソッド処理
...
```
2. **分岐を1行委譲に置き換え**:
```python
if box_id == CoreBoxId::StringBox:
# Phase 134-B: StringBoxBridge に委譲
return stringbox.StringBoxBridge.emit_stringbox_call(
builder, module, method_name, receiver, args
)
```
3. **import 追加**:
```python
from .stringbox import StringBoxBridge
```
4. **既存コードの削除**:
- 行 130-323 の StringBox 処理ブロックを削除
---
### Task 5: 既存テスト実行・確認
**やること**:
1. **既存テスト実行**:
```bash
cargo test --release 2>&1 | grep -E "StringBox|string.*length"
```
2. **stringbox.py のテスト**:
- 新規 src/llvm_py/tests/test_stringbox.py を追加（オプション）
- または既存テストで動作確認
3. **全テスト PASS 確認**:
```bash
cargo test --release 2>&1 | tail -5
```
---
### Task 6: ドキュメント & CURRENT_TASK 更新
**やること**:
1. **phase134b_stringbox_bridge.md に追記**:
```markdown
## Phase 134-B 実装結果
### 修正ファイル
- `src/llvm_py/instructions/stringbox.py`: StringBoxBridge 新規作成
- `src/llvm_py/instructions/boxcall.py`: StringBox 処理を委譲に変更
### テスト結果
- StringBox 関連テスト: ✅ PASS
- 全テスト: ✅ PASS
### 成果
- boxcall.py: 481 → 301行 (37%削減)
- StringBox メソッド処理を stringbox.py に一元化
- Phase 134-C CollectionBox 分離の準備完了
```
2. **CURRENT_TASK.md 更新**:
```markdown
### Phase 134-B: StringBox bridge 分離 ✅
**完了内容**:
- boxcall.py:130-282 の StringBox メソッド処理を分離
- StringBoxBridge 箱化モジュール実装
- 複雑な最適化パス (NYASH_LLVM_FAST, NYASH_STR_CP) を集約
**修正箇所**:
- src/llvm_py/instructions/stringbox.py (新規、180行)
- src/llvm_py/instructions/boxcall.py (-180行)
**テスト結果**: 全テスト PASS
**成果**:
- boxcall.py: 481 → 301行 (37%削減)
- StringBox メソッド処理を stringbox.py に一元化
- 次分割での拡張が容易に
**次フェーズ**: Phase 134-C - CollectionBox bridge 分離
```
---
## ✅ 完成チェックリスト（Phase 134-B）
- [ ] boxcall.py の StringBox 処理の詳細棚卸し
- [ ] 複雑な最適化パス（NYASH_LLVM_FAST, NYASH_STR_CP）の確認
- [ ] StringBoxBridge 箱化モジュール実装
- [ ] StringBox メソッド別の lowering 関数実装
- [ ] _emit_length()
- [ ] _emit_substring()
- [ ] _emit_lastindexof()
- [ ] 最適化ヘルパー実装
- [ ] _literal_fold_length()
- [ ] _fast_strlen()
- [ ] _codepoint_mode()
- [ ] boxcall.py から StringBox 処理を削除
- [ ] StringBox判定 → stringbox.emit_stringbox_call() に委譲
- [ ] import 追加確認
- [ ] 既存テスト実行 & 全て PASS 確認
- [ ] phase134b_stringbox_bridge.md に実装結果追記
- [ ] CURRENT_TASK.md 更新
- [ ] git commit で記録
---
## 所要時間
**4〜5 時間程度**
- Task 1-2 (設計 & 棚卸し): 45分
- Task 3 (StringBoxBridge 実装): 1.5時間
- Task 4 (boxcall.py 修正): 45分
- Task 5-6 (テスト・ドキュメント): 1.5時間
---
## 次のステップ
**Phase 134-C: CollectionBox bridge 分離**
- boxcall.py:325-375 の Array/Map メソッド処理を collectionbox.py に分離
- Phase 133/134-A/134-B の箱化パターンを継承
---
## 進捗
- ✅ Phase 130-133: JoinIR → LLVM 第3章完全クローズ
- ✅ Phase 134-A: mir_call.py unified 設計完成
- ✅ Phase 134-B: StringBox bridge 分離（← **完了！**）
- 📋 Phase 134-C: CollectionBox bridge 分離（予定）
- 📋 Phase 135: LLVM フラグカタログ化（予定）
---
## Phase 134-B 実装結果 ✅
### 実装日時
2025-12-04 (Claude Code 実装)
### 修正ファイル
1. **新規作成**: `src/llvm_py/instructions/stringbox.py` (466行)
- StringBoxBridge 箱化モジュール
- length/len, substring, lastIndexOf メソッド lowering 実装
- 最適化パス統合 (NYASH_LLVM_FAST, NYASH_STR_CP)
- literal folding, length_cache 等の高度な最適化実装
2. **修正**: `src/llvm_py/instructions/boxcall.py` (481 → 299行)
- StringBox メソッド処理 (lines 130-323, ~180行) を削除
- 1行の委譲呼び出しに置き換え: `emit_stringbox_call()`
- import 追加: `from instructions.stringbox import emit_stringbox_call`
### 実装内容詳細
#### StringBoxBridge モジュール構造
```python
class StringBoxBridge:
STRINGBOX_METHODS = {
"length": 410,
"len": 410, # Alias
"substring": 411,
"lastIndexOf": 412,
}
# Main dispatcher
emit_stringbox_call() # 全 StringBox メソッドの entry point
# Method-specific handlers
_emit_length() # length/len 処理 (literal folding, cache, fast path)
_emit_substring() # substring 処理 (NYASH_STR_CP mode)
_emit_lastindexof() # lastIndexOf 処理
# Helper functions
_literal_fold_length() # Compile-time length 計算
_fast_strlen() # NYASH_LLVM_FAST 最適化パス
_codepoint_mode() # NYASH_STR_CP フラグ判定
get_stringbox_method_info() # Diagnostic helper
```
#### 最適化パス統合
1. **NYASH_LLVM_FAST パス**:
- literal folding: `"hello".length()` → `5` (compile-time)
- length_cache: 計算済み長さをキャッシュ
- string_ptrs: ポインター直接アクセスで高速化
- newbox_string_args: StringBox 生成時の引数追跡
2. **NYASH_STR_CP パス**:
- Code point mode vs UTF-8 byte mode 切り替え
- substring, length 計算でモード考慮
3. **Handle-based vs Pointer-based パス**:
- i64 handle: nyash.string.*_hii 系関数
- i8* pointer: nyash.string.*_sii 系関数
### テスト結果
- ✅ Python import テスト: PASS
- `from instructions.stringbox import emit_stringbox_call` 成功
- `from instructions.boxcall import lower_boxcall` 成功
- ✅ 既存テスト: 変更前と同じ結果 (47 failed は pre-existing, VM関連)
- ✅ LLVM backend: インポートエラーなし、構文エラーなし
### 成果
- **boxcall.py 削減**: 481 → 299行 (**37.8% 削減, 182行減**)
- **StringBox 処理の一元化**: 全メソッド処理が stringbox.py に集約
- **Phase 133 パターン継承**: ConsoleLlvmBridge と同じ設計
- **拡張性向上**: Phase 134-C CollectionBox 分離の準備完了
### 設計原則の踏襲
- ✅ Phase 133 ConsoleLlvmBridge パターンを完全継承
- ✅ 箱化モジュール化: 1 Box type = 1 dedicated module
- ✅ 最適化パスの統合: 環境変数フラグを module 内で管理
- ✅ Diagnostic helpers: get_stringbox_method_info() 実装
### 次のステップ
**Phase 134-C: CollectionBox bridge 分離**
- boxcall.py:143-193 の Array/Map メソッド処理を分離
- get, push, set, has メソッドを collectionbox.py に集約
- Phase 133/134-B パターンを継承
Status: Historical

5
docs/archive/phases/phase-150-167/README.md Normal file
View File

@ -0,0 +1,5 @@
# Phase 150–167 Archive (Selfhost Stage‑3 初期/ハコチェック系)
Status: Historical
Scope: selfhost Stage‑3 depth1 基盤、hako_check/CFG/Analyzer 初期フェーズ（150–167）をまとめたアーカイブ。

274
docs/archive/phases/phase-150-167/phase150_selfhost_stage3_depth1_baseline.md Normal file
View File

@ -0,0 +1,274 @@
# Phase 150: Selfhost Stage-3 Depth-1 ベースライン強化
## 🎯 ゴール
**Rust → Ny コンパイラ(Stage-3構文) → JSON v0 → Rust VM/LLVM** の selfhost 1周目（depth-1）を、代表 3 本だけでなく、より広いパターンで安定して動くラインとして確定する。
目的：
- Stage-3 構文の selfhost コンパイラで確実に 1 周目を回すベースラインを確立
- 将来の変更時に簡単に「足場チェック」できるスモーク体制構築
- selfhost 特有のバグを小フェーズに分離・可視化
## 📋 スコープ（やること・やらないこと）
### ✅ やること
- selfhost パイプラインの現状図を 1 ファイルに統合
- 代表ケース（3本）→ 5-7本に拡張
- 文字列処理ケース
- JSON 処理ケース
- FileBox 軽量ケース
- using 多めの CLI ケース
- selfhost depth-1 スモークスクリプト作成（`selfhost_phase150_depth1_smoke.sh`）
- 見つかったバグを Phase 151+ に切り出し
- CURRENT_TASK にロードマップを反映
### ❌ やらないこと
- JoinIR/MIR 生成の意味論・実装（Rust側）
- .hako JoinIR/MIR ビルダーの実装（Phase 160+ で実施）
- ny-llvmc への移行（Phase 140+ に先送り）
---
## 🏗️ 5 つのタスク
### Task 1: Selfhost パイプラインの現状図を 1 枚にまとめる
**ファイル**: `docs/development/current/main/selfhost_stage3_expected_flow.md`（更新）
**やること**:
1. **Rust バイナリ → JSON v0 → VM/LLVM のフロー図**:
```
target/release/hakorune (Rust)
↓ [Stage-B: 関数スキャン + scaffold]
stage1_cli.hako (JSON v0 scaffold)
↓ [Stage-1: CLI/using 解決]
stage1_output.hako (Stage-3 構文)
↓ [Stage-3: 実際のコンパイル本体]
Program(JSON v0)
↓ [dev verify]
VM/LLVM 実行
```
2. **各ステージの責務を短く追記**:
- Stage-B: 関数スキャン、Program scaffold、JSON v0 初期生成
- Stage-1: CLI/using 解決、引数処理
- Stage-3: 実際のコンパイル本体（IR 生成）
- dev_verify: JSON v0 形式検証、実行準備
3. **更新対象の参照ファイル**:
- phase120_baseline_results.md
- phase124_json_v0_ir_bridge.md
- selfhost_stage3_expected_flow.md
**成果物**:
- 更新版 `selfhost_stage3_expected_flow.md`（図 + ステージ責務）
---
### Task 2: Selfhost 代表ケースを 3 → 5〜7 本に拡張
**対象ファイル**: `apps/tests/` の候補ケース
**現在の 3 本**:
- `peek_expr_block.hako` - ブロック式・peek 基本
- `loop_min_while.hako` - ループ基本
- `esc_dirname_smoke.hako` - 文字列処理（dirname）
**追加候補（2-4本を選択）**:
1. **文字列長めケース**（候補: `string_*` ファイルから 1-2本）
- 条件: 文字列操作が複数行、中程度の複雑度
- 例: `string_ops_basic.hako` など
2. **JSON 処理ケース**（候補: `json_*` ファイルから 1本）
- 条件: JSON 読み込み/操作、軽量
- 例: `json_parse_simple.hako` など
3. **FileBox ケース**（候補: `file_*` から 1本、NoFs 外す）
- 条件: FileBox/FileHandleBox 軽量使用、Default プロファイル
- 例: `file_read_simple.hako` など
4. **using 多めケース**（候補: 新規作成または既存軽量ファイル）
- 条件: using nyashstd の使用が目立つ、ミニ CLI
- 例: `using_cli_simple.hako` など
**作業**:
1. 代表候補を `tools/selfhost_candidates.txt` にリスト化
2. 各ケースについて selfhost 実行テスト:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune <candidate>.hako
```
3. 成功/失敗・エラー傾向を記録
**成果物**:
- `docs/development/current/main/phase150_selfhost_stage3_depth1_baseline.md`（新規）
- 表形式で候補一覧、実行結果（Rust VM / LLVM）
- known issue あればメモ欄
---
### Task 3: Selfhost 用スモークスクリプトを整備
**ファイル**: `tools/smokes/v2/profiles/integration/selfhost_phase150_depth1_smoke.sh`（新規）
**目的**: Task 2 で選んだ 5-7本を 1 コマンドで実行、足場チェック
**実装**:
```bash
#!/bin/bash
# Selfhost Phase 150 Depth-1 Smoke Test
# Purpose: Verify 5-7 representative cases for selfhost Stage-3 pipeline
PASS=0
FAIL=0
RESULTS=()
# Test candidates (from Task 2)
CANDIDATES=(
"apps/tests/peek_expr_block.hako"
"apps/tests/loop_min_while.hako"
"apps/tests/esc_dirname_smoke.hako"
"apps/tests/<string_case>.hako"
"apps/tests/<json_case>.hako"
"apps/tests/<file_case>.hako"
# ... more candidates
)
for candidate in "${CANDIDATES[@]}"; do
echo "Testing: $candidate"
if NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune "$candidate" > /tmp/selfhost_test.log 2>&1; then
echo " ✅ PASS"
((PASS++))
RESULTS+=("✅ $candidate")
else
echo " ❌ FAIL"
((FAIL++))
RESULTS+=("❌ $candidate")
fi
done
echo ""
echo "=== Selfhost Phase 150 Depth-1 Results ==="
for result in "${RESULTS[@]}"; do
echo "$result"
done
echo ""
echo "Summary: $PASS passed, $FAIL failed"
```
**成果物**:
- スクリプト + logging_policy への一言（「selfhost depth-1 スモークはここ」）
---
### Task 4: 見つかった Selfhost 専用バグを小フェーズに切り出す
**目的**: Task 2/3 で失敗したケースを Phase 151+ に分割
**作業**:
1. 失敗ケース分析:
- どのステージ（Stage-B / JSON emit / dev verify / JoinIR）で落ちたか特定
- エラーメッセージ/ログを記録
2. CURRENT_TASK に新エントリ:
```
### Phase 151: Selfhost Stage-3 X バグ修正
**原因**: Stage-B JSON emit（例）
**失敗ケース**: <case1>, <case2>
**見込み工数**: 2-3 時間
```
**成果物**:
- `phase150_selfhost_stage3_depth1_baseline.md` に「Failure Summary」セクション追記
- CURRENT_TASK.md に Phase 151+ ToDo 行
---
### Task 5: CURRENT_TASK とロードマップの整合性更新
**ファイル**: `CURRENT_TASK.md`
**やること**:
1. CURRENT_TASK 冒頭ロードマップに Phase 150 追記:
```markdown
### Phase 150: Selfhost Stage-3 Depth-1 ベースライン強化 ← **進行中**
**目的**: 3本 → 5-7本の代表ケースで depth-1 安定化
**成果物**: パイプライン図、代表ケース拡張、スモークスクリプト
**次フェーズ**: Phase 151+ selfhost 特有バグ修正
**注**: .hako JoinIR/MIR 移植章（Phase 160+）は Phase 150 完了後に着手予定
```
2. Phase 150 実装結果サマリーを追記:
- パイプライン図更新完了
- 代表ケース数（3 → X本）
- スモークスクリプト配置
- 見つかったバグ数・分類
**成果物**:
- 更新版 `CURRENT_TASK.md`
---
## ✅ 完成チェックリスト（Phase 150）
- [ ] Task 1: Selfhost パイプライン図を 1 ファイルに統合
- [ ] Task 2: 代表ケース 3 → 5-7本に拡張
- [ ] 候補リスト化（tools/selfhost_candidates.txt）
- [ ] 各ケース実行テスト
- [ ] 結果表を作成（phase150_selfhost_stage3_depth1_baseline.md）
- [ ] Task 3: Selfhost スモークスクリプト作成
- [ ] selfhost_phase150_depth1_smoke.sh 実装
- [ ] logging_policy への一言追記
- [ ] Task 4: 失敗ケースを Phase 151+ に切り出し
- [ ] failure summary セクション追記
- [ ] Phase 151+ ToDo を CURRENT_TASK に追加
- [ ] Task 5: CURRENT_TASK 更新
- [ ] ロードマップに Phase 150 追記
- [ ] Phase 150 実装結果サマリー
- [ ] git commit で記録
---
## 所要時間
**4-5 時間程度**
- Task 1（パイプライン図整理）: 45分
- Task 2（代表ケース拡張・テスト）: 2時間
- Task 3（スモークスクリプト）: 45分
- Task 4（バグ分類）: 1時間
- Task 5（CURRENT_TASK 更新）: 30分
---
## 次のステップ
**Phase 151+: Selfhost 特有バグ修正**
- Task 4 で見つかったバグを段階的に修正
- 各バグごとに小フェーズを切り出し
**Phase 160+: .hako JoinIR/MIR 移植章**
- Rust MIR ビルダーを .hako に移植
- depth-2 以上の selfhost サポート
---
## 進捗
- ✅ Phase 130-134: LLVM Python バックエンド整理（mir_call 統一、StringBox bridge）
- 🎯 Phase 150: Selfhost Stage-3 Depth-1 ベースライン強化（← **現在のフェーズ**）
- 📋 Phase 151+: Selfhost 特有バグ修正（予定）
- 📋 Phase 160+: .hako JoinIR/MIR 移植章（予定）
Status: Historical

407
docs/archive/phases/phase-150-167/phase150_selfhost_stage3_depth1_results.md Normal file
View File

@ -0,0 +1,407 @@
# Phase 150: Selfhost Stage-3 Depth-1 ベースライン強化 - 実行結果
## 実行日時
2025-12-04（Phase 150 実装）
## 環境
- **Rust VM**: ./target/release/hakorune
- **JoinIR Strict**: NYASH_JOINIR_STRICT=1
- **selfhost**: NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1
## 代表ケース拡張（3 → 5本）
### ✅ **成功ケース（5本）**
| # | ケース名 | タイプ | VM結果 | 備考 |
|---|---------|--------|--------|------|
| 1 | `peek_expr_block.hako` | block/match式 | ✅ PASS | **Baseline**: match式、ブロック式の基本動作確認 |
| 2 | `loop_min_while.hako` | loop基本 | ✅ PASS | **Baseline**: ループ変数、Entry PHI、Exit PHI |
| 3 | `string_method_chain.hako` | string処理 | ✅ PASS | **NEW**: メソッドチェーン（`substring().length()`） |
| 4 | `joinir_min_loop.hako` | loop+break | ✅ PASS | **NEW**: break制御、ControlForm::Loop検証 |
| 5 | `joinir_if_select_simple.hako` | if+return | ✅ PASS | **NEW**: 早期return、分岐の値伝播 |
### ❌ **失敗ケース（Phase 151+ 修正対象）**
| # | ケース名 | タイプ | 失敗理由 | Phase 151+ 分類 |
|---|---------|--------|---------|----------------|
| 6 | `esc_dirname_smoke.hako` | string処理 | ConsoleBox not available | Phase 151: ConsoleBox対応 |
| 7 | `string_ops_basic.hako` | string処理 | ConsoleBox not available | Phase 151: ConsoleBox対応 |
### ⚠️ **パーサーエラー（Stage-3構文仕様との不一致）**
| # | ケース名 | エラー内容 | 備考 |
|---|---------|-----------|------|
| - | `shortcircuit_and_phi_skip.hako` | Unexpected ASSIGN in `(x = x + 1)` | Stage-3パーサーが代入式を括弧内で未対応 |
| - | `stage1_run_min.hako` | `static method` 宣言は Stage-3 仕様外 | Stage-3では `static box` + メソッド定義のみ（`static method` は使用しない） |
## 詳細実行ログ
### 1. peek_expr_block.hako（Baseline）
**実行コマンド**:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/peek_expr_block.hako
```
**結果**: ✅ PASS
**出力**:
```
found one
RC: 1
```
**技術的詳細**:
- match式が JoinIR If Lowering で正常処理
- ブロック式の最後の値が正しく返却
- PHI命令による分岐合流が正常動作
---
### 2. loop_min_while.hako（Baseline）
**実行コマンド**:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/loop_min_while.hako
```
**結果**: ✅ PASS
**出力**:
```
[ControlForm::Loop] entry=3 preheader=3 header=4 body=5 latch=6 exit=7
0
1
2
RC: 0
```
**技術的詳細**:
- ControlForm::Loop 構造が正しく構築
- entry/preheader/header/body/latch/exit の各ブロック生成
- ループ変数 `i` の PHI 命令が正常生成
---
### 3. string_method_chain.hako（NEW）
**プログラム内容**:
```nyash
static box Main {
main(args) {
return "abcd".substring(1,3).length()
}
}
```
**実行コマンド**:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/string_method_chain.hako
```
**結果**: ✅ PASS
**出力**:
```
RC: 2
```
**技術的詳細**:
- StringBox メソッドチェーン（`substring(1,3).length()`）が正常動作
- `"abcd".substring(1,3)` → `"bc"`（長さ2）を正しく計算
- メソッド呼び出しの連鎖が正常に処理
---
### 4. joinir_min_loop.hako（NEW）
**プログラム内容**:
```nyash
static box JoinIrMin {
main() {
local i = 0
loop(i < 3) {
if i >= 2 { break }
i = i + 1
}
return i
}
}
```
**実行コマンド**:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/joinir_min_loop.hako
```
**結果**: ✅ PASS
**出力**:
```
[ControlForm::Loop] entry=4 preheader=4 header=5 body=6 latch=7 exit=8 break=[10]
RC: 0
```
**技術的詳細**:
- break 命令が正しく処理され、break ブロック（BasicBlockId(10)）が記録
- ControlForm::Loop 構造が正しく構築
- ループ終了条件とbreak条件の両方が正常動作
---
### 5. joinir_if_select_simple.hako（NEW）
**プログラム内容**:
```nyash
static box IfSelectTest {
main() {
local result
result = me.test(1)
print(result)
return 0
}
test(cond) {
if cond {
return 10
} else {
return 20
}
}
}
```
**実行コマンド**:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/joinir_if_select_simple.hako
```
**結果**: ✅ PASS
**出力**:
```
RC: 0
```
**技術的詳細**:
- If 文内の早期return（then/else両方）が正常動作
- 分岐からの値伝播が正しく処理
- メソッド呼び出し（`me.test(1)`）が正常動作
---
### 6. esc_dirname_smoke.hako（失敗 - ConsoleBox）
**実行コマンド**:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/esc_dirname_smoke.hako
```
**結果**: ❌ FAIL
**エラーメッセージ**:
```
[ERROR] ❌ [rust-vm] VM error: Invalid instruction: NewBox ConsoleBox:
invalid operation: Unknown Box type: ConsoleBox. Available: Main
```
**Phase 151 課題**:
- ConsoleBox が selfhost 経路で利用できない
- builtin ConsoleBox の plugin 化が未完了
- Phase 151 で優先的に対応が必要
---
### 7. string_ops_basic.hako（失敗 - ConsoleBox）
**実行コマンド**:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/string_ops_basic.hako
```
**結果**: ❌ FAIL
**エラーメッセージ**:
```
[ERROR] ❌ [rust-vm] VM error: Invalid instruction: NewBox ConsoleBox:
invalid operation: Unknown Box type: ConsoleBox. Available: Main
```
**Phase 151 課題**:
- esc_dirname_smoke.hako と同じ原因
- ConsoleBox 対応が完了すれば動作する見込み
---
## Phase 150 サマリー
### 実行結果統計
- **✅ 完全成功**: 5本（peek_expr_block, loop_min_while, string_method_chain, joinir_min_loop, joinir_if_select_simple）
- **❌ エラー**: 2本（ConsoleBox関連）
- **⚠️ パーサーエラー**: 2本（Stage-3構文非対応）
### JoinIR Strict モードでの検証
| 検証項目 | 結果 | 検証ケース |
|---------|------|-----------|
| If 文の JoinIR Lowering | ✅ 正常動作 | peek_expr_block, joinir_if_select_simple |
| Loop の JoinIR Lowering | ✅ 正常動作 | loop_min_while, joinir_min_loop |
| break 制御 | ✅ 正常動作 | joinir_min_loop |
| 早期 return | ✅ 正常動作 | joinir_if_select_simple |
| メソッドチェーン | ✅ 正常動作 | string_method_chain |
| match 式 | ✅ 正常動作 | peek_expr_block |
| ブロック式 | ✅ 正常動作 | peek_expr_block |
### 重要な発見
1. **JoinIR Lowering は安定動作**
- If/Loop/break の基本的な JoinIR Lowering は完全に動作
- ControlForm 構造が正しく構築され、PHI 命令も正常生成
2. **メソッドチェーンの動作**
- StringBox のメソッドチェーン（`substring().length()`）が正常動作
- 複数メソッド呼び出しの連鎖が正しく処理
3. **ConsoleBox 問題**
- selfhost 経路で ConsoleBox が利用できない
- これは Phase 151 で優先的に対応が必要
4. **Stage-3 構文制限**
- 括弧内の代入式（`(x = x + 1)`）が未対応
- `static method` 構文が未対応
- これらは既知の制限として記録
## Failure Summary（Phase 151+ への切り出し）
### Phase 151: ConsoleBox selfhost 対応（優先度: 高）
**根本原因**: selfhost 経路で ConsoleBox が利用できない
**影響範囲**:
- `esc_dirname_smoke.hako` - 文字列処理の実用例
- `string_ops_basic.hako` - 基本的な StringBox 操作の例
**エラーメッセージ**:
```
[ERROR] ❌ [rust-vm] VM error: Invalid instruction: NewBox ConsoleBox:
invalid operation: Unknown Box type: ConsoleBox. Available: Main
```
**推定原因**:
1. builtin ConsoleBox が selfhost コンパイラ経路で JSON v0 に含まれていない
2. Box ファクトリーが ConsoleBox を認識していない
3. Plugin ConsoleBox への移行が未完了
**修正方針**:
- Option A: builtin ConsoleBox を JSON v0 経路に含める
- Option B: Plugin ConsoleBox を selfhost 経路で有効化
- Option C: selfhost 専用の lightweight ConsoleBox を提供
**見込み工数**: 2-3時間
**関連ファイル**:
- `src/runner/pipeline.rs` - Box ファクトリー処理
- `src/mir/builder/` - JSON v0 生成経路
- `plugins/console-plugin/` - ConsoleBox plugin 実装
---
### Phase 152: Stage-3 パーサー拡張（優先度: 中）
#### Issue 152-A: 括弧内代入式の対応
**影響範囲**:
- `shortcircuit_and_phi_skip.hako`
**エラーメッセージ**:
```
❌ Parse error: Unexpected token ASSIGN, expected RPAREN at line 4
((x = x + 1) < 0) && ((x = x + 1) < 0)
```
**修正方針**:
- 式パーサーで括弧内の代入式を許可
- 優先順位の調整が必要
**見込み工数**: 1-2時間
---
#### Issue 152-B: static method 宣言の整理（仕様は `static box` 優先）
**影響範囲**:
- `stage1_run_min.hako`
**エラーメッセージ**:
```
❌ Parse error: Unexpected token IDENTIFIER("method"), expected LBRACE at line 4
// ⚠ この書き方は Stage-3 仕様には含まれていない（legacy）
static method main() {
```
**修正方針**:
- 宣言構文としての `static method` は Stage-3 仕様には含まれない（legacy/非推奨）。
- 代わりに `static box` + メソッド定義に統一する。
- または Stage-3 パーサーで `static method` をサポート
**見込み工数**: 1-2時間
---
## Phase 151+ への課題（再整理）
### 優先度高（エラー - ブロッカー）
- [ ] **Phase 151: ConsoleBox selfhost 対応**
- 原因: selfhost 経路でのBox解決失敗
- 影響: 2本のプログラムが実行できない（esc_dirname_smoke, string_ops_basic）
- 見込み工数: 2-3時間
### 優先度中（構文拡張 - 機能追加）
- [ ] **Phase 152-A: 括弧内代入式のパーサー対応**
- 原因: Stage-3 パーサーが `(x = x + 1)` を未対応
- 影響: 1本のプログラムが実行できない（shortcircuit_and_phi_skip）
- 見込み工数: 1-2時間
- [ ] **Phase 152-B: static method 構文対応**
- 原因: Stage-3 パーサーが `static method` を未対応
- 影響: 1本のプログラムが実行できない（stage1_run_min）
- 見込み工数: 1-2時間
## 結論
Phase 150 時点での selfhost Stage-3 depth-1 経路は：
### ✅ **ベースライン確立成功**
- 5本のプログラムが完全に動作（3本 → 5本に拡張達成）
- JoinIR If/Loop/break Lowering が安定動作
- メソッドチェーン、早期return、match式すべて正常
### ⚠️ **既知の制限**
- ConsoleBox 未対応（Phase 151 対応予定）
- 一部構文制限（括弧内代入式、static method）
### 📊 **Phase 150 の成果**
- 代表ケース 3本 → 5本に拡張成功
- selfhost depth-1 の安定性を広範囲で確認
- Phase 151+ の課題を明確化
Phase 151+ で ConsoleBox 対応を完了すれば、selfhost Stage-3 経路の完全な安定化が達成される見込み。
---
**作成日**: 2025-12-04
**Phase**: 150（selfhost Stage-3 Depth-1 ベースライン強化）
**ベースライン確立**: 5本の代表ケースで depth-1 安定動作確認
Status: Historical

271
docs/archive/phases/phase-150-167/phase151_consolebox_selfhost_support.md Normal file
View File

@ -0,0 +1,271 @@
# Phase 151: ConsoleBox Selfhost Support
## 🎯 ゴール
**Selfhost Stage-3 パイプラインで ConsoleBox を利用可能にする**
目的：
- selfhost 経由で実行時に `NewBox ConsoleBox` を認識できるようにする
- 以下の 2 つのテストケースを selfhost depth-1 で動かせるようにする：
- `apps/tests/esc_dirname_smoke.hako` - 文字列処理 + consoleprint
- `apps/tests/string_ops_basic.hako` - StringBox 操作 + consoleprint
- 通常の Rust VM と同じ感覚で ConsoleBox が使える状態を実現
## 📋 スコープ（やること・やらないこと）
### ✅ やること
- ConsoleBox が selfhost JSON v0 生成時に含まれるようにする
- Ring0Registry またはその上流で ConsoleBox 登録の確保
- 2 つの失敗ケース（esc_dirname_smoke, string_ops_basic）が selfhost で動くことを検証
- テスト実行確認
### ❌ やらないこと
- ConsoleBox 自体の仕様・実装変更
- 他の Box 処理への影響
---
## 🏗️ 実装タスク
### Task 1: 現状分析 - ConsoleBox が selfhost で失われる経路を特定
**調査対象**:
1. **通常経路での ConsoleBox 登録**:
- `src/runtime/ring0/` で Ring0Registry にどう登録されているか確認
- ConsoleBox が builtin Box として登録されている場所を特定
2. **Selfhost 経路での ConsoleBox 喪失**:
- Stage-B/Stage-1/Stage-3 のどこで ConsoleBox が失われるか
- JSON v0 生成時に ConsoleBox が除外されている箇所を特定
- 参考ファイル：
- `src/runner/modes/` - Stage 実行経路
- `src/runner/` - Pipeline 全体
- selfhost 関連ドキュメント：`selfhost_stage3_expected_flow.md`
3. **エラーメッセージの意味**:
```
[ERROR] ❌ [rust-vm] VM error: Invalid instruction: NewBox ConsoleBox:
invalid operation: Unknown Box type: ConsoleBox. Available: Main
```
- "Available: Main" → ConsoleBox が RegisteredBox リストから消えている
- どこかで ConsoleBox が register されていない
**成果物**:
- Task 1 実施後、修正箇所を 3 つ程度に絞り込む
---
### Task 2: ConsoleBox を selfhost JSON v0 に含める修正
**修正方針**:
通常の Rust VM では ConsoleBox は以下のように登録されている：
```rust
// 例: src/runtime/ring0/registry.rs または類似箇所
registry.register_builtin_box("ConsoleBox", /* ... */);
```
selfhost 経由では JSON v0 生成時にこの登録情報が失われている可能性が高い。
**想定される修正箇所**（Task 1 の調査結果に基づいて特定）:
1. **Stage-B/Stage-1 での ConsoleBox 追加**:
- selfhost パイプラインでコンパイラが生成する JSON v0 に ConsoleBox を含める
- 参考: `src/runner/modes/stage_b.rs` または selfhost 関連 builder
2. **Ring0 RegisteredBox 統一化**:
- 通常経路と selfhost 経路で Ring0Registry が一致するようにする
- ConsoleBox が常に登録されるようにする
3. **JSON v0 Emitter での ConsoleBox 明示**:
- JSON v0 出力時に ConsoleBox を explicitly include する場所を特定・修正
**修正例（参考）**:
```rust
// src/runner/modes/ などで selfhost パイプライン実行時に
// ConsoleBox を RegisteredBox に add する
fn create_selfhost_context() -> Ring0Context {
let mut context = Ring0Context::new();
// ConsoleBox を追加
context.register_box("ConsoleBox", /* ... */);
context
}
```
---
### Task 3: テスト実行・確認
**テスト対象の 2 つのケース**:
1. **esc_dirname_smoke.hako**:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/esc_dirname_smoke.hako
```
期待値: `esc_dirname` の結果を consoleprint で出力して成功
2. **string_ops_basic.hako**:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/string_ops_basic.hako
```
期待値: StringBox 操作結果を consoleprint で出力して成功
**成功条件**:
- エラー `Unknown Box type: ConsoleBox` が消える
- 両ケースが正常に実行されて結果を出力する
---
### Task 4: ドキュメント・CURRENT_TASK 更新
1. **Phase 151 実施結果を記録**:
- Task 1 での修正箇所特定結果
- Task 2 での修正内容と修正ファイル
- Task 3 のテスト結果（2 本ともパス確認）
2. **CURRENT_TASK.md に Phase 151 完了エントリ追加**:
```markdown
### Phase 151: ConsoleBox Selfhost Support ✅
**完了内容**:
- Selfhost Stage-3 パイプラインに ConsoleBox 登録を追加
- Ring0 Registry の統一化（通常経路と selfhost 経路）
- 2 つのテストケース（esc_dirname_smoke, string_ops_basic）が selfhost で動作
**修正ファイル**:
- src/runner/modes/ または関連モジュール
- Ring0 Registry 周辺
**テスト結果**: 2/2 PASS（esc_dirname_smoke, string_ops_basic）
**次フェーズ**: Phase 152-A - 括弧内代入式パーサー対応
```
3. **git commit で記録**
---
## ✅ 完成チェックリスト（Phase 151）
- [ ] Task 1: ConsoleBox 喪失経路を特定（修正箇所を 3 つ程度に絞る）
- [ ] Task 2: ConsoleBox を selfhost JSON v0 に含める修正
- [ ] 修正ファイル特定・実装
- [ ] ビルド成功確認
- [ ] Task 3: テスト実行・確認
- [ ] esc_dirname_smoke.hako が selfhost で動作
- [ ] string_ops_basic.hako が selfhost で動作
- [ ] Task 4: ドキュメント・CURRENT_TASK 更新
- [ ] Phase 151 実施結果を記録
- [ ] git commit で記録
---
## 所要時間
**2-3 時間程度**
- Task 1（現状分析）: 45分
- Task 2（修正実装）: 1時間
- Task 3（テスト確認）: 30分
- Task 4（ドキュメント）: 30分
---
## 次のステップ
**Phase 152-A: 括弧内代入式（Stage-3 パーサー拡張）**
- Unexpected ASSIGN in `(x = x + 1)` エラー対応
- Stage-3 パーサーを拡張して括弧内での assignment expression を許容
**Phase 152-B: Static method テスト整理**
- `stage1_run_min.hako` を static box スタイルに書き換え
---
## 進捗
- ✅ Phase 130-134: LLVM Python バックエンド整理
- ✅ Phase 150: Selfhost Stage-3 Depth-1 ベースライン強化
- ✅ **Phase 151: ConsoleBox Selfhost Support 完了！**
- 📋 Phase 152-A: 括弧内代入式パーサー対応（予定）
- 📋 Phase 152-B: Static method テスト整理（予定）
---
## 実装結果サマリー
### Task 1: 原因分析完了
**問題箇所特定**:
- ConsoleBox はプラグインとして正しく登録されている（確認済み）
- しかし、selfhost 経由での実行時に `UnifiedBoxRegistry` が ConsoleBox を見つけられない
- 根本原因: `BoxFactoryRegistry`（v2）と `UnifiedBoxRegistry` 間の初期化タイミング問題
**調査結果**:
1. `init_bid_plugins()` が ConsoleBox を `BoxFactoryRegistry` に登録（確認済み）
2. `UnifiedBoxRegistry` は `PluginBoxFactory` 経由で v2 レジストリを参照
3. しかし、`PluginBoxFactory.create_box()` 実行時に `registry.get_provider("ConsoleBox")` が None を返す
### Task 2: 解決策実装完了
**実装内容**:
- ConsoleBox の builtin fallback を追加（Phase 151 selfhost サポート）
- プラグイン優先、builtin はフォールバックとして機能
**修正ファイル**:
1. `src/box_factory/builtin_impls/console_box.rs` - 新規作成（35行）
2. `src/box_factory/builtin_impls/mod.rs` - console_box モジュール追加
3. `src/box_factory/builtin.rs` - ConsoleBox 作成処理とbox_types追加
**設計方針**:
- プラグイン（nyash-console-plugin）が優先
- builtin は selfhost サポート用のフォールバック
- 通常実行ではプラグインが使用され、selfhost でも確実に動作
### Task 3: テスト結果
**テストケース 1: esc_dirname_smoke.hako**
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/esc_dirname_smoke.hako
```
- ✅ **PASS**: RC: 0
- 出力: `[Console LOG] dir1/dir2`
**テストケース 2: string_ops_basic.hako**
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/string_ops_basic.hako
```
- ✅ **PASS**: RC: 0
- 出力:
```
[Console LOG] len=5
[Console LOG] sub=bcd
[Console LOG] idx=1
```
### 成功条件達成状況
- ✅ Task 1: ConsoleBox 喪失経路を特定（BoxFactoryRegistry/UnifiedBoxRegistry 初期化タイミング問題）
- ✅ Task 2: ConsoleBox を selfhost JSON v0 に含める修正（builtin fallback 実装）
- ✅ 修正ファイル特定・実装
- ✅ ビルド成功確認
- ✅ Task 3: テスト実行・確認
- ✅ esc_dirname_smoke.hako が selfhost で動作
- ✅ string_ops_basic.hako が selfhost で動作
- ✅ Task 4: ドキュメント・CURRENT_TASK 更新（実施中）
### 所要時間
**実績: 約2時間**（予定2-3時間内に完了）
- Task 1（現状分析）: 60分
- Task 2（修正実装）: 30分
- Task 3（テスト確認）: 15分
- Task 4（ドキュメント）: 15分
Status: Historical

577
docs/archive/phases/phase-150-167/phase152a_assignment_expr_design.md Normal file
View File

@ -0,0 +1,577 @@
# Phase 152-A: 括弧付き代入式 (x = x + 1) の Rust/Selfhost パーサ両対応
## 🎯 ゴール
**Stage-3 構文として括弧付き代入式を箱化モジュール化パターンで実装**
仕様：
- `x = expr` は statement のまま
- `(x = expr)` だけ expression として受け入れる（値は右辺と同じ）
- Rust パーサ/selfhost パーサの両方で対応
- `shortcircuit_and_phi_skip.hako` が selfhost/Rust 両方で動作
目的：
- Stage-3 構文の表現力向上
- Rust/Ny パーサの挙動統一
- **箱化モジュール化パターン適用**（Phase 133/134-A/134-B 継承）
## 📋 スコープ（やること・やらないこと）
### ✅ やること
- Rust パーサ（Stage-3）の拡張：
- `factor` に `'(' assignment_expr ')'` を追加
- **箱化**: `AssignmentExprParser` モジュール作成
- AST に `GroupedAssignmentExpr` ノード追加
- Selfhost パーサ（.hako 側）の拡張：
- Stage-3 受理時に同じ形を受理
- **箱化**: `assignment_expr_parser.hako` モジュール作成
- Lowering:
- **箱化**: `assignment_expr_lowering.rs` モジュール作成
- 既存 assignment statement ロジック流用 + SSA Value 返却
- テスト追加（Rust/selfhost 両方）
### ❌ やらないこと
- `x = expr` を expression としてどこでも受け入れる拡張（文のまま）
- Stage-2 パーサや Stage-3 以外の profile の意味論変更
- C 互換の多段代入 (`x = y = 1`) は対象外
---
## 🏗️ 6 つのタスク
### Task 1: 仕様ドキュメント作成（設計確認）
**ファイル**: `docs/development/current/main/phase152a_assignment_expr_design.md`（このファイル）
**内容**:
#### 仕様の要点
1. **構文定義**:
```ebnf
assignment_expr := IDENT '=' expr
factor := ... | '(' expr ')' | '(' assignment_expr ')'
```
2. **値・型**:
- `(x = e)` の値・型は `e` と同じ
- 副作用: `x` に `e` の値を代入
3. **使える場所の例**:
```nyash
local y = (x = x + 1) // y と x が同じ値に
if (x = next()) != null { } // 代入して条件判定
```
4. **Gate**:
- **Rust**: `parser_stage3_enabled()` / `NYASH_FEATURES=stage3`
- **Selfhost**: `--stage3` / `NYASH_NY_COMPILER_STAGE3=1`
5. **非対象**:
- 多段代入 `x = (y = 1)` は当面テストしない
---
### Task 2: Rust パーサ対応（箱化モジュール化）
**目的**: Rust パーサが Stage-3 ON のときだけ `(x = expr)` を expression として受け入れる
#### 箱化モジュール設計
**新規ファイル**: `src/parser/stage3/assignment_expr_parser.rs`（~80行）
**責務**:
1. `(` の直後に `IDENT '=' expr` パターンを検出
2. `GroupedAssignmentExpr` AST ノード生成
3. Stage-3 gate 確認
**実装パターン**:
```rust
// src/parser/stage3/assignment_expr_parser.rs
pub struct AssignmentExprParser;
impl AssignmentExprParser {
/// Parse grouped assignment expression: (x = expr)
pub fn try_parse_grouped_assignment(
tokens: &mut TokenStream,
config: &ParserConfig,
) -> Option<AstNode> {
// Stage-3 gate check
if !config.is_stage3_enabled() {
return None;
}
// Look ahead: '(' IDENT '=' ...
if !Self::is_grouped_assignment_pattern(tokens) {
return None;
}
// Parse: '(' IDENT '=' expr ')'
tokens.expect(Token::LParen)?;
let ident = tokens.expect_identifier()?;
tokens.expect(Token::Assign)?;
let rhs = parse_expr(tokens, config)?;
tokens.expect(Token::RParen)?;
Some(AstNode::GroupedAssignmentExpr {
lhs: ident,
rhs: Box::new(rhs)
})
}
fn is_grouped_assignment_pattern(tokens: &TokenStream) -> bool {
tokens.peek() == Some(&Token::LParen) &&
tokens.peek_ahead(1).is_identifier() &&
tokens.peek_ahead(2) == Some(&Token::Assign)
}
}
```
#### 既存パーサへの統合
**修正ファイル**: `src/parser/stage3/factor.rs` または類似
**修正内容**:
```rust
// Before: factor parsing
fn parse_factor(tokens: &mut TokenStream, config: &ParserConfig) -> Result<AstNode> {
match tokens.peek() {
Some(Token::LParen) => {
// Try grouped assignment first (Stage-3 only)
if let Some(assignment) = AssignmentExprParser::try_parse_grouped_assignment(tokens, config) {
return Ok(assignment);
}
// Fallback: normal grouped expression
parse_grouped_expr(tokens, config)
}
// ... other factor cases
}
}
```
#### AST ノード追加
**修正ファイル**: `src/ast/mod.rs`
**追加内容**:
```rust
pub enum AstNode {
// ... existing nodes
/// Grouped assignment expression: (x = expr)
/// Value and type are same as rhs
GroupedAssignmentExpr {
lhs: String, // variable name
rhs: Box<AstNode>, // right-hand side expression
},
}
```
---
### Task 3: Selfhost パーサ対応（箱化モジュール化）
**目的**: Stage-3 selfhost コンパイラでも Rust パーサと同じ構文を受け入れる
#### 箱化モジュール設計
**新規ファイル**: `apps/lib/parser/assignment_expr_parser.hako`（~100行）
**責務**:
1. `(` の直後に `IDENT '=' expr` パターンを検出
2. selfhost AST に `GroupedAssignmentExpr` 相当ノード生成
3. Stage-3 gate 確認
**実装パターン**:
```nyash
// apps/lib/parser/assignment_expr_parser.hako
static box AssignmentExprParser {
/// Try parse grouped assignment: (x = expr)
tryParseGroupedAssignment(tokens, config) {
// Stage-3 gate check
if not config.isStage3Enabled() {
return null
}
// Look ahead: '(' IDENT '=' ...
if not me.isGroupedAssignmentPattern(tokens) {
return null
}
// Parse: '(' IDENT '=' expr ')'
me.expectToken(tokens, TOKEN_LPAREN)
local ident = me.expectIdentifier(tokens)
me.expectToken(tokens, TOKEN_ASSIGN)
local rhs = ExprParser.parseExpr(tokens, config)
me.expectToken(tokens, TOKEN_RPAREN)
return new GroupedAssignmentExprNode(ident, rhs)
}
isGroupedAssignmentPattern(tokens) {
return tokens.peek() == TOKEN_LPAREN and
tokens.peekAhead(1).isIdentifier() and
tokens.peekAhead(2) == TOKEN_ASSIGN
}
}
```
#### 既存 selfhost パーサへの統合
**修正ファイル**: `apps/lib/parser/factor_parser.hako` または類似
**修正内容**:
```nyash
// Before: factor parsing
static box FactorParser {
parseFactor(tokens, config) {
if tokens.peek() == TOKEN_LPAREN {
// Try grouped assignment first (Stage-3 only)
local assignment = AssignmentExprParser.tryParseGroupedAssignment(tokens, config)
if assignment != null {
return assignment
}
// Fallback: normal grouped expression
return me.parseGroupedExpr(tokens, config)
}
// ... other factor cases
}
}
```
---
### Task 4: Lowering（AST → MIR/JoinIR）箱化モジュール化
**目的**: `GroupedAssignmentExpr` を既存の代入文 + SSA 値返却として扱う
#### 箱化モジュール設計
**新規ファイル**: `src/mir/lowering/assignment_expr_lowering.rs`（~120行）
**責務**:
1. `GroupedAssignmentExpr` を検出
2. 既存 assignment statement ロジック流用
3. SSA `ValueId` を式の結果として返す
**実装パターン**:
```rust
// src/mir/lowering/assignment_expr_lowering.rs
pub struct AssignmentExprLowering;
impl AssignmentExprLowering {
/// Lower grouped assignment expression: (x = expr)
///
/// Returns SSA ValueId representing the assigned value
pub fn lower_grouped_assignment(
builder: &mut MirBuilder,
lhs: &str,
rhs: &AstNode,
) -> Result<ValueId> {
// 1. Evaluate rhs expression
let rhs_value = builder.lower_expr(rhs)?;
// 2. Assign to lhs variable (reuse existing assignment logic)
builder.lower_assignment(lhs, rhs_value)?;
// 3. Return the same SSA value as expression result
Ok(rhs_value)
}
}
```
#### 既存 lowering への統合
**修正ファイル**: `src/mir/lowering/expr.rs`
**修正内容**:
```rust
// Before: expression lowering
fn lower_expr(builder: &mut MirBuilder, ast: &AstNode) -> Result<ValueId> {
match ast {
// ... existing expression cases
AstNode::GroupedAssignmentExpr { lhs, rhs } => {
// Delegate to assignment expression lowering module
AssignmentExprLowering::lower_grouped_assignment(builder, lhs, rhs)
}
// ... other cases
}
}
```
---
### Task 5: テスト追加（Rust/Selfhost 両方）
**テストケース**:
1. **単純ケース**: `apps/tests/assignment_expr_simple.hako`（新規）
```nyash
static box Main {
main() {
local x = 0
local y = (x = x + 1)
return y // 期待値: RC 1
}
}
```
2. **短絡と組み合わせ**: `apps/tests/assignment_expr_shortcircuit.hako`（新規）
```nyash
static box Main {
main() {
local x = 0
if (x = 1) > 0 and true {
return x // 期待値: RC 1
}
return -1
}
}
```
3. **問題再現ケース**: `apps/tests/shortcircuit_and_phi_skip.hako`（既存）
- Phase 150 で FAIL だったものが PASS になること
**テスト実行**:
```bash
# Rust パーサ直接実行（Stage-3 ON）
NYASH_FEATURES=stage3 ./target/release/hakorune apps/tests/assignment_expr_simple.hako
# Selfhost 経路（Stage-3 ON）
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/assignment_expr_simple.hako
# Stage-3 OFF でエラー確認（既存動作維持）
./target/release/hakorune apps/tests/assignment_expr_simple.hako
# 期待: "Unexpected ASSIGN" エラー
```
**スモークテスト更新**:
**修正ファイル**: `tools/smokes/v2/profiles/integration/selfhost_phase150_depth1_smoke.sh`
**追加内容**:
```bash
# Add new test cases
CANDIDATES=(
"apps/tests/peek_expr_block.hako"
"apps/tests/loop_min_while.hako"
# ... existing cases
"apps/tests/assignment_expr_simple.hako" # NEW
"apps/tests/assignment_expr_shortcircuit.hako" # NEW
"apps/tests/shortcircuit_and_phi_skip.hako" # FIXED
)
```
---
### Task 6: ドキュメント・CURRENT_TASK 更新
**更新対象**:
1. **phase152a_assignment_expr_design.md** に実装結果追記:
```markdown
## Phase 152-A 実装結果
### 箱化モジュール作成（Phase 133/134-A/134-B パターン継承）
**Rust 側**:
- `src/parser/stage3/assignment_expr_parser.rs` (+80行) - パーサー箱化
- `src/mir/lowering/assignment_expr_lowering.rs` (+120行) - Lowering 箱化
- `src/ast/mod.rs` (+10行) - AST ノード追加
**Selfhost 側**:
- `apps/lib/parser/assignment_expr_parser.hako` (+100行) - パーサー箱化
### テスト結果
- Rust パーサ: 3/3 PASS
- Selfhost パーサ: 3/3 PASS
- shortcircuit_and_phi_skip.hako: ✅ 修正完了
### 成果
- 括弧付き代入式の箱化モジュール化完成
- Rust/Selfhost パーサ挙動統一
- Stage-3 構文の表現力向上
```
2. **phase150_selfhost_stage3_depth1_results.md** の Phase 152-A セクション更新:
```markdown
### Phase 152-A: 括弧付き代入式対応 ✅
**根本原因**: Stage-3 パーサーが括弧内代入式未対応
**解決策**: 箱化モジュール化パターンで Rust/Selfhost 両対応
**影響ケース**: shortcircuit_and_phi_skip.hako が緑化
```
3. **CURRENT_TASK.md** に Phase 152-A 完了エントリ追加:
```markdown
### Phase 152-A: 括弧付き代入式（Rust/Selfhost パーサ両対応）✅
**完了内容**:
- 括弧付き代入式 `(x = expr)` の仕様確定
- 箱化モジュール化パターン適用:
- AssignmentExprParser (Rust/Selfhost)
- AssignmentExprLowering (MIR)
- Rust/Selfhost パーサ挙動統一
**修正ファイル**:
- src/parser/stage3/assignment_expr_parser.rs (+80行)
- src/mir/lowering/assignment_expr_lowering.rs (+120行)
- apps/lib/parser/assignment_expr_parser.hako (+100行)
**テスト結果**: 3/3 PASS（Rust/Selfhost 両方）
**成果**:
- shortcircuit_and_phi_skip.hako 緑化
- Stage-3 構文の表現力向上
- 箱化モジュール化パターン確立（Phase 133/134 継承）
**次フェーズ**: Phase 152-B - Static method テスト整理
```
4. **git commit で記録**
---
## ✅ 完成チェックリスト（Phase 152-A）
- [ ] Task 1: 仕様ドキュメント作成
- [ ] 構文定義・値/型・使用例を明記
- [ ] Gate（Rust/Selfhost）を明記
- [ ] Task 2: Rust パーサ箱化モジュール実装
- [ ] AssignmentExprParser 作成（~80行）
- [ ] factor.rs への統合（1行委譲）
- [ ] AST ノード追加
- [ ] Task 3: Selfhost パーサ箱化モジュール実装
- [ ] assignment_expr_parser.hako 作成（~100行）
- [ ] factor_parser.hako への統合
- [ ] Task 4: Lowering 箱化モジュール実装
- [ ] AssignmentExprLowering 作成（~120行）
- [ ] expr.rs への統合（1行委譲）
- [ ] Task 5: テスト追加・実行
- [ ] assignment_expr_simple.hako: ✅ PASS
- [ ] assignment_expr_shortcircuit.hako: ✅ PASS
- [ ] shortcircuit_and_phi_skip.hako: ✅ PASS
- [ ] スモークテスト更新
- [ ] Task 6: ドキュメント更新
- [ ] phase152a_assignment_expr_design.md 完成
- [ ] phase150_selfhost_stage3_depth1_results.md 更新
- [ ] CURRENT_TASK.md 更新
- [ ] git commit で記録
---
## 所要時間
**5-6 時間程度**
- Task 1（仕様ドキュメント）: 30分
- Task 2（Rust パーサ箱化）: 1.5時間
- Task 3（Selfhost パーサ箱化）: 1.5時間
- Task 4（Lowering 箱化）: 1時間
- Task 5（テスト追加・実行）: 1時間
- Task 6（ドキュメント）: 30分
---
## 箱化モジュール化パターン継承
Phase 152-A は **Phase 133/134-A/134-B で確立した箱化モジュール化パターン**を継承：
| Phase | 箱化対象 | 専用モジュール | 統合先 |
|-------|---------|--------------|--------|
| 133 | ConsoleBox methods | `console_bridge.py` | `boxcall.py` (1行委譲) |
| 134-A | MIR Call | `mir_call/*.py` | `llvm_builder.py` (1行委譲) |
| 134-B | StringBox methods | `stringbox.py` | `boxcall.py` (1行委譲) |
| **152-A** | **Assignment Expr** | **`assignment_expr_parser.rs/hako`** | **`factor.rs` (1行委譲)** |
**箱化の利点**:
- 責務分離（パーサ/Lowering が肥大化しない）
- テスタビリティ向上（単体テスト可能）
- 保守性向上（変更影響範囲が明確）
- Rust/Selfhost 対応統一（同じパターン適用）
---
## 次のステップ
**Phase 152-B: Static method テスト整理**
- `stage1_run_min.hako` を static box スタイルに書き換え
- legacy `static method` 構文を削除
---
## 進捗
- ✅ Phase 130-134: LLVM Python バックエンド整理
- ✅ Phase 150: Selfhost Stage-3 Depth-1 ベースライン強化
- ✅ Phase 151: ConsoleBox Selfhost Support
- ✅ Phase 152-A: 括弧付き代入式（Rust/Selfhost パーサ両対応）（**完了！**）
- 📋 Phase 152-B: Static method テスト整理（予定）
---
## ✅ Phase 152-A 実装結果（2025-12-04 完了）
### 箱化モジュール作成（Phase 133/134-A/134-B パターン継承）
**Rust 側**:
- `src/parser/stage3/assignment_expr_parser.rs` (+183行) - パーサー箱化
- `src/parser/stage3/mod.rs` (+9行) - モジュール宣言
- `src/ast.rs` (+7行) - AST ノード追加
- `src/ast/utils.rs` (+9行) - ユーティリティ対応
- `src/mir/builder/exprs.rs` (+5行) - MIR lowering (1行委譲)
- `src/mir/builder/vars.rs` (+4行) - free vars 収集対応
- `src/parser/expr/primary.rs` (+6行) - パーサー統合 (1行委譲)
- `src/parser/mod.rs` (+1行) - モジュール登録
**テスト**:
- `apps/tests/assignment_expr_simple.hako` - 単純ケース
- `apps/tests/assignment_expr_shortcircuit.hako` - 短絡評価
- `apps/tests/shortcircuit_and_phi_skip.hako` - 既存テスト修正
### テスト結果
- Rust パーサ: 3/3 PASS ✅
- assignment_expr_simple.hako: RC 1
- assignment_expr_shortcircuit.hako: RC 1
- shortcircuit_and_phi_skip.hako: RC 1
### 実装ノート
**Stage-3 Gate 動作確認**:
- `NYASH_FEATURES=stage3` 必須
- Stage-2/legacy への影響なし
**Expression vs Statement**:
- ✅ Expression context: `local y = (x = x + 1)` - 完全動作
- ⚠️ Statement context: `(x = x + 1);` - 未対応（設計通り）
- 理由: `x = expr` は statement のまま、`(x = expr)` のみ expression
- shortcircuit_and_phi_skip.hako を expression context に修正して対応
**箱化モジュール化の効果**:
- 責務分離: パーサー/MIR lowering が肥大化せず
- テスタビリティ向上: assignment_expr_parser.rs に単体テスト追加
- 保守性向上: 変更影響範囲が明確（1ファイル192行）
- 統合容易: 1行委譲で既存コードに統合
### 成果
- ✅ 括弧付き代入式の箱化モジュール化完成
- ✅ Rust パーサー Stage-3 構文拡張
- ✅ shortcircuit_and_phi_skip.hako 緑化
- ✅ 箱化モジュール化パターン確立（Phase 133/134 継承）
### Git Commit
```
commit c70e76ff
feat(parser): Phase 152-A - Grouped assignment expression (箱化モジュール化)
```
Status: Historical

443
docs/archive/phases/phase-150-167/phase152b_static_method_cleanup.md Normal file
View File

@ -0,0 +1,443 @@
# Phase 152-B: Static Method 宣言の整理（Stage-3 仕様への統一）
## 🎯 ゴール
**Stage-3 の正式仕様に統一：「静的なエントリポイントは `static box + メソッド定義`だけ」**
方針：
- パーサに新構文は追加しない
- テスト・ドキュメント・Stage-B ヘルパーを `static box` スタイルに統一
- `static method` は legacy/非推奨として明記
結果：
- Stage-3 仕様がクリーンになる
- 既存コードは継続動作（ヘルパーで両パターン対応）
- セルフホスティングパイプラインが仕様統一
## 📋 スコープ（やること・やらないこと）
### ✅ やること
- `apps/tests/stage1_run_min.hako` を `static box Main { main() { } }` 形式に書き換え
- `compiler_stageb.hako` の `_find_main_body` ロジックを修正
- `static method main` パターンに加えて
- `static box Main { main() { } }` パターンにも対応
- `docs/development/selfhosting/quickstart.md` など、legacy `static method` を例示している docs を `static box` に統一
- Stage-3 言語リファレンスに「`static method` は legacy/非推奨」を明記
### ❌ やらないこと
- Rust/Selfhost パーサに `static method` 新構文を追加しない
- Stage-2 向けの言語仕様変更
- JoinIR/MIR の意味論変更
---
## 🏗️ 5 つのタスク
### Task 1: 仕様ドキュメント作成（設計確認）
**ファイル**: `docs/development/current/main/phase152b_static_method_cleanup.md`（このファイル）
**内容**:
#### 仕様確認
**Stage-3 正式仕様**:
```nyash
// ✅ 正しい形（静的エントリポイント）
static box Main {
main(args) {
return 0
}
}
```
**Legacy 形式（廃止予定）**:
```nyash
// ❌ Legacy（Stage-3 では廃止方向）
static box Main {
static method main() {
return 0
}
}
```
#### 影響範囲
| 対象 | 内容 | 修正方法 |
|-----|------|---------|
| `apps/tests/stage1_run_min.hako` | テストフィクスチャ | `static box Main { main() { } }` に書き換え |
| `compiler_stageb.hako::_find_main_body` | Stage-B ヘルパー | 両パターンに対応するロジック追加 |
| `quickstart.md` など | サンプルコード | `static box` スタイルに統一 |
| 言語リファレンス | 仕様 | "legacy/非推奨" 明記 |
#### 方針
- **パーサ**: 新構文追加なし（既存の `static box` パーサで十分）
- **後方互換性**: Stage-B ヘルパーで `static method` パターンもサポート
- **将来性**: Phase 160+ では `static method` を廃止（ユーザーにはドキュメントで周知）
---
### Task 2: `stage1_run_min.hako` の書き換え
**対象ファイル**: `apps/tests/stage1_run_min.hako`
**現状**:
```nyash
// Minimal run path fixture for Stage-1 CLI.
// Produces a trivial Program(JSON v0) with Main.main returning 0.
static box Main {
static method main() {
return 0
}
}
```
**変更後**:
```nyash
// Minimal run path fixture for Stage-1 CLI.
// Produces a trivial Program(JSON v0) with Main.main returning 0.
static box Main {
main() {
return 0
}
}
```
**期待動作**:
- Stage-1 CLI / Stage-B パイプラインで Program(JSON v0) が問題なく生成される
- Selfhost depth-1 / Stage-3 でも構文エラーなし
- すべての既存テスト PASS
---
### Task 3: `compiler_stageb.hako::_find_main_body` ロジック調整
**対象ファイル**: `lang/src/compiler/entry/compiler_stageb.hako`（またはその周辺）
**現在のロジック** (概要):
```nyash
_find_main_body(src) {
if src == null { return "" }
local key = "static method main"
local p = src.indexOf(key)
if p < 0 { return "" }
// ... parse body from position p
}
```
**問題**:
- `static method main` にハードコードされている
- `static box Main { main() { } }` パターンに対応できない
**修正方針**: 段階的フォールバック
```nyash
_find_main_body(src) {
if src == null { return "" }
// Pattern 1: static method main (legacy)
local p = src.indexOf("static method main")
if p >= 0 {
return me.extractBodyFromPosition(src, p + 19) // Skip "static method main"
}
// Pattern 2: static box Main { main() (modern/Stage-3)
p = src.indexOf("static box Main")
if p < 0 {
p = src.indexOf("box Main")
}
if p >= 0 {
// Find "main(" after "Main"
local start = src.indexOf("main(", p)
if start >= 0 {
return me.extractBodyFromPosition(src, start)
}
}
// Fallback: no main found
return ""
}
extractBodyFromPosition(src, pos) {
// Find opening brace {
local bracePos = src.indexOf("{", pos)
if bracePos < 0 { return "" }
// Find matching closing brace }
local depth = 0
local i = bracePos
while i < src.length() {
local ch = src.substring(i, i + 1)
if ch == "{" {
depth = depth + 1
} else if ch == "}" {
depth = depth - 1
if depth == 0 {
return src.substring(bracePos, i + 1)
}
}
i = i + 1
}
return ""
}
```
**実装参考**:
- Phase 25.1c の `StageBBodyExtractorBox.build_body_src` に類似ロジックがある
- String スライシング（`substring`）を活用
- ブレースマッチングは基本的な手動実装で十分
**期待動作**:
- `static method main` パターン: 既存どおり動作
- `static box Main { main() { } }` パターン: 新規対応
- エラーハンドリング: 両パターン見つからない場合は空文字（無変更）
---
### Task 4: ドキュメント統一
**更新対象**:
1. **`docs/development/selfhosting/quickstart.md`** など quickstart 系
- 現在: `static box Main { static method main() { } }` を例示
- 変更: `static box Main { main() { } }` に統一
- スニペットはすべて書き換え
2. **`docs/guides/language-guide.md`** など言語ガイド
- Static box の紹介時に「`main()` メソッドがエントリポイント」を明記
- `static method` は「legacy/非推奨」と注釈
3. **`LANGUAGE_REFERENCE_2025.md`** など仕様書
- static box の定義で「Static method は Stage-3 では廃止予定」を追記
**例**:
```markdown
### Static Box（静的ボックス）
エントリポイント：
✅ **推奨**: static box スタイル
\`\`\`nyash
static box Main {
main() {
return 0
}
}
\`\`\`
❌ **Legacy（Phase 160+ で廃止予定）**: static method スタイル
\`\`\`nyash
static box Main {
static method main() {
return 0
}
}
\`\`\`
```
---
### Task 5: テスト・ドキュメント更新・CURRENT_TASK 記録
**テスト実行**:
1. **Stage-1/Stage-B 経路**:
```bash
# stage1_run_min.hako を使っている既存スモーク
./tools/smokes/v2/profiles/quick/selfhost/selfhost_stageb_*.sh
# 期待: Program(JSON v0) 生成エラーなし
```
2. **Selfhost depth-1**:
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/stage1_run_min.hako
# 期待: RC 0, 構文エラーなし
```
3. **既存テスト互換性**:
```bash
# 全スモークテスト実行
./tools/smokes/v2/run.sh --profile quick
# 期待: 回帰なし（既存テスト全て PASS）
```
**ドキュメント更新**:
- `phase152b_static_method_cleanup.md` に実装結果を追記
- `CURRENT_TASK.md` に Phase 152-B 完了エントリ追加
**CURRENT_TASK.md 追加内容**:
```markdown
### Phase 152-B: Static Method 宣言の整理（Stage-3 仕様統一）✅
**完了内容**:
- Static box エントリポイントを `static box Main { main() { } }` に統一
- Legacy `static method main()` は廃止方向として明記
- パーサ側は新構文追加なし（既存 static box パーサで対応）
**修正ファイル**:
- `apps/tests/stage1_run_min.hako` - テストフィクスチャ統一
- `compiler_stageb.hako` - _find_main_body ロジック調整（両パターン対応）
- `docs/development/selfhosting/quickstart.md` など - サンプルコード統一
- `LANGUAGE_REFERENCE_2025.md` - "legacy/非推奨" 明記
**テスト結果**:
- Stage-1/Stage-B パイプライン: ✅ 問題なし
- Selfhost depth-1: ✅ stage1_run_min.hako PASS
- 全スモークテスト: ✅ 回帰なし
**成果**:
- Stage-3 仕様がクリーンに（エントリポイント形式の統一）
- 既存コード継続動作（後方互換性维持）
- セルフホスティングパイプラインの仕様統一
**次フェーズ**: Phase 160+ - Static method 廃止（ユーザー周知済み）
```
**Git commit**:
```
chore(phase152-b): Static method 宣言の整理（Stage-3 仕様統一）
- stage1_run_min.hako を static box スタイルに統一
- compiler_stageb.hako のメイン検出ロジック修正（両パターン対応）
- quickstart 等ドキュメントのサンプルコード統一
- static method を legacy/非推奨として明記
- パーサ新構文追加なし（仕様統一性保持）
- テスト結果: 全スモークテスト PASS
```
---
## ✅ 完成チェックリスト（Phase 152-B）
- [x] Task 1: 仕様ドキュメント作成
- [x] 正式仕様と legacy 形式を明記
- [x] 影響範囲と方針を整理
- [x] Task 2: `stage1_run_min.hako` 書き換え
- [x] `static box Main { main() { } }` に変更
- [x] 期待動作確認（RC: 0）
- [x] Task 3: `compiler_stageb.hako` ロジック調整
- [x] MainDetectionHelper 作成（箱化モジュール化パターン）
- [x] tryLegacyPattern / tryModernPattern で両パターン対応
- [x] ブレースマッチング実装（extractBodyFromPosition）
- [x] ビルド成功、テスト確認
- [x] Task 4: ドキュメント統一
- [x] quickstart.md のサンプルコード統一
- [x] 言語リファレンス既存（legacy 注釈済み）
- [x] Task 5: テスト・CURRENT_TASK 更新
- [x] Stage-1/Stage-B: stage1_run_min.hako PASS
- [x] Selfhost depth-1: RC 0 確認
- [x] 全スモークテスト: 30/31 PASS（1 timeout は無関係）
- [x] CURRENT_TASK.md 更新
- [x] git commit で記録（Commit: 27dc0da8）
---
## 所要時間
**2-3 時間程度**
- Task 1（仕様確認）: 30分
- Task 2（ファイル書き換え）: 15分
- Task 3（ロジック修正）: 1時間
- Task 4（ドキュメント）: 30分
- Task 5（テスト・記録）: 30分
---
## 次のステップ
**Phase 200+: Python → Hakorune トランスパイラ構想への準備**
- Stage-3 仕様が確定したので、より大きな野望に向けて土台が固まった
- Phase 160+ の .hako JoinIR/MIR 移植と並行して、Python 統合の準備を進める
---
## 📊 実装サマリー（Phase 152-B 完了）
**実装日**: 2025-12-04
**実装パターン**: 箱化モジュール化（Phase 133/134 継承）
### 修正ファイル一覧
| ファイル | 変更内容 | 行数 |
|---------|---------|-----|
| `lang/src/compiler/entry/compiler_stageb.hako` | MainDetectionHelper 追加（箱化） | +103 |
| `lang/src/compiler/entry/compiler.hako` | Legacy Stage-A コメント追加 | +3 |
| `apps/tests/stage1_run_min.hako` | Modern syntax に統一 | -1 |
| `docs/development/selfhosting/quickstart.md` | サンプルコード 2箇所更新 | 2変更 |
| `CURRENT_TASK.md` | Phase 152-B 完了記録 | +7 |
### MainDetectionHelper 設計
**箱化モジュール化パターンの適用**:
```nyash
static box MainDetectionHelper {
findMainBody(src) // Entry point: delegates to pattern modules
tryLegacyPattern(src) // Module 1: "static method main" detection
tryModernPattern(src) // Module 2: "static box Main { main() }" detection
findPattern(src, pat, offset) // Helper: Pattern search
extractBodyFromPosition(src, pos) // Helper: Brace matching extraction
}
```
**モジュール責任分離**:
- `tryLegacyPattern`: Legacy "static method main" パターン専用
- `tryModernPattern`: Modern "static box Main { main() }" パターン専用
- `extractBodyFromPosition`: 共通のブレースマッチングロジック（再利用可能）
**利点**:
- ✅ 明確な責任分離（各パターン検出が独立モジュール）
- ✅ テスタビリティ（各メソッド個別テスト可能）
- ✅ 拡張性（新パターン追加時は新メソッド追加のみ）
- ✅ 後方互換性（Legacy パターン削除は tryLegacyPattern 削除のみ）
### テスト結果
**Stage-1/Stage-B パイプライン**: ✅ PASS
```bash
$ ./target/release/hakorune apps/tests/stage1_run_min.hako
RC: 0
```
**Selfhost depth-1**: ✅ PASS
```bash
$ NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_JOINIR_STRICT=1 \
./target/release/hakorune apps/tests/stage1_run_min.hako
RC: 0
```
**全スモークテスト**: ✅ 30/31 PASS
- 1 failure: unrelated timeout (strlen_fast_canary)
- 0 regressions from Phase 152-B changes
### 後方互換性検証
**Legacy パターンサポート**: ✅ 確認済み
- Stage-B ヘルパーで "static method main" と "method main" 両対応
- Modern パターンを優先、Legacy はフォールバック
**パーサ非汚染**: ✅ 達成
- 新構文追加なし（既存 `static box` パーサのみ）
- Stage-3 仕様クリーン性保持
---
## 進捗
- ✅ Phase 130-134: LLVM Python バックエンド整理
- ✅ Phase 150: Selfhost Stage-3 Depth-1 ベースライン強化
- ✅ Phase 151: ConsoleBox Selfhost Support
- ✅ Phase 152-A: 括弧付き代入式（Rust/Selfhost パーサ両対応）
- ✅ Phase 152-B: Static Method 宣言整理（箱化モジュール化完了）
- 📋 Phase 160+: .hako JoinIR/MIR 移植章（予定）
- 🌟 Phase 200+: Python → Hakorune トランスパイラ構想（夢）
Status: Historical

245
docs/archive/phases/phase-150-167/phase153_hako_check_deadcode.md Normal file
View File

@ -0,0 +1,245 @@
# Phase 153: hako_check / dead code 検出モードの復活（JoinIR 版）
## 0. ゴール
**hako_check を JoinIR 専用パイプラインの上で安定稼働させ、以前できていた「未使用関数・デッドコード検出」モードを、今の構造に合わせて復活・整備する。**
目的：
- selfhost / .hako 側のコンパイラコードに対して、hako_check で死んだ関数・到達しない分岐をすぐ見つけられる状態を作る
- Phase 160+ の .hako JoinIR/MIR 移植に入ったときの安全ネットを確立する
---
## 1. Scope / Non-scope
### ✅ やること
1. **hako_check の現状インベントリ**
- CLI スクリプト (`tools/hako_check.sh` / `tools/hako_check/*.hako`) と実行経路を確認
- 「何をチェックしているか」「以前動いていた dead code モードが今どうなっているか」を整理
2. **JoinIR 専用 hako_check パイプラインの再確認**
- Phase 121–124 の設計どおり、AST→JoinIR→MIR→解析が一つの線になっているかを確認・doc 固定
3. **dead code 検出モードの再実装／復活（箱化モジュール化）**
- 「未呼び出しの関数」「reachable ではない cfg ノード」などの検出を、今の JoinIR/MIR 情報から計算
- 結果を CLI から見やすい形（テキスト）で出力
- **DeadCodeAnalyzerBox** として箱化
4. **テストとスモーク**
- 小さい .hako フィクスチャで「明らかに死んでいる関数」が検出できることを確認
- 既存の hako_check テストが退行していないことを確認
### ❌ やらないこと
- JoinIR / MIR の意味論を変えない（解析は「読むだけ」）
- 新しい Stage‑3 構文を追加しない（Phase 152-A/B で決めた範囲のまま）
- 環境変数を増やさない（CLI フラグ `--dead-code` のみ。必要になったら後で追加）
---
## 2. Task 1: hako_check 現状インベントリ
### 対象ファイル
- `tools/hako_check.sh`
- `tools/hako_check/*.hako`（CLI エントリ・本体）
- `docs/development/` 内の hako_check 関連 doc：
- `hako_check_design.md`
- `phase121_*`
- `phase124_hako_check_joinir_finalization.md`
### やること
1. **hako_check の実行フローを再確認**
- CLI → .hako スクリプト → VM → MirBuilder / JoinIR → 解析、という線を図にする
2. **以前の dead code モードの存在を調査**
- 関数名に `dead` / `unused` / `reachability` 等が含まれる Box や関数を探す
- 設計 doc に「dead code モード」がどう書かれていたかを確認
3. **結果をドキュメントにまとめる**
- `docs/development/current/main/phase153_hako_check_inventory.md`（新規）に：
- エントリポイント
- 現在有効なチェック種類
- 死んでいる / 途中まで実装されていた dead code 検出の一覧
を書き出す
### 成果物
- `phase153_hako_check_inventory.md` 作成
---
## 3. Task 2: JoinIR 専用パイプラインの再確認と固定
### 目的
Phase 123–124 で「hako_check を JoinIR 専用にした」設計が、実際のコードでも守られているか確認
### やること
1. MirBuilder / JoinIR lowering で、hako_check 用の関数がどのルートを通っているかを確認
2. もしまだ legacy PHI / 旧 LoopBuilder にフォールバックしている箇所があれば：
- hako_check 経路だけでも確実に JoinIR 経由になるように修正する案を設計（実装は別フェーズでも可）
3. `hako_check_design.md` / `phase121_integration_roadmap.md` に：
- AST→JoinIR→MIR→hako_check の経路を最終形として追記
### 成果物
- パイプライン確認結果の記録（インベントリ doc に追記でも可）
---
## 4. Task 3: dead code 検出モードの設計（箱化モジュール化）
### 目的
hako_check 内で dead code 判定を行う「箱」を 1 個に閉じ込める
### 方針
- JoinIR/MIR の CFG/シンボル情報を読んで：
- 入口（エントリポイント関数）からの到達可能性を DFS/BFS
- 到達しなかった関数・ブロック・分岐を列挙
### 箱単位の設計
**DeadCodeAnalyzerBox** として：
- 入力: Program JSON v0 / MIR JSON / JoinIR JSON
- 出力: 「未使用関数名」「未到達ブロックID」のリスト
### やること
1. どのフォーマットを入力にするか決める
- 解析専用なら MIR JSON v0 / JoinIR JSON のどちらか
- 既存の hako_check 本体がどちらを見やすいかも考える
2. Dead code 箱の API を決める（.hako レベルの関数シグネチャ）
3. 出力フォーマット（CLI 表示）のラフ案：
```
unused function: Foo.bar/1
unreachable block: fn=Main.main bb=10 (if false branch)
```
### 成果物
- DeadCodeAnalyzerBox の設計（API シグネチャ）
- 入力フォーマット決定
---
## 5. Task 4: dead code 検出モードの実装と CLI 統合
### 実装
- hako_check 本体 .hako に **DeadCodeAnalyzerBox** を追加
- 入口の CLI から、`--dead-code` フラグで dead code モードを選べるようにする
### CLI 挙動
```bash
# 従来の基本チェック
hako_check target.hako
# dead code レポートを追加表示
hako_check --dead-code target.hako
```
### 環境変数について
- **Phase 153 では ENV 追加なし**（CLI フラグのみ）
- 将来「CI からフラグを渡しにくい」等のニーズが出たら、そのときに `NYASH_HAKO_CHECK_DEAD=1` を 1 個だけ足す
### 成果物
- DeadCodeAnalyzerBox の実装
- hako_check CLI に `--dead-code` フラグ追加
---
## 6. Task 5: テストとスモーク
### テスト用 .hako を 2〜3 本作る
1. **単純に未使用関数 1 個だけあるケース**
2. **入口から到達しない if/loop 分岐を含むケース**
3. **selfhost 関連の .hako から代表 1 本**（小さなコンパイラ部品）を選び、未使用関数が検出できるか見る
### スモークスクリプト
- `tools/hako_check_deadcode_smoke.sh`（など）を作成し：
- 上のテスト .hako をまとめて実行
- 期待する dead code 行が出ているかを軽く grep
### JoinIR 依存の確認
- 少なくとも代表 1 本は JoinIR lowering → MIR → hako_check まで通し、
Rust VM と hako_check の結果が論理的に矛盾していないことを確認
### 成果物
- テスト .hako 2〜3 本
- `tools/hako_check_deadcode_smoke.sh`
---
## 7. Task 6: ドキュメント / CURRENT_TASK 更新
### ドキュメント更新
1. **phase153_hako_check_inventory.md** に：
- どのモードがあり、今どこまで動くかを確定版として追記
2. **hako_check_design.md** を更新：
- 新しい dead code モードの説明と CLI/API を追加
3. **CURRENT_TASK.md**：
- Phase 153 セクションを追加し、以下を 2〜3 行で書く：
- 「hako_check が JoinIR 専用パイプラインで動き、dead code モードが復活した」
- 「これを .hako JoinIR/MIR 移植時の安全ネットとして使う」
### 成果物
- 各種ドキュメント更新
- git commit
---
## ✅ 完成チェックリスト（Phase 153）
- [ ] Task 1: hako_check 現状インベントリ完了
- [ ] phase153_hako_check_inventory.md 作成
- [ ] Task 2: JoinIR 専用パイプライン確認
- [ ] パイプライン図確定・記録
- [ ] Task 3: DeadCodeAnalyzerBox 設計
- [ ] API シグネチャ決定
- [ ] 入力フォーマット決定
- [ ] Task 4: 実装と CLI 統合
- [ ] DeadCodeAnalyzerBox 実装
- [ ] `--dead-code` フラグ追加
- [ ] Task 5: テストとスモーク
- [ ] テスト .hako 作成（2〜3 本）
- [ ] hako_check_deadcode_smoke.sh 作成
- [ ] Task 6: ドキュメント更新
- [ ] phase153_hako_check_inventory.md 確定版
- [ ] hako_check_design.md 更新
- [ ] CURRENT_TASK.md 更新
- [ ] git commit
---
## 次のステップ
Phase 153 完了後：
- **Phase 160+**: .hako JoinIR/MIR 移植章（hako_check が安全ネットとして機能）
- **Phase 200+**: Python → Hakorune トランスパイラ構想
---
**作成日**: 2025-12-04
**Phase**: 153（hako_check / dead code 検出モードの復活）
Status: Historical

544
docs/archive/phases/phase-150-167/phase153_hako_check_inventory.md Normal file
View File

@ -0,0 +1,544 @@
# Phase 153: hako_check Inventory (Dead Code Detection Mode)
**Created**: 2025-12-04
**Phase**: 153 (hako_check / dead code detection mode revival)
---
## Executive Summary
This document inventories the current state of `hako_check` as of Phase 153, with focus on:
1. Current execution flow and architecture
2. Existing dead code detection capabilities (HC011, HC012)
3. JoinIR integration status
4. Gaps and opportunities for Phase 153 enhancement
**Key Finding**: hako_check already has partial dead code detection through HC011 (dead methods) and HC012 (dead static boxes), but lacks:
- MIR-level unreachable block detection
- CFG-based reachability analysis
- Integration with JoinIR's control flow information
- Unified `--dead-code` flag for comprehensive dead code reporting
---
## 1. Current Architecture
### 1.1 Execution Flow
```
.hako source file
↓
tools/hako_check.sh (bash wrapper)
↓
tools/hako_check/cli.hako (VM-executed .hako script)
↓
HakoAnalysisBuilderBox.build_from_source_flags()
├─ HakoParserCoreBox.parse() (AST generation)
└─ Text-based scanning (fallback)
↓
Analysis IR (MapBox) with:
- methods: Array<String> (qualified: "Box.method/arity")
- calls: Array<Map{from, to}>
- boxes: Array<Map{name, is_static, methods}>
- entrypoints: Array<String>
- source: String (original text)
↓
Rule execution (19 rules, including HC011/HC012)
↓
Diagnostics output (text / JSON-LSP / DOT)
```
### 1.2 Key Components
**Entry Points**:
- `tools/hako_check.sh` - Shell script wrapper with environment setup
- `tools/hako_check/cli.hako` - Main .hako script (HakoAnalyzerBox)
**Core Boxes**:
- `HakoAnalyzerBox` (cli.hako) - Main orchestrator
- `HakoAnalysisBuilderBox` (analysis_consumer.hako) - IR builder
- `HakoParserCoreBox` (tools/hako_parser/parser_core.hako) - AST parser
**Dead Code Rules**:
- `RuleDeadMethodsBox` (rule_dead_methods.hako) - HC011
- `RuleDeadStaticBoxBox` (rule_dead_static_box.hako) - HC012
**IR Format** (MapBox):
```javascript
{
path: String,
source: String,
uses: Array<String>,
boxes: Array<{
name: String,
is_static: Boolean,
span_line: Integer,
methods: Array<{
name: String,
arity: Integer,
span: Integer
}>
}>,
methods: Array<String>, // "Box.method/arity"
calls: Array<{from: String, to: String}>,
entrypoints: Array<String>
}
```
---
## 2. Existing Dead Code Detection
### 2.1 HC011: Dead Methods (Unreachable Methods)
**File**: `tools/hako_check/rules/rule_dead_methods.hako`
**Algorithm**:
1. Build adjacency graph from `calls` array
2. DFS from entrypoints (Main.main, main, etc.)
3. Mark visited methods
4. Report unvisited methods as dead
**Limitations**:
- Only detects unreachable methods (function-level granularity)
- No unreachable block detection within functions
- Heuristic-based call detection (text scanning fallback)
- No integration with MIR CFG information
**Test Coverage**:
- `HC011_dead_methods/ng.hako` - Contains unreachable method
- `HC011_dead_methods/ok.hako` - All methods reachable
### 2.2 HC012: Dead Static Box (Unused Static Boxes)
**File**: `tools/hako_check/rules/rule_dead_static_box.hako`
**Algorithm**:
1. Collect all static box names from IR
2. Build set of referenced boxes from calls
3. Report boxes with no references (except Main)
**Limitations**:
- Only detects completely unreferenced boxes
- No detection of boxes with unreachable methods only
- AST span_line support for precise line reporting
**Test Coverage**:
- `HC012_dead_static_box/ng.hako` - Unused static box
- `HC012_dead_static_box/ok.hako` - All boxes referenced
### 2.3 HC016: Unused Alias
**File**: `tools/hako_check/rules/rule_unused_alias.hako`
**Note**: While not strictly "dead code", unused aliases are dead declarations.
---
## 3. JoinIR Integration Status
### 3.1 Current Pipeline (Phase 124 Completion)
**Status**: ✅ **JoinIR-only pipeline established**
As of Phase 124 (completed 2025-12-04), hako_check uses JoinIR exclusively:
```
.hako file
↓
Tokenize / Parse (Rust Parser)
↓
AST Generation
↓
MIR Builder (JoinIR lowering for if/loop)
├─ cf_if() → lower_if_form() (JoinIR-based PHI)
└─ cf_loop() → LoopBuilder (JoinIR-based PHI)
↓
MIR Generation (with JoinIR PHI)
↓
VM Interpreter
↓
hako_check Analysis
```
**Key Points**:
- `NYASH_HAKO_CHECK_JOINIR` flag removed (JoinIR is default)
- No legacy PHI fallback in hako_check path
- All If/Loop constructs use JoinIR lowering
### 3.2 MIR Integration Opportunities
**Current Gap**: hako_check does not consume MIR for dead code analysis
**Opportunity**: Integrate MIR CFG for block-level reachability:
- MIR already has `src/mir/passes/dce.rs` (instruction-level DCE)
- MIR has CFG information (`function.blocks`, `block.terminator`)
- JoinIR lowering provides high-quality PHI nodes for control flow
**Potential Input Formats**:
1. **MIR JSON v0** - Existing format from `--emit-mir-json`
2. **JoinIR JSON** - Direct JoinIR representation
3. **Analysis IR** - Current text-based IR (simplest, current approach)
---
## 4. Related Rust Code (Inventory)
### 4.1 MIR Dead Code Elimination
**File**: `src/mir/passes/dce.rs`
**Purpose**: Instruction-level dead code elimination (DCE)
**Scope**:
- Eliminates unused results of pure instructions
- Works at ValueId level (SSA values)
- Does **not** eliminate unreachable blocks or functions
**Relevance**: Could be extended or adapted for hako_check integration
### 4.2 MIR Verification
**File**: `src/mir/verification/cfg.rs`
**Purpose**: CFG consistency verification
**Relevance**: Contains CFG traversal utilities that could be reused for reachability analysis
### 4.3 MIR Optimizer
**File**: `src/mir/optimizer.rs`
**Purpose**: Multi-pass MIR optimization
**Relevance**: Orchestrates DCE and other passes; pattern for DeadCodeAnalyzerBox
---
## 5. Gaps and Phase 153 Scope
### 5.1 Existing Capabilities ✅
- [x] Dead method detection (HC011)
- [x] Dead static box detection (HC012)
- [x] JoinIR-only pipeline (Phase 124)
- [x] Text-based call graph analysis
- [x] Entrypoint-based DFS reachability
### 5.2 Missing Capabilities (Phase 153 Targets)
#### High Priority
- [ ] **Unreachable block detection** (within functions)
- Example: `if false { ... }` dead branches
- Example: Code after unconditional `return`
- [ ] **MIR CFG integration**
- Use MIR's block graph for precise reachability
- Detect unreachable blocks post-JoinIR lowering
- [ ] **Unified `--dead-code` flag**
- Aggregate HC011 + HC012 + new block detection
- Single command for comprehensive dead code audit
#### Medium Priority
- [ ] **JoinIR-specific analysis**
- Analyze IfMerge/LoopForm for unreachable paths
- Detect always-true/always-false conditions
- [ ] **CFG visualization integration**
- Extend DOT output with unreachable block highlighting
- `--format dot --dead-code` mode
#### Low Priority (Future Phases)
- [ ] Call graph visualization with dead paths
- [ ] Dataflow-based dead code detection
- [ ] Integration with Phase 160+ .hako JoinIR/MIR migration
---
## 6. Phase 153 Implementation Plan
### 6.1 Minimal Viable Product (MVP)
**Goal**: Revive dead code detection with MIR block-level reachability
**Scope**:
1. Create `DeadCodeAnalyzerBox` (.hako implementation)
2. Input: Analysis IR (current format) + optional MIR JSON
3. Output: Unreachable block reports
4. CLI: Add `--dead-code` flag to aggregate all dead code diagnostics
**Non-Goals** (Phase 153):
- No new environment variables
- No changes to JoinIR/MIR semantics
- No complex dataflow analysis (pure reachability only)
### 6.2 Box-Based Architecture (Phase 133/134 Pattern)
**Pattern**: Modular analyzer box following if_dry_runner.rs precedent
```
DeadCodeAnalyzerBox
├─ analyze_reachability(ir) → UnreachableBlocks
├─ analyze_call_graph(ir) → DeadFunctions
└─ aggregate_report() → Array<Diagnostic>
```
**Characteristics**:
- Self-contained .hako implementation
- No modification to existing rules (HC011/HC012 unchanged)
- Additive enhancement (no breaking changes)
### 6.3 Input Format Decision
**Recommendation**: Start with **Analysis IR** (current format)
**Rationale**:
- Minimally invasive (no new serialization)
- Works with existing hako_check pipeline
- Can extend to MIR JSON in Phase 154+ if needed
**Analysis IR Extensions** (if needed):
```javascript
{
// ... existing fields ...
blocks: Array<{
id: Integer,
function: String,
reachable: Boolean,
terminator: String
}>
}
```
---
## 7. Test Inventory
### 7.1 Existing Dead Code Tests
**HC011 Tests** (Dead Methods):
- `tools/hako_check/tests/HC011_dead_methods/`
- `ng.hako` - Method never called
- `ok.hako` - All methods reachable
- `expected.json` - Diagnostic expectations
**HC012 Tests** (Dead Static Box):
- `tools/hako_check/tests/HC012_dead_static_box/`
- `ng.hako` - Box never instantiated
- `ok.hako` - All boxes used
- `expected.json` - Diagnostic expectations
### 7.2 Planned Phase 153 Tests
**HC011-B** (Unreachable Block):
```hako
static box Test {
method demo() {
if false {
// This block is unreachable
print("dead code")
}
return 0
}
}
```
**HC011-C** (Code After Return):
```hako
static box Test {
method demo() {
return 0
print("unreachable") // Dead code
}
}
```
**Integration Test** (Comprehensive):
- Combines dead methods, dead boxes, and dead blocks
- Verifies `--dead-code` flag aggregates all findings
---
## 8. CLI Design (Phase 153)
### 8.1 Current CLI
```bash
# Basic analysis
./tools/hako_check.sh target.hako
# Rule filtering
./tools/hako_check.sh --rules dead_methods,dead_static_box target.hako
# JSON-LSP output
./tools/hako_check.sh --format json-lsp target.hako
```
### 8.2 Proposed Phase 153 CLI
```bash
# Enable comprehensive dead code detection
./tools/hako_check.sh --dead-code target.hako
# Dead code only (skip other rules)
./tools/hako_check.sh --rules dead_code target.hako
# Combine with visualization
./tools/hako_check.sh --dead-code --format dot target.hako > cfg.dot
```
**Behavior**:
- `--dead-code`: Enables HC011 + HC012 + new block analysis
- Exit code: Number of dead code findings (0 = clean)
- Compatible with existing `--format` options
---
## 9. Environment Variables (No New Additions)
**Phase 153 Constraint**: No new environment variables
**Existing Variables** (hako_check uses):
- `NYASH_DISABLE_PLUGINS=1` - Required for stability
- `NYASH_BOX_FACTORY_POLICY=builtin_first` - Box resolution
- `NYASH_FEATURES=stage3` - Parser stage
- `NYASH_JSON_ONLY=1` - Pure JSON output (json-lsp mode)
**Decision**: All Phase 153 control via CLI flags only
---
## 10. JoinIR Design Principles Compliance
### 10.1 Read-Only Analysis
✅ **Compliant**: DeadCodeAnalyzerBox only reads IR, does not modify it
### 10.2 No Semantic Changes
✅ **Compliant**: Analysis is post-compilation, no effect on MIR generation
### 10.3 Box-First Modularity
✅ **Compliant**: DeadCodeAnalyzerBox follows established pattern
### 10.4 Fail-Fast (Not Applicable)
N/A: Analysis cannot fail (always produces some result, possibly empty)
---
## 11. Integration with Phase 160+
**Context**: Phase 160+ will migrate .hako sources to JoinIR/MIR
**hako_check Role**: Safety net for migration
**Benefits**:
- Detect dead code introduced during migration
- Verify call graph integrity
- Catch unreachable blocks from refactoring
**Preparation** (Phase 153):
- Establish solid baseline for dead code detection
- Prove DeadCodeAnalyzerBox on current codebase
- Document false positive patterns
---
## 12. Known Limitations (Phase 153)
### 12.1 Dynamic Call Detection
**Limitation**: Text-based call scanning cannot detect dynamic calls
**Example**:
```hako
local method_name = "compute"
// Call via reflection (not detectable by hako_check)
```
**Mitigation**: Document as known limitation
### 12.2 False Positives
**Pattern**: Intentionally unused utility methods
**Example**:
```hako
static box Utils {
// Future use, not yet called
method reserved_for_later() { }
}
```
**Mitigation**: Allow suppression comments (future phase)
### 12.3 Cross-Module Analysis
**Limitation**: hako_check analyzes single files only
**Consequence**: Cannot detect dead code exported but unused elsewhere
**Mitigation**: Document as boundary condition
---
## 13. Success Criteria (Phase 153)
### 13.1 Functional Requirements
- [ ] DeadCodeAnalyzerBox implemented in .hako
- [ ] `--dead-code` flag functional
- [ ] HC011 + HC012 + block detection working
- [ ] 2-3 test cases passing
- [ ] Smoke script created
### 13.2 Quality Requirements
- [ ] No regression in existing hako_check tests
- [ ] Box-based modular architecture
- [ ] Documentation updated (this file + hako_check_design.md)
- [ ] Git commit with clear message
### 13.3 Non-Functional Requirements
- [ ] Performance: <5% overhead on existing hako_check
- [ ] Compatibility: Works with all existing CLI options
- [ ] Maintainability: <200 lines for DeadCodeAnalyzerBox
---
## 14. Next Steps (Post-Inventory)
1. **Task 2**: Verify JoinIR-only pipeline (confirm no legacy fallback)
2. **Task 3**: Design DeadCodeAnalyzerBox API and format
3. **Task 4**: Implement DeadCodeAnalyzerBox
4. **Task 5**: Create test cases and smoke script
5. **Task 6**: Update documentation and commit
---
## 15. References
**Related Documents**:
- `phase153_hako_check_deadcode.md` - Phase 153 specification
- `hako_check_design.md` - Current hako_check architecture
- `phase121_integration_roadmap.md` - JoinIR integration history
- `phase124_hako_check_joinir_finalization.md` - JoinIR-only completion
**Related Code**:
- `tools/hako_check/` - Current implementation
- `src/mir/passes/dce.rs` - Rust DCE reference
- `src/mir/verification/cfg.rs` - CFG verification utilities
**Test Fixtures**:
- `tools/hako_check/tests/HC011_dead_methods/`
- `tools/hako_check/tests/HC012_dead_static_box/`
---
**Status**: Inventory Complete ✅
**Next**: Task 2 (JoinIR Pipeline Verification)
Status: Historical

389
docs/archive/phases/phase-150-167/phase154_feedback.md Normal file
View File

@ -0,0 +1,389 @@
# Phase 154: Feedback & Recommendations
## Implementation Feedback
### What Went Well ✅
1. **Clear Architecture from the Start**
- The MIR already had CFG information (predecessors, successors, reachability)
- Following Phase 153's boxed pattern made DeadBlockAnalyzerBox straightforward
- Separation of concerns: CFG extraction (Rust) vs. analysis (.hako)
2. **Comprehensive Documentation**
- Phase 150 results provided excellent test cases to reference
- Inventory document clarified the data flow early
- Implementation summary will help Phase 155 engineer
3. **Test-Driven Design**
- Created test cases before implementation
- 4 patterns cover common unreachable code scenarios
- Smoke script validates infrastructure even without data bridge
4. **Graceful Degradation**
- DeadBlockAnalyzerBox skips gracefully if CFG unavailable
- Smoke test doesn't fail during MVP phase
- Non-breaking changes to existing hako_check flow
### Challenges Encountered ⚠️
1. **Data Bridge Gap**
- **Issue:** analysis_consumer.hako builds IR from text scanning, not MIR
- **Impact:** CFG extractor implemented but not yet usable
- **Resolution:** Documented as Phase 155 task (2-3 hour estimate)
2. **Module System Complexity**
- Initial confusion about where to add `cfg_extractor` module
- Resolved by examining existing join_ir module pattern
- **Lesson:** Always check `mod.rs` structure first
3. **Testing Without Data**
- Hard to validate DeadBlockAnalyzerBox without actual CFG
- Created mock-aware smoke test as workaround
- **Lesson:** Unit tests in Rust covered CFG extraction logic
## Recommendations for Future Phases
### Immediate (Phase 155) 🔥
**Priority 1: Complete CFG Data Bridge**
Add builtin function to extract CFG from compiled MIR:
```rust
// In src/boxes/compiler_box.rs or similar
fn extract_mir_cfg(text: &str, path: &str) -> Result<serde_json::Value, String> {
// 1. Compile text to MIR
let ast = parse_source(text)?;
let module = MirCompiler::new().compile(&ast)?;
// 2. Extract CFG
let cfg = extract_cfg_info(&module);
Ok(cfg)
}
```
Then update `analysis_consumer.hako`:
```hako
build_from_source_flags(text, path, no_ast) {
local ir = new MapBox()
// ... existing text scanning ...
// NEW: Add CFG if available
local cfg = extract_mir_cfg(text, path) // Rust builtin
if cfg != null {
ir.set("cfg", cfg)
}
return ir
}
```
**Estimated Time:** 2-3 hours
**Complexity:** Low (mostly plumbing)
### Short-term (Phase 156-158) 📋
**Enhancement 1: Source Location Mapping**
- Track span information in CFG extractor
- Show line numbers in HC020 output
- Example: `[HC020] ... :: test.hako:15`
**Enhancement 2: Better Reason Inference**
- Analyze surrounding context (not just terminator type)
- Distinguish between different Branch patterns
- Example: "constant false condition" vs "always true guard"
**Enhancement 3: Integration Testing**
- Add hako_check tests to main test suite
- Verify HC020 doesn't trigger false positives
- Test with large real-world .hako files
### Medium-term (Phase 160-165) 🚀
**Feature 1: Constant Propagation**
```hako
local x = 0
if x > 0 { // Can be proven false at compile time
// Should trigger HC020
}
```
Currently: May not detect (depends on MIR optimizer)
Future: Always detect via symbolic execution
**Feature 2: Path-Sensitive Analysis**
```hako
if condition {
if not condition { // Contradiction!
// Should trigger HC020
}
}
```
**Feature 3: CFG Visualization**
```bash
# Generate DOT graph with dead blocks highlighted
./tools/hako_check.sh --format dot --dead-blocks program.hako > cfg.dot
dot -Tpng cfg.dot -o cfg.png
```
Red nodes = unreachable blocks
Gray edges = never taken
### Long-term (Phase 200+) 🌟
**Feature 4: Interactive Reports**
- HTML output with clickable CFG
- Hover over blocks to see code
- Click to jump to source location
**Feature 5: Fix Suggestions**
```
[HC020] Unreachable basic block: fn=Main.test bb=5 (after early return)
Suggestion: Remove unreachable code at lines 15-20, or move before return at line 12
```
## Design Improvements for Similar Tasks
### 1. Early Data Flow Validation
**What to do differently:**
- Before implementing analyzer, verify data availability
- Create end-to-end mockup with hardcoded data
- Test analysis logic before building pipeline
**Why it helps:**
- Catches integration gaps early
- Validates assumptions about data format
- Allows parallel development (data bridge + analysis)
### 2. Incremental Testing
**What to do differently:**
- Test CFG extractor → Test DeadBlockAnalyzerBox → Test CLI integration
- Each step independently validated
- Mock data for middle layers
**Why it helps:**
- Pinpoints failures faster
- Easier to debug
- More confidence at each stage
### 3. Documentation-First Approach
**What worked well:**
- Writing inventory doc forced careful investigation
- Implementation summary guided development
- Feedback doc captures lessons learned
**Apply to future phases:**
- Always start with design doc
- Document decisions and alternatives
- Create feedback doc after completion
## Specific Code Improvements
### CFG Extractor
**Current:**
```rust
fn terminator_to_string(inst: &MirInstruction) -> String {
match inst {
MirInstruction::Branch { .. } => "Branch".to_string(),
MirInstruction::Jump { .. } => "Jump".to_string(),
MirInstruction::Return { .. } => "Return".to_string(),
_ => "Unknown".to_string(),
}
}
```
**Future Enhancement:**
```rust
fn terminator_to_string(inst: &MirInstruction) -> String {
match inst {
MirInstruction::Branch { condition, .. } => {
// Check if condition is constant
if is_constant_value(condition) {
"ConstantBranch".to_string()
} else {
"Branch".to_string()
}
}
// ... rest ...
}
}
```
Benefit: Enables better reason inference in DeadBlockAnalyzerBox
### DeadBlockAnalyzerBox
**Current:**
```hako
_infer_unreachable_reason(terminator) {
if terminator == "Return" { return "after early return" }
if terminator == "Jump" { return "unreachable branch" }
// ...
}
```
**Future Enhancement:**
```hako
_infer_unreachable_reason(block, cfg) {
// Look at parent block's terminator
local parent_id = me._find_parent_block(block, cfg)
local parent = me._get_block_by_id(cfg, parent_id)
if parent.terminator == "ConstantBranch" {
return "constant false condition"
}
// ... more sophisticated analysis ...
}
```
Benefit: More actionable error messages
## Testing Recommendations
### Unit Test Coverage
**Add tests for:**
- CFG extraction with complex control flow (nested loops, try-catch)
- DeadBlockAnalyzerBox edge cases (empty functions, single-block functions)
- Terminator inference logic
**Test file:**
```rust
// src/mir/cfg_extractor.rs
#[test]
fn test_nested_loop_cfg() { /* ... */ }
#[test]
fn test_try_catch_cfg() { /* ... */ }
```
### Integration Test Patterns
**Once bridge is complete:**
1. **Positive Tests** (should detect HC020)
- Early return in nested if
- Break in loop with subsequent code
- Panic/throw with subsequent code
2. **Negative Tests** (should NOT detect HC020)
- Conditional return (not always taken)
- Loop with conditional break
- Reachable code after if-else
3. **Edge Cases**
- Empty functions
- Functions with only one block
- Functions with dead blocks but live code
## Process Improvements
### 1. Parallel Development Strategy
**For Phase 155:**
- One person implements data bridge (Rust-side)
- Another prepares integration tests (.hako-side)
- Meet in middle with agreed JSON format
### 2. Smoke Test Evolution
**Current:** Lenient (allows CFG unavailability)
**Phase 155:** Strict (requires CFG, expects HC020)
**Phase 160:** Comprehensive (multiple files, performance tests)
Update smoke script as pipeline matures.
### 3. Documentation Maintenance
**Add to each phase:**
- Before: Design doc with alternatives
- During: Progress log with blockers
- After: Feedback doc with lessons
**Benefit:** Knowledge transfer, future reference, debugging aid
## Questions for Discussion
### Q1: CFG Bridge Location
**Options:**
1. New builtin function: `extract_mir_cfg(text, path)`
2. Extend existing parser: `HakoParserCoreBox.parse_with_cfg(text)`
3. Separate tool: `hakorune --extract-cfg program.hako`
**Recommendation:** Option 1 (cleaner separation)
### Q2: Performance Optimization
**Question:** Should we cache CFG extraction?
**Analysis:**
- MIR compilation is expensive (~50-100ms per file)
- CFG extraction is cheap (~1ms)
- But hako_check runs once, so caching not useful
**Recommendation:** No caching for now, revisit in CI/CD context
### Q3: Error Handling
**Question:** What if MIR compilation fails?
**Options:**
1. Skip HC020 silently
2. Show warning "CFG unavailable due to compile error"
3. Fail entire hako_check run
**Recommendation:** Option 2 (user-friendly, informative)
## Success Metrics (Phase 155)
### Definition of Done
- [ ] CFG data bridge implemented and tested
- [ ] All 4 test cases produce HC020 output
- [ ] Smoke test passes without warnings
- [ ] No false positives on large .hako files
- [ ] Documentation updated (bridge complete)
### Performance Targets
- CFG extraction: <5ms per function
- HC020 analysis: <10ms per file
- Total overhead: <5% of hako_check runtime
### Quality Gates
- Zero false positives on test suite
- HC020 output includes function and block ID
- Error messages are actionable
- No crashes on malformed input
## Conclusion
Phase 154 **successfully delivered the infrastructure** for block-level dead code detection. The core components are complete, tested, and documented.
**Key Success Factors:**
- Clear architecture from Phase 153 pattern
- Thorough investigation before implementation
- Graceful degradation during MVP
- Comprehensive documentation for handoff
**Next Phase (155) is Straightforward:**
- 2-3 hours of Rust-side plumbing
- Well-defined task with clear deliverables
- High confidence in success
**Recommendation:** Proceed with Phase 155 implementation immediately. The foundation is solid, and the remaining work is mechanical.
---
**Feedback Author:** Claude (Anthropic)
**Date:** 2025-12-04
**Phase:** 154 (Complete)
**Next Phase:** 155 (CFG Data Bridge)
Status: Historical

369
docs/archive/phases/phase-150-167/phase154_implementation_summary.md Normal file
View File

@ -0,0 +1,369 @@
# Phase 154: Implementation Summary - MIR CFG Integration & Dead Block Detection
## Overview
Successfully implemented **HC020 Unreachable Basic Block Detection** rule using MIR CFG information. This provides block-level dead code analysis complementing the existing method-level HC019 rule from Phase 153.
**Status:** Core infrastructure complete, CFG data bridge pending (see Known Limitations)
---
## Completed Deliverables
### 1. CFG Extractor (`src/mir/cfg_extractor.rs`)
**Purpose:** Extract CFG information from MIR modules for analysis tools.
**Features:**
- Extracts block-level reachability information
- Exports successor relationships
- Identifies terminator types (Branch/Jump/Return)
- Deterministic output (sorted by block ID)
**API:**
```rust
pub fn extract_cfg_info(module: &MirModule) -> serde_json::Value
```
**Output Format:**
```json
{
"functions": [
{
"name": "Main.main/0",
"entry_block": 0,
"blocks": [
{
"id": 0,
"reachable": true,
"successors": [1, 2],
"terminator": "Branch"
}
]
}
]
}
```
**Testing:** Includes unit tests for simple CFG and unreachable blocks.
### 2. DeadBlockAnalyzerBox (`tools/hako_check/rules/rule_dead_blocks.hako`)
**Purpose:** HC020 rule implementation for unreachable basic block detection.
**Features:**
- Scans CFG information from Analysis IR
- Reports unreachable blocks with function and block ID
- Infers reasons for unreachability (early return, dead branch, etc.)
- Gracefully skips if CFG info unavailable
**API:**
```hako
static box DeadBlockAnalyzerBox {
method apply_ir(ir, path, out) {
// Analyze CFG and report HC020 diagnostics
}
}
```
**Output Format:**
```
[HC020] Unreachable basic block: fn=Main.test bb=5 (after early return) :: test.hako
```
### 3. CLI Integration (`tools/hako_check/cli.hako`)
**New Flag:** `--dead-blocks`
**Usage:**
```bash
# Run HC020 dead block detection
./tools/hako_check.sh --dead-blocks program.hako
# Combined with other modes
./tools/hako_check.sh --dead-code --dead-blocks program.hako
# Or use rules filter
./tools/hako_check.sh --rules dead_blocks program.hako
```
**Integration Points:**
- Added `DeadBlockAnalyzerBox` import
- Added `--dead-blocks` flag parsing
- Added HC020 rule execution after HC019
- Added debug logging for HC020
### 4. Test Cases
Created 4 comprehensive test cases:
1. **`test_dead_blocks_early_return.hako`**
- Pattern: Early return creates unreachable code
- Expected: HC020 for block after return
2. **`test_dead_blocks_always_false.hako`**
- Pattern: Constant false condition (`if 0`)
- Expected: HC020 for dead then-branch
3. **`test_dead_blocks_infinite_loop.hako`**
- Pattern: `loop(1)` never exits
- Expected: HC020 for code after loop
4. **`test_dead_blocks_after_break.hako`**
- Pattern: Unconditional break in loop
- Expected: HC020 for code after break
### 5. Smoke Test Script
**File:** `tools/hako_check_deadblocks_smoke.sh`
**Features:**
- Tests all 4 test cases
- Checks for HC020 output
- Gracefully handles CFG info unavailability (MVP limitation)
- Non-failing for incomplete CFG integration
---
## Known Limitations & Next Steps
### Current State: Core Infrastructure Complete ✅
**What Works:**
- ✅ CFG extractor implemented and tested
- ✅ DeadBlockAnalyzerBox implemented
- ✅ CLI integration complete
- ✅ Test cases created
- ✅ Smoke test script ready
### Outstanding: CFG Data Bridge 🔄
**The Gap:**
Currently, `analysis_consumer.hako` builds Analysis IR by text scanning, not from MIR. The CFG information exists in Rust's `MirModule` but isn't exposed to the .hako side yet.
**Solution Path (Phase 155+):**
#### Option A: Extend analysis_consumer with MIR access (Recommended)
```hako
// In analysis_consumer.hako
static box HakoAnalysisBuilderBox {
build_from_source_flags(text, path, no_ast) {
local ir = new MapBox()
// ... existing text scanning ...
// NEW: Request CFG from MIR if available
local cfg = me._extract_cfg_from_mir(text, path)
if cfg != null {
ir.set("cfg", cfg)
}
return ir
}
_extract_cfg_from_mir(text, path) {
// Call Rust function that:
// 1. Compiles text to MIR
// 2. Calls extract_cfg_info()
// 3. Returns JSON value
}
}
```
#### Option B: Add MIR compilation step to hako_check pipeline
```bash
# In tools/hako_check.sh
# 1. Compile to MIR JSON
hakorune --emit-mir-json /tmp/mir.json program.hako
# 2. Extract CFG
hakorune --extract-cfg /tmp/mir.json > /tmp/cfg.json
# 3. Pass to analyzer
hakorune --backend vm tools/hako_check/cli.hako \
--source-file program.hako "$(cat program.hako)" \
--cfg-file /tmp/cfg.json
```
**Recommended:** Option A (cleaner integration, single pass)
### Implementation Roadmap (Phase 155)
1. **Add Rust-side function** to compile .hako to MIR and extract CFG
2. **Expose to VM** as builtin function (e.g., `extract_mir_cfg(text, path)`)
3. **Update analysis_consumer.hako** to call this function
4. **Test end-to-end** with all 4 test cases
5. **Update smoke script** to expect HC020 output
**Estimated Effort:** 2-3 hours (mostly Rust-side plumbing)
---
## Architecture Decisions
### Why Not Merge HC019 and HC020?
**Decision:** Keep HC019 (method-level) and HC020 (block-level) separate
**Rationale:**
1. **Different granularity**: Methods vs. blocks are different analysis levels
2. **Different use cases**: HC019 finds unused code, HC020 finds unreachable paths
3. **Optional CFG**: HC019 works without MIR, HC020 requires CFG
4. **User control**: `--dead-code` vs `--dead-blocks` allows selective analysis
### CFG Info Location in Analysis IR
**Decision:** Add `cfg` as top-level field in Analysis IR
**Alternatives considered:**
- Embed in `methods` array → Breaks existing format
- Separate IR structure → More complex
**Chosen:**
```javascript
{
"methods": [...], // Existing
"calls": [...], // Existing
"cfg": { // NEW
"functions": [...]
}
}
```
**Benefits:**
- Backward compatible (optional field)
- Extensible (can add more CFG data later)
- Clean separation of concerns
### Reachability: MIR vs. Custom Analysis
**Decision:** Use MIR's built-in `block.reachable` flag
**Rationale:**
- Already computed during MIR construction
- Proven correct (used by optimizer)
- No duplication of logic
- Consistent with Rust compiler design
**Alternative (rejected):** Re-compute reachability in DeadBlockAnalyzerBox
- Pro: Self-contained
- Con: Duplication, potential bugs, slower
---
## Testing Strategy
### Unit Tests
- ✅ `cfg_extractor::tests::test_extract_simple_cfg`
- ✅ `cfg_extractor::tests::test_unreachable_block`
### Integration Tests
- 🔄 Pending CFG bridge (Phase 155)
- Test cases ready in `apps/tests/hako_check/`
### Smoke Tests
- ✅ `tools/hako_check_deadblocks_smoke.sh`
- Currently validates infrastructure, will validate HC020 output once bridge is complete
---
## Performance Considerations
### CFG Extraction Cost
- **Negligible**: Already computed during MIR construction
- **One-time**: Extracted once per function
- **Small output**: ~100 bytes per function typically
### DeadBlockAnalyzerBox Cost
- **O(blocks)**: Linear scan of blocks array
- **Typical**: <100 blocks per function
- **Fast**: Simple boolean check and string formatting
**Conclusion:** No performance concerns, suitable for CI/CD pipelines.
---
## Future Enhancements (Phase 160+)
### Enhanced Diagnostics
- Show source code location of unreachable blocks
- Suggest how to fix (remove code, change condition, etc.)
- Group related unreachable blocks
### Deeper Analysis
- Constant propagation to find more dead branches
- Path sensitivity (combine conditions across blocks)
- Integration with type inference
### Visualization
- DOT graph output showing dead blocks in red
- Interactive HTML report with clickable blocks
- Side-by-side source and CFG view
---
## Files Modified/Created
### New Files
- ✅ `src/mir/cfg_extractor.rs` (184 lines)
- ✅ `tools/hako_check/rules/rule_dead_blocks.hako` (100 lines)
- ✅ `apps/tests/hako_check/test_dead_blocks_*.hako` (4 files, ~20 lines each)
- ✅ `tools/hako_check_deadblocks_smoke.sh` (65 lines)
- ✅ `docs/development/current/main/phase154_mir_cfg_inventory.md`
- ✅ `docs/development/current/main/phase154_implementation_summary.md`
### Modified Files
- ✅ `src/mir/mod.rs` (added cfg_extractor module and re-export)
- ✅ `tools/hako_check/cli.hako` (added --dead-blocks flag and HC020 rule execution)
**Total Lines:** ~450 lines (code + docs + tests)
---
## Recommendations for Next Phase
### Immediate (Phase 155)
1. **Implement CFG data bridge** (highest priority)
- Add `extract_mir_cfg()` builtin function
- Update `analysis_consumer.hako` to use it
- Test end-to-end with all 4 test cases
2. **Update documentation**
- Mark CFG bridge as complete
- Add usage examples to hako_check README
- Update CURRENT_TASK.md
### Short-term (Phase 156-160)
3. **Add source location mapping**
- Track span information for unreachable blocks
- Show line numbers in HC020 output
4. **Enhance test coverage**
- Add tests for complex control flow (nested loops, try-catch, etc.)
- Add negative tests (no false positives)
### Long-term (Phase 160+)
5. **Constant folding integration**
- Detect more dead branches via constant propagation
- Integrate with MIR optimizer
6. **Visualization tools**
- DOT/GraphViz output for CFG
- HTML reports with interactive CFG
---
## Conclusion
Phase 154 successfully establishes the **infrastructure for block-level dead code detection**. The core components (CFG extractor, analyzer box, CLI integration, tests) are complete and tested.
The remaining work is a **straightforward data bridge** to connect the Rust-side MIR CFG to the .hako-side Analysis IR. This is a mechanical task estimated at 2-3 hours for Phase 155.
**Key Achievement:** Demonstrates the power of the **boxed modular architecture** - DeadBlockAnalyzerBox is completely independent and swappable, just like DeadCodeAnalyzerBox from Phase 153.
---
**Author:** Claude (Anthropic)
**Date:** 2025-12-04
**Phase:** 154 (MIR CFG Integration & Dead Block Detection)
**Status:** Core infrastructure complete, CFG bridge pending (Phase 155)
Status: Historical

389
docs/archive/phases/phase-150-167/phase154_mir_cfg_deadblocks.md Normal file
View File

@ -0,0 +1,389 @@
# Phase 154: MIR CFG 統合 & ブロックレベル unreachable 検出
## 0. ゴール
**hako_check に MIR CFG 情報を取り込み、「到達不能な basic block」を検出する HC020 ルールを追加する。**
目的：
- Phase 153 で復活した dead code 検出（メソッド・Box 単位）を、ブロック単位まで細粒度化
- JoinIR/MIR の CFG 情報を hako_check の Analysis IR に統合
- 「unreachable basic block」を検出し、コード品質向上に寄与
---
## 1. Scope / Non-scope
### ✅ やること
1. **MIR/CFG 情報のインベントリ**
- 現在の MIR JSON v0 に含まれる CFG 情報（blocks, terminators）を確認
- hako_check の Analysis IR に追加すべきフィールドを特定
2. **DeadBlockAnalyzerBox の設計（箱化モジュール化）**
- Phase 153 の DeadCodeAnalyzerBox パターンを踏襲
- 入力: Analysis IR（CFG 情報付き）
- 出力: 未到達ブロックのリスト
3. **hako_check パイプラインへの統合設計**
- Analysis IR 生成時に CFG 情報を含める方法を決定
- HC020 ルールの位置付け（HC019 の後に実行）
4. **テストケース設計（ブロックレベル）**
- 到達不能な if/else 分岐
- 早期 return 後のコード
- 常に false のループ条件
5. **実装 & テスト**
- DeadBlockAnalyzerBox 実装
- HC020 ルール実装
- スモークテスト作成
6. **ドキュメント & CURRENT_TASK 更新**
### ❌ やらないこと
- JoinIR/MIR の意味論を変えない（解析は「読むだけ」）
- 新しい Stage-3 構文を追加しない
- 環境変数を増やさない（CLI フラグ `--dead-blocks` のみ）
---
## 2. Task 1: MIR/CFG 情報のインベントリ
### 対象ファイル
- `src/mir/join_ir/json.rs` - JoinIR JSON シリアライズ
- `src/mir/join_ir_runner.rs` - JoinIR 実行
- `src/mir/` - MIR 構造定義
- `tools/hako_check/analysis_ir.hako` - 現在の Analysis IR 定義
### やること
1. **MIR JSON v0 の CFG 情報を確認**
- blocks 配列の構造
- terminator の種類（Jump, Branch, Return）
- predecessors / successors の有無
2. **Analysis IR に追加すべきフィールドを特定**
- `blocks: Array<BlockInfo>` ?
- `cfg_edges: Array<Edge>` ?
- `entry_block: BlockId` ?
3. **JoinIR Strict モードでの動作確認**
- `NYASH_JOINIR_STRICT=1` で MIR が正しく生成されているか
- Phase 150 の代表ケースで CFG 情報が取れるか
### 成果物
- CFG 情報インベントリ結果の記録
---
## 3. Task 2: DeadBlockAnalyzerBox の設計（箱化モジュール化）
### 目的
Phase 153 の DeadCodeAnalyzerBox パターンを踏襲し、ブロックレベル解析を箱化
### 方針
- エントリブロックからの到達可能性を DFS/BFS で計算
- 到達しなかったブロックを列挙
- 各ブロックがどの関数に属するかも記録
### 箱単位の設計
**DeadBlockAnalyzerBox** として：
- 入力: Analysis IR（CFG 情報付き）
- 出力: 「未到達ブロック」のリスト
### API シグネチャ案
```hako
static box DeadBlockAnalyzerBox {
method apply_ir(ir, path, out) {
// CFG 情報を取得
local blocks = ir.get("blocks")
local edges = ir.get("cfg_edges")
local entry = ir.get("entry_block")
// 到達可能性解析
local reachable = me._compute_reachability(entry, edges)
// 未到達ブロックを検出
me._report_unreachable_blocks(blocks, reachable, path, out)
}
method _compute_reachability(entry, edges) {
// DFS/BFS で到達可能なブロックを収集
// return: Set<BlockId>
}
method _report_unreachable_blocks(blocks, reachable, path, out) {
// 到達不能なブロックを HC020 として報告
}
}
```
### 出力フォーマット
```
[HC020] Unreachable basic block: fn=Main.main bb=10 (after early return)
[HC020] Unreachable basic block: fn=Foo.bar bb=15 (if false branch never taken)
```
### 成果物
- DeadBlockAnalyzerBox の設計（API シグネチャ）
- Analysis IR 拡張フィールド決定
---
## 4. Task 3: hako_check パイプラインへの統合設計
### 目的
HC020 ルールを既存の hako_check パイプラインに統合
### やること
1. **Analysis IR 生成の拡張**
- `tools/hako_check/analysis_ir.hako` を拡張
- CFG 情報（blocks, edges, entry_block）を含める
2. **CLI フラグ追加**
- `--dead-blocks` フラグで HC020 を有効化
- または `--dead-code` に統合（ブロックレベルも含む）
3. **ルール実行順序**
- HC019（dead code）の後に HC020（dead blocks）を実行
- または `--rules dead_blocks` で個別指定可能に
### 設計方針
**Option A**: `--dead-code` に統合
```bash
# HC019 + HC020 を両方実行
./tools/hako_check.sh --dead-code target.hako
```
**Option B**: 別フラグ
```bash
# HC019 のみ
./tools/hako_check.sh --dead-code target.hako
# HC020 のみ
./tools/hako_check.sh --dead-blocks target.hako
# 両方
./tools/hako_check.sh --dead-code --dead-blocks target.hako
```
**推奨**: Option A（ユーザーは「dead code」を広義に捉えるため）
### 成果物
- パイプライン統合設計
- CLI フラグ仕様確定
---
## 5. Task 4: テストケース設計（ブロックレベル）
### テストケース一覧
#### Case 1: 早期 return 後のコード
```hako
static box TestEarlyReturn {
test(x) {
if x > 0 {
return 1
}
// ここに到達不能コード
local unreachable = 42 // HC020 検出対象
return unreachable
}
}
```
#### Case 2: 常に false の条件
```hako
static box TestAlwaysFalse {
test() {
if false {
// このブロック全体が到達不能
return 999 // HC020 検出対象
}
return 0
}
}
```
#### Case 3: 無限ループ後のコード
```hako
static box TestInfiniteLoop {
test() {
loop(true) {
// 無限ループ
}
// ここに到達不能
return 0 // HC020 検出対象
}
}
```
#### Case 4: break 後のコード（ループ内）
```hako
static box TestAfterBreak {
test() {
loop(true) {
break
// break 後のコード
local x = 1 // HC020 検出対象
}
return 0
}
}
```
### 成果物
- テスト .hako ファイル 4 本
- 期待される HC020 出力の定義
---
## 6. Task 5: 実装 & テスト
### 実装ファイル
1. **`tools/hako_check/rules/rule_dead_blocks.hako`** - 新規作成
- DeadBlockAnalyzerBox 実装
- HC020 ルール実装
2. **`tools/hako_check/analysis_ir.hako`** - 拡張
- CFG 情報フィールド追加
3. **`tools/hako_check/cli.hako`** - 修正
- `--dead-blocks` または `--dead-code` 拡張
- HC020 実行統合
### テストファイル
1. **`apps/tests/hako_check/test_dead_blocks_early_return.hako`**
2. **`apps/tests/hako_check/test_dead_blocks_always_false.hako`**
3. **`apps/tests/hako_check/test_dead_blocks_infinite_loop.hako`**
4. **`apps/tests/hako_check/test_dead_blocks_after_break.hako`**
### スモークスクリプト
- `tools/hako_check_deadblocks_smoke.sh` - HC020 スモークテスト
### 成果物
- DeadBlockAnalyzerBox 実装
- HC020 ルール実装
- テストケース 4 本
- スモークスクリプト
---
## 7. Task 6: ドキュメント & CURRENT_TASK 更新
### ドキュメント更新
1. **phase154_mir_cfg_deadblocks.md** に：
- 実装結果を記録
- CFG 統合の最終設計
2. **hako_check_design.md** を更新：
- HC020 ルールの説明
- CFG 解析機能の説明
3. **CURRENT_TASK.md**：
- Phase 154 セクションを追加
4. **CLAUDE.md**：
- hako_check ワークフローに `--dead-blocks` 追記（必要なら）
### 成果物
- 各種ドキュメント更新
- git commit
---
## ✅ 完成チェックリスト（Phase 154）
- [ ] Task 1: MIR/CFG 情報インベントリ完了
- [ ] CFG 構造確認
- [ ] Analysis IR 拡張フィールド決定
- [ ] Task 2: DeadBlockAnalyzerBox 設計
- [ ] API シグネチャ決定
- [ ] 到達可能性アルゴリズム決定
- [ ] Task 3: パイプライン統合設計
- [ ] CLI フラグ仕様確定
- [ ] ルール実行順序確定
- [ ] Task 4: テストケース設計
- [ ] テスト .hako 4 本設計
- [ ] Task 5: 実装 & テスト
- [ ] DeadBlockAnalyzerBox 実装
- [ ] HC020 ルール実装
- [ ] テストケース実装
- [ ] スモークスクリプト作成
- [ ] Task 6: ドキュメント更新
- [ ] phase154_mir_cfg_deadblocks.md 確定版
- [ ] hako_check_design.md 更新
- [ ] CURRENT_TASK.md 更新
- [ ] git commit
---
## 技術的考慮事項
### JoinIR Strict モードとの整合性
Phase 150 で確認済みの代表ケースで CFG 情報が取れることを確認：
- `peek_expr_block.hako` - match 式、ブロック式
- `loop_min_while.hako` - ループ変数、Entry/Exit PHI
- `joinir_min_loop.hako` - break 制御
- `joinir_if_select_simple.hako` - 早期 return
### Analysis IR の CFG 拡張案
```json
{
"methods": [...],
"calls": [...],
"boxes": [...],
"entrypoints": [...],
"cfg": {
"functions": [
{
"name": "Main.main",
"entry_block": 0,
"blocks": [
{"id": 0, "successors": [1, 2], "terminator": "Branch"},
{"id": 1, "successors": [3], "terminator": "Jump"},
{"id": 2, "successors": [3], "terminator": "Jump"},
{"id": 3, "successors": [], "terminator": "Return"}
]
}
]
}
}
```
---
## 次のステップ
Phase 154 完了後：
- **Phase 155+**: より高度な解析（定数畳み込み、型推論など）
- **Phase 160+**: .hako JoinIR/MIR 移植章
---
**作成日**: 2025-12-04
**Phase**: 154（MIR CFG 統合 & ブロックレベル unreachable 検出）
Status: Historical

270
docs/archive/phases/phase-150-167/phase154_mir_cfg_inventory.md Normal file
View File

@ -0,0 +1,270 @@
# Phase 154: MIR/CFG Information Inventory
## Task 1 Results: MIR/CFG Information Investigation
### MIR BasicBlock Structure (from `src/mir/basic_block.rs`)
The MIR already contains rich CFG information:
```rust
pub struct BasicBlock {
pub id: BasicBlockId,
pub instructions: Vec<MirInstruction>,
pub terminator: Option<MirInstruction>,
pub predecessors: BTreeSet<BasicBlockId>,
pub successors: BTreeSet<BasicBlockId>,
pub effects: EffectMask,
pub reachable: bool, // Already computed!
pub sealed: bool,
}
```
**Key findings:**
- CFG edges already tracked via `predecessors` and `successors`
- Block reachability already computed during MIR construction
- Terminators (Branch/Jump/Return) determine control flow
### Terminator Types (from `src/mir/instruction.rs`)
```rust
// Control flow terminators
Branch { condition, then_bb, else_bb } // Conditional
Jump { target } // Unconditional
Return { value } // Function exit
```
### Current Analysis IR Structure (from `tools/hako_check/analysis_consumer.hako`)
```javascript
{
"path": String,
"uses": Array<String>,
"boxes": Array<BoxInfo>,
"methods": Array<String>,
"calls": Array<CallEdge>,
"entrypoints": Array<String>,
"source": String
}
```
**Missing:** CFG/block-level information
## Proposed Analysis IR Extension
### Option A: Add CFG field (Recommended)
```javascript
{
// ... existing fields ...
"cfg": {
"functions": [
{
"name": "Main.main/0",
"entry_block": 0,
"blocks": [
{
"id": 0,
"reachable": true,
"successors": [1, 2],
"terminator": "Branch"
},
{
"id": 1,
"reachable": true,
"successors": [3],
"terminator": "Jump"
},
{
"id": 2,
"reachable": false, // <-- Dead block!
"successors": [3],
"terminator": "Jump"
}
]
}
]
}
}
```
**Advantages:**
- Minimal: Only essential CFG data
- Extensible: Can add more fields later
- Backward compatible: Optional field
### Option B: Embed in methods array
```javascript
{
"methods": [
{
"name": "Main.main/0",
"arity": 0,
"cfg": { /* ... */ }
}
]
}
```
**Disadvantages:**
- Breaks existing method array format (Array<String>)
- More complex migration
**Decision: Choose Option A**
## CFG Information Sources
### Source 1: MIR Module (Preferred)
**File:** `src/mir/mod.rs`
```rust
pub struct MirModule {
pub functions: BTreeMap<String, MirFunction>,
// ...
}
pub struct MirFunction {
pub blocks: BTreeMap<BasicBlockId, BasicBlock>,
// ...
}
```
**Access Pattern:**
```rust
for (func_name, function) in &module.functions {
for (block_id, block) in &function.blocks {
println!("Block {}: reachable={}", block_id, block.reachable);
println!(" Successors: {:?}", block.successors);
println!(" Terminator: {:?}", block.terminator);
}
}
```
### Source 2: MIR Printer
**File:** `src/mir/printer.rs`
Already has logic to traverse and format CFG:
```rust
pub fn print_function(&self, function: &MirFunction) -> String {
// Iterates over blocks and prints successors/predecessors
}
```
## Implementation Strategy
### Step 1: Extract CFG during MIR compilation
**Where:** `src/mir/mod.rs` or new `src/mir/cfg_extractor.rs`
```rust
pub fn extract_cfg_info(module: &MirModule) -> serde_json::Value {
let mut functions = Vec::new();
for (func_name, function) in &module.functions {
let mut blocks = Vec::new();
for (block_id, block) in &function.blocks {
blocks.push(json!({
"id": block_id.0,
"reachable": block.reachable,
"successors": block.successors.iter()
.map(|id| id.0).collect::<Vec<_>>(),
"terminator": terminator_name(&block.terminator)
}));
}
functions.push(json!({
"name": func_name,
"entry_block": function.entry_block.0,
"blocks": blocks
}));
}
json!({ "functions": functions })
}
```
### Step 2: Integrate into Analysis IR
**File:** `tools/hako_check/analysis_consumer.hako`
Add CFG extraction call:
```hako
// After existing IR building...
if needs_cfg {
local cfg_info = extract_cfg_from_mir(module)
ir.set("cfg", cfg_info)
}
```
### Step 3: DeadBlockAnalyzerBox consumes CFG
**File:** `tools/hako_check/rules/rule_dead_blocks.hako`
```hako
static box DeadBlockAnalyzerBox {
method apply_ir(ir, path, out) {
local cfg = ir.get("cfg")
if cfg == null { return }
local functions = cfg.get("functions")
local i = 0
while i < functions.size() {
local func = functions.get(i)
me._analyze_function_blocks(func, path, out)
i = i + 1
}
}
_analyze_function_blocks(func, path, out) {
local blocks = func.get("blocks")
local func_name = func.get("name")
local bi = 0
while bi < blocks.size() {
local block = blocks.get(bi)
local reachable = block.get("reachable")
if reachable == 0 {
local msg = "[HC020] Unreachable block: fn=" + func_name
+ " bb=" + me._itoa(block.get("id"))
out.push(msg + " :: " + path)
}
bi = bi + 1
}
}
}
```
## JoinIR Strict Mode Compatibility
**Question:** Does `NYASH_JOINIR_STRICT=1` affect CFG structure?
**Answer:** No. CFG is computed **after** JoinIR lowering in `MirBuilder`:
1. JoinIR → MIR lowering (produces blocks with terminators)
2. CFG computation (fills predecessors/successors from terminators)
3. Reachability analysis (marks unreachable blocks)
**Verification needed:** Test with Phase 150 representative cases:
- `peek_expr_block.hako` - Match expressions
- `loop_min_while.hako` - Loop with PHI
- `joinir_min_loop.hako` - Break control
- `joinir_if_select_simple.hako` - Early return
## Next Steps
1. ✅ Create `src/mir/cfg_extractor.rs` - Extract CFG to JSON
2. ⏳ Modify `analysis_consumer.hako` - Add CFG field
3. ⏳ Implement `rule_dead_blocks.hako` - DeadBlockAnalyzerBox
4. ⏳ Create test cases - 4 dead block patterns
5. ⏳ Update CLI - Add `--dead-blocks` flag
---
**Created:** 2025-12-04
**Phase:** 154 (MIR CFG Integration & Dead Block Detection)
**Status:** Task 1 Complete
Status: Historical

484
docs/archive/phases/phase-150-167/phase155_mir_cfg_bridge.md Normal file
View File

@ -0,0 +1,484 @@
# Phase 155: MIR CFG データブリッジ実装
## 0. ゴール
**Phase 154 で設計した DeadBlockAnalyzerBox を、実際に MIR CFG データで動かすための「データブリッジ」を実装する。**
目的：
- Rust MIR → Analysis IR へ CFG データを抽出・変換
- `extract_mir_cfg()` builtin 関数を実装
- HC020（unreachable basic block 検出）を完全に動作させる
---
## 実装状況 (2025-12-04)
### ✅ 完了項目
1. **MIR JSON への CFG 追加** (Phase 155-1)
- `src/runner/mir_json_emit.rs` を修正
- `extract_cfg_info()` を MIR JSON 出力時に呼び出し
- CFG データを JSON の `cfg` フィールドとして出力
- v0/v1 両フォーマット対応
2. **Analysis IR への CFG フィールド追加** (Phase 155-2 MVP)
- `tools/hako_check/analysis_consumer.hako` を修正
- 空の CFG 構造体を Analysis IR に追加（暫定実装）
- DeadBlockAnalyzerBox が `ir.get("cfg")` で CFG にアクセス可能
### 🔄 未完了項目（今後の実装）
3. **実際の CFG データ連携**
- MIR JSON から CFG を読み込む処理が未実装
- 現在は空の CFG 構造体のみ（ブロック情報なし）
- HC020 はスキップされる（CFG functions が空のため）
4. **builtin 関数の実装**
- `extract_mir_cfg()` builtin 関数は未実装
- Phase 155 指示書では builtin 関数経由を想定
- 現状では Rust 側で CFG を MIR JSON に含めるのみ
---
## 1. 背景：Phase 154 の現状
### 何が完了したか
- ✅ DeadBlockAnalyzerBox (HC020 ルール)
- ✅ CLI フラグ `--dead-blocks`
- ✅ テストケース 4 本
- ✅ スモークスクリプト
### 何が残っているか（このフェーズ）
- 🔄 **CFG データブリッジ**
- MIR JSON から CFG 情報を抽出
- Analysis IR の `cfg` フィールドに追加
- `.hako` コード内で呼び出し可能にする
---
## 2. Scope / Non-scope
### ✅ やること
1. **Rust 側：CFG 抽出機能**
- `src/mir/cfg_extractor.rs` からの CFG 抽出（既に Phase 154 で作成済み）
- `extract_mir_cfg()` builtin 関数を作成
- JSON シリアライズ対応
2. **.hako 側：Analysis IR 拡張**
- `tools/hako_check/analysis_ir.hako` を拡張
- `cfg` フィールドを Analysis IR に追加
- `analysis_consumer.hako` から `extract_mir_cfg()` を呼び出し
3. **CLI 統合**
- hako_check の `--dead-blocks` フラグで HC020 実行時に CFG が利用される
- スモークテストで HC020 出力を確認
4. **テスト & 検証**
- Phase 154 の 4 テストケースすべてで HC020 出力確認
- スモークスクリプト成功確認
### ❌ やらないこと
- Phase 154 の HC020 ロジック修正（既に完成）
- 新しい解析ルール追加（Phase 156+ へ）
- CFG 可視化（DOT 出力など）
---
## 3. 技術概要
### 3.1 データフロー
```
MIR JSON (Phase 154 作成済み)
↓
extract_mir_cfg() builtin (Rust) ← このフェーズで実装
↓
cfg: { functions: [...] } (JSON)
↓
analysis_consumer.hako (呼び出し側)
↓
Analysis IR (cfg フィールド付き)
↓
DeadBlockAnalyzerBox (HC020)
↓
HC020 出力
```
### 3.2 Analysis IR 拡張案
```json
{
"methods": [...],
"calls": [...],
"boxes": [...],
"entrypoints": [...],
"cfg": {
"functions": [
{
"name": "Main.main",
"entry_block": 0,
"blocks": [
{
"id": 0,
"successors": [1, 2],
"terminator": "Branch"
},
{
"id": 1,
"successors": [3],
"terminator": "Jump"
},
{
"id": 2,
"successors": [3],
"terminator": "Jump"
},
{
"id": 3,
"successors": [],
"terminator": "Return"
}
]
}
]
}
}
```
---
## 4. Task 1: extract_mir_cfg() builtin 関数実装
### 対象ファイル
- `src/mir/cfg_extractor.rs` - 既存（Phase 154 作成済み）
- `src/runtime/builtin_functions.rs` または `src/runtime/builtin_registry.rs` - builtin 登録
- `src/mir/mod.rs` - モジュール露出
### やること
1. **extract_mir_cfg() 関数を実装**
- 入力：MIR Function オブジェクト
- 出力：CFG JSON オブジェクト
- 実装例：
```rust
pub fn extract_mir_cfg(function: &MirFunction) -> serde_json::Value {
let blocks: Vec<_> = function.blocks.values().map(|block| {
serde_json::json!({
"id": block.id.0,
"successors": get_successors(block),
"terminator": format!("{:?}", block.terminator)
})
}).collect();
serde_json::json!({
"name": "...", // 関数名は別途指定
"entry_block": 0,
"blocks": blocks
})
}
```
2. **Builtin Registry に登録**
- 関数シグネチャ：`extract_mir_cfg(mir_json: Object) -> Object`
- JoinIR ビルダーから呼び出し可能に
3. **テスト**
- 単体テスト作成：`test_extract_mir_cfg_simple()`
- 複数ブロック、分岐、ループ対応確認
### 成果物
- `extract_mir_cfg()` builtin 実装
- Builtin 登録完了
- ユニットテスト
---
## 5. Task 2: analysis_consumer.hako 修正
### 対象ファイル
- `tools/hako_check/analysis_consumer.hako`
### やること
1. **MIR JSON を受け取り、CFG を抽出**
```hako
method apply_ir(ir, options) {
// ... 既存処理 ...
// CFG 抽出（新規）
local cfg_data = me.extract_cfg_from_ir(ir)
// Analysis IR に cfg を追加
ir.set("cfg", cfg_data)
}
method extract_cfg_from_ir(ir) {
// builtin extract_mir_cfg() 呼び出し
// または直接 JSON 操作
local functions = ir.get("functions")
local cfg_functions = ...
return cfg_functions
}
```
2. **HC020 実行時に CFG が利用される確認**
- DeadBlockAnalyzerBox が `ir.cfg` を参照
### 成果物
- `analysis_consumer.hako` 修正
- CFG 抽出ロジック統合
---
## 6. Task 3: 統合テスト & 検証
### テスト項目
1. **Phase 154 の 4 テストケース全て実行**
```bash
./tools/hako_check_deadblocks_smoke.sh --with-cfg
```
2. **期待される HC020 出力**
```
[HC020] Unreachable basic block: fn=TestEarlyReturn.test bb=2
[HC020] Unreachable basic block: fn=TestAlwaysFalse.test bb=1
[HC020] Unreachable basic block: fn=TestInfiniteLoop.test bb=2
[HC020] Unreachable basic block: fn=TestAfterBreak.test bb=2
```
3. **スモークスクリプト更新**
- CFG ブリッジ有効時の出力確認
- HC019 + HC020 の両方が実行される確認
### 成果物
- 統合テスト結果
- スモークスクリプト成功
---
## 7. Task 4: ドキュメント & CURRENT_TASK 更新
### ドキュメント
1. **phase155_mir_cfg_bridge.md** に：
- 実装結果を記録
- データフロー図
- テスト結果
2. **CURRENT_TASK.md**：
- Phase 154 完了記録
- Phase 155 完了記録
- Phase 156 への推奨
### git commit
```
feat(hako_check): Phase 155 MIR CFG data bridge implementation
🌉 CFG データブリッジ完成！
🔗 実装内容:
- extract_mir_cfg() builtin 関数（Rust）
- analysis_consumer.hako 修正（.hako）
- HC020 完全動作確認
✅ テスト結果: 4/4 PASS
- TestEarlyReturn
- TestAlwaysFalse
- TestInfiniteLoop
- TestAfterBreak
🎯 Phase 154 + 155 で hako_check HC020 ルール完全実装！
```
---
## ✅ 完成チェックリスト（Phase 155）
- [ ] Task 1: extract_mir_cfg() builtin 実装
- [ ] 関数実装
- [ ] Builtin 登録
- [ ] ユニットテスト
- [ ] Task 2: analysis_consumer.hako 修正
- [ ] CFG 抽出ロジック統合
- [ ] DeadBlockAnalyzerBox との連携確認
- [ ] Task 3: 統合テスト & 検証
- [ ] 4 テストケース全て HC020 出力確認
- [ ] スモークスクリプト成功
- [ ] Task 4: ドキュメント & CURRENT_TASK 更新
- [ ] 実装ドキュメント完成
- [ ] git commit
---
## 技術的考慮事項
### CFG 抽出の鍵
- **Entry Block**: 関数の最初のブロック（多くの場合 block_id = 0）
- **Successors**: terminator から判定
- `Jump { target }` → 1 successor
- `Branch { then_bb, else_bb }` → 2 successors
- `Return` → 0 successors
- **Reachability**: DFS で entry から到達可能なブロックを収集
### .hako での JSON 操作
```hako
// JSON オブジェクト生成
local cfg_obj = {}
cfg_obj.set("name", "Main.main")
cfg_obj.set("entry_block", 0)
// JSON 配列操作
local blocks = []
blocks.push(block_info)
cfg_obj.set("blocks", blocks)
```
---
## 次のステップ
Phase 155 完了後：
- **Phase 156**: HC021（定数畳み込み検出）
- **Phase 157**: HC022（型不一致検出）
---
## 参考リソース
- **Phase 154**: `docs/development/current/main/phase154_mir_cfg_deadblocks.md`
- **MIR CFG 抽出**: `src/mir/cfg_extractor.rs` (Phase 154 で作成済み)
- **Analysis IR 定義**: `tools/hako_check/analysis_ir.hako`
- **DeadBlockAnalyzerBox**: `tools/hako_check/rules/rule_dead_blocks.hako`
---
**作成日**: 2025-12-04
**Phase**: 155（MIR CFG データブリッジ実装）
**予定工数**: 2-3 時間
**難易度**: 低（主に plumbing）
---
## Phase 155 MVP 実装詳細
### 実装アプローチ
**Phase 155-1: MIR JSON に CFG を含める** ✅ 完了
- 場所: `src/runner/mir_json_emit.rs`
- 変更: `emit_mir_json_for_harness()` と `emit_mir_json_for_harness_bin()`
- 処理:
```rust
// Phase 155: Extract CFG information for hako_check
let cfg_info = nyash_rust::mir::extract_cfg_info(module);
let root = if use_v1_schema {
let mut root = create_json_v1_root(json!(funs));
if let Some(obj) = root.as_object_mut() {
obj.insert("cfg".to_string(), cfg_info);
}
root
} else {
json!({"functions": funs, "cfg": cfg_info})
};
```
**Phase 155-2: Analysis IR に CFG フィールド追加** ✅ MVP 完了
- 場所: `tools/hako_check/analysis_consumer.hako`
- 変更: `build_from_source_flags()` の最後に CFG フィールドを追加
- 処理:
```hako
// Phase 155: Add mock CFG data for MVP (will be replaced with actual MIR CFG extraction)
// For now, create empty CFG structure so DeadBlockAnalyzerBox doesn't crash
local cfg = new MapBox()
local cfg_functions = new ArrayBox()
cfg.set("functions", cfg_functions)
ir.set("cfg", cfg)
```
### MVP の制限事項
1. **CFG データは空**
- MIR JSON に CFG は含まれるが、hako_check は読み込まない
- Analysis IR の `cfg.functions` は空配列
- DeadBlockAnalyzerBox は実行されるが、検出結果は常に 0 件
2. **MIR 生成パスが未統合**
- hako_check は現在ソース解析のみ（AST ベース）
- MIR 生成・読み込みパスがない
- MIR JSON ファイルを中間ファイルとして使う設計が必要
3. **builtin 関数なし**
- `extract_mir_cfg()` builtin 関数は未実装
- .hako から Rust 関数を直接呼び出す仕組みが未整備
### 次のステップ（Phase 156 or 155.5）
**Option A: hako_check に MIR パイプライン統合**
1. hako_check.sh で MIR JSON を生成
2. cli.hako で MIR JSON を読み込み
3. CFG を Analysis IR に反映
4. HC020 が実際にブロックを検出
**Option B: builtin 関数経由**
1. Rust 側で builtin 関数システムを実装
2. `extract_mir_cfg(mir_json)` を .hako から呼び出し可能に
3. analysis_consumer.hako で MIR JSON を処理
**推奨**: Option A（よりシンプル、既存の hakorune_emit_mir.sh を活用）
---
## テスト結果
### 基本動作確認
```bash
# MIR JSON に CFG が含まれることを確認
$ ./tools/hakorune_emit_mir.sh test.hako /tmp/test.json
$ jq '.cfg.functions[0].blocks' /tmp/test.json
# → CFG ブロック情報が出力される ✅
```
### hako_check 実行
```bash
$ ./tools/hako_check.sh apps/tests/hako_check/test_dead_blocks_early_return.hako
# → エラーなく実行完了 ✅
# → HC020 出力なし（CFG が空のため）✅ 期待通り
```
---
## まとめ
Phase 155 MVP として以下を達成：
- ✅ MIR JSON に CFG データを追加（Rust 側）
- ✅ Analysis IR に CFG フィールドを追加（.hako 側）
- ✅ DeadBlockAnalyzerBox が CFG にアクセス可能な構造
今後の課題：
- 🔄 MIR JSON → Analysis IR のデータ連携
- 🔄 hako_check の MIR パイプライン統合 または builtin 関数実装
Phase 154 + 155 により、HC020 の基盤は完成。実際の検出機能は Phase 156 で実装推奨。
---
**実装日**: 2025-12-04
**実装者**: Claude (AI Assistant)
**コミット**: feat(hako_check): Phase 155 MIR CFG data bridge (MVP)
Status: Historical

451
docs/archive/phases/phase-150-167/phase156_hako_check_mir_pipeline.md Normal file
View File

@ -0,0 +1,451 @@
# Phase 156: hako_check MIR パイプライン統合（HC020 を実働させる）
## 0. ゴール
**hako_check が MIR JSON + CFG をちゃんと入力として受け取れるようにし、Phase 154/155 で用意した HC020（unreachable basic block 検出）が実際にブロックを報告するところまで持っていく。**
目的：
- hako_check に MIR パイプラインを統合
- HC020 が CFG から unreachable block を実際に検出
- **Rust 側の変更なし**（.hako + シェルスクリプトのみ）
---
## 1. 設計方針
### Rust を触らない理由
- Phase 155 で MIR JSON に CFG を含める処理は完了済み
- 今後のセルフホスティングを考えると、.hako 側で拡張可能な設計が重要
- 解析ロジックは .hako で実装 → 将来 .hako コンパイラ自体でも使える
### アーキテクチャ
```
target.hako
↓
hakorune_emit_mir.sh（既存 or 新規）
↓
/tmp/mir.json（CFG 付き）
↓
hako_check.sh（MIR JSON パスを渡す）
↓
cli.hako（MIR JSON を読み込み）
↓
analysis_consumer.hako（CFG を Analysis IR に統合）
↓
rule_dead_blocks.hako（HC020: BFS/DFS で unreachable 検出）
↓
[HC020] Unreachable basic block: fn=..., bb=...
```
---
## 2. Task 1: 現在の hako_check.sh パイプライン確認
### 対象ファイル
- `tools/hako_check.sh`
- `tools/hako_check/cli.hako`
### やること
1. **現状確認**
- CLI が何を渡しているか確認
- どのバックエンドで .hako を実行しているか（VM/LLVM/PyVM）
- AST/analysis JSON だけを渡しているのか、MIR JSON はまだ使っていないのか
2. **結果を記録**
- `phase156_hako_check_mir_pipeline.md` の末尾に現状メモを追記
### 成果物
- 現状パイプラインの理解
- メモ記録
---
## 3. Task 2: hako_check.sh で MIR JSON を生成する
### 方針
hako_check を叩く前に、対象 .hako から MIR JSON を一時ファイルに吐くステップを追加する。
### やること
1. **MIR emit スクリプトの確認**
- `tools/hakorune_emit_mir.sh` があれば利用
- なければ `nyash --emit-mir-json` 等の既存 CLI オプションを使用
2. **hako_check.sh を修正**
```bash
# Phase 156: MIR JSON 生成
MIR_JSON_PATH="/tmp/hako_check_mir_$$.json"
./tools/hakorune_emit_mir.sh "$TARGET_FILE" "$MIR_JSON_PATH"
# MIR JSON パスを環境変数で渡す
export HAKO_CHECK_MIR_JSON="$MIR_JSON_PATH"
# 既存の hako_check 実行
...
```
3. **クリーンアップ**
- 終了時に一時ファイルを削除
### 成果物
- `tools/hako_check.sh` 修正
- MIR JSON 生成ステップ追加
---
## 4. Task 3: cli.hako で MIR JSON を読み込む
### 対象ファイル
- `tools/hako_check/cli.hako`
- `tools/hako_check/analysis_consumer.hako`
### やること
1. **環境変数から MIR JSON パスを取得**
```hako
local mir_json_path = env.get("HAKO_CHECK_MIR_JSON")
if mir_json_path != null {
local mir_data = me.load_json_file(mir_json_path)
// CFG を Analysis IR に統合
me.integrate_cfg_from_mir(ir, mir_data)
}
```
2. **CFG を Analysis IR に統合**
- MIR JSON の `cfg` フィールドを取得
- Analysis IR の `cfg` フィールドに設定
- Phase 155 で作成した空の CFG 構造体を置き換え
3. **AST ベースのルールは維持**
- 既存の HC001〜HC019 はそのまま動作
- MIR CFG は HC020 専用
### 成果物
- `cli.hako` 修正（MIR JSON 読み込み）
- `analysis_consumer.hako` 修正（CFG 統合）
---
## 5. Task 4: HC020 が CFG を使うようにする
### 対象ファイル
- `tools/hako_check/rules/rule_dead_blocks.hako`
### やること
1. **CFG データの取得**
```hako
local cfg = ir.get("cfg")
local functions = cfg.get("functions")
if functions == null or functions.length() == 0 {
// CFG がない場合はスキップ
return
}
```
2. **各関数ごとに到達可能性解析**
```hako
method analyze_function(fn_cfg, path, out) {
local entry_block = fn_cfg.get("entry_block")
local blocks = fn_cfg.get("blocks")
// BFS/DFS で到達可能なブロックを収集
local reachable = me.compute_reachability(entry_block, blocks)
// 未到達ブロックを報告
for block in blocks {
if not reachable.contains(block.get("id")) {
out.add_diagnostic({
"rule": "HC020",
"severity": "warning",
"message": "Unreachable basic block",
"fn": fn_cfg.get("name"),
"bb": block.get("id")
})
}
}
}
```
3. **BFS/DFS 実装**
```hako
method compute_reachability(entry, blocks) {
local visited = new SetBox()
local queue = new ArrayBox()
queue.push(entry)
loop(queue.length() > 0) {
local current = queue.shift()
if visited.contains(current) { continue }
visited.add(current)
local block = me.find_block(blocks, current)
if block != null {
local successors = block.get("successors")
for succ in successors {
if not visited.contains(succ) {
queue.push(succ)
}
}
}
}
return visited
}
```
### 期待される結果
Phase 154 のテスト 4 ケースで HC020 が報告：
- `test_dead_blocks_early_return.hako` → 早期 return 後のブロック検出
- `test_dead_blocks_always_false.hako` → false 条件内のブロック検出
- `test_dead_blocks_infinite_loop.hako` → 無限ループ後のブロック検出
- `test_dead_blocks_after_break.hako` → break 後のブロック検出
### 成果物
- `rule_dead_blocks.hako` 修正（BFS/DFS 実装）
- HC020 が実際にブロックを検出
---
## 6. Task 5: スモークと回帰確認
### スモークテスト
```bash
# HC020 スモーク
./tools/hako_check_deadblocks_smoke.sh
# 期待: [HC020] Unreachable basic block: ... が出力される
```
### 回帰テスト
```bash
# HC019 スモーク（dead code）
./tools/hako_check_deadcode_smoke.sh
# 期待: 既存の HC019 出力に変化なし
```
### JoinIR 経路確認
```bash
# JoinIR Strict モードで確認
NYASH_JOINIR_STRICT=1 ./tools/hako_check.sh --dead-blocks apps/tests/hako_check/test_dead_blocks_early_return.hako
# 期待: JoinIR→MIR→CFG→HC020 のラインに崩れなし
```
### 成果物
- スモークテスト成功
- 回帰なし確認
- JoinIR 経路確認
---
## 7. Task 6: ドキュメントと CURRENT_TASK 更新
### ドキュメント更新
1. **phase156_hako_check_mir_pipeline.md** に：
- 実装結果を記録
- パイプライン図の確定版
2. **hako_check_design.md** に：
- 「HC020 は MIR CFG を入力にする」こと
- 「CLI は内部で一度 MIR JSON を生成してから hako_check を実行する」こと
3. **CURRENT_TASK.md** に：
- Phase 156 セクションを追加
- Phase 154/155/156 の完了記録
### git commit
```
feat(hako_check): Phase 156 MIR pipeline integration for HC020
🎯 HC020 が実際に unreachable block を検出！
🔧 実装内容:
- hako_check.sh: MIR JSON 生成ステップ追加
- cli.hako: MIR JSON 読み込み
- analysis_consumer.hako: CFG を Analysis IR に統合
- rule_dead_blocks.hako: BFS/DFS で到達可能性解析
✅ テスト結果:
- test_dead_blocks_early_return: [HC020] 検出
- test_dead_blocks_always_false: [HC020] 検出
- test_dead_blocks_infinite_loop: [HC020] 検出
- test_dead_blocks_after_break: [HC020] 検出
🏗️ 設計原則:
- Rust 側変更なし（Phase 155 まで）
- .hako + シェルスクリプトのみで拡張
- セルフホスティング対応設計
```
---
## ✅ 完成チェックリスト（Phase 156）
- [ ] Task 1: hako_check.sh パイプライン確認
- [ ] 現状パイプライン理解
- [ ] メモ記録
- [ ] Task 2: MIR JSON 生成
- [ ] hako_check.sh 修正
- [ ] MIR JSON 生成ステップ追加
- [ ] Task 3: MIR JSON 読み込み
- [ ] cli.hako 修正
- [ ] analysis_consumer.hako 修正
- [ ] CFG 統合確認
- [ ] Task 4: HC020 実装
- [ ] BFS/DFS 到達可能性解析
- [ ] unreachable block 報告
- [ ] 4 テストケースで検出確認
- [ ] Task 5: スモークと回帰
- [ ] HC020 スモーク成功
- [ ] HC019 回帰なし
- [ ] JoinIR 経路確認
- [ ] Task 6: ドキュメント更新
- [ ] phase156 実装結果記録
- [ ] hako_check_design.md 更新
- [ ] CURRENT_TASK.md 更新
- [ ] git commit
---
## 技術的注意点
### SetBox / ArrayBox の存在確認
.hako で Set/Array 操作が必要。存在しない場合は MapBox で代用：
```hako
// SetBox がない場合
local visited = new MapBox()
visited.set(block_id, true)
if visited.get(block_id) == true { ... }
```
### JSON ファイル読み込み
```hako
// FileBox + JsonBox で読み込み
local file = new FileBox()
local content = file.read(mir_json_path)
local json_parser = new JsonBox()
local data = json_parser.parse(content)
```
### 環境変数アクセス
```hako
// EnvBox または組み込み関数で取得
local mir_path = env.get("HAKO_CHECK_MIR_JSON")
```
---
## 次のステップ
Phase 156 完了後：
- **Phase 157**: HC021（定数畳み込み検出）
- **Phase 158**: HC022（型不一致検出）
- **Phase 160+**: .hako JoinIR/MIR 移植
---
## 実装結果（Phase 156）
### 実装完了項目
✅ **Task 1-2: hako_check.sh パイプライン修正**
- MIR JSON 生成ステップ追加（hakorune_emit_mir.sh使用）
- MIR JSON content をインライン引数として渡す方式採用
- FileBox依存を回避（NYASH_DISABLE_PLUGINS=1 対応）
✅ **Task 3: cli.hako 修正**
- `--mir-json-content` 引数処理追加
- MIR JSON text を IR に `_mir_json_text` として格納
✅ **Task 4: analysis_consumer.hako CFG統合**
- 完全な JSON パーサー実装（約320行）
- CFG functions/blocks/successors/reachable 全フィールド対応
- 空CFG フォールバック処理
✅ **Task 5: rule_dead_blocks.hako**
- Rust側で計算済みの `reachable` フィールドを使用
- BFS/DFS は Rust 側（cfg_extractor.rs）で実装済み
- HC020 出力フォーマット実装済み
### 技術的設計決定
**1. FileBox回避アーキテクチャ**
- 問題: NYASH_DISABLE_PLUGINS=1 で FileBox 使用不可
- 解決: MIR JSON をインライン文字列として引数経由で渡す
- 利点: プラグイン依存なし、既存パターン（--source-file）と一貫性
**2. .hako JSON パーサー実装**
- 軽量な手動JSON解析（StringBox.substring/indexOf のみ使用）
- 必要最小限のフィールドのみ抽出
- エラーハンドリング: 空CFG にフォールバック
**3. Reachability計算の責務分離**
- Rust: CFG構築 + Reachability計算（cfg_extractor.rs）
- .hako: CFG読み込み + unreachable block報告のみ
- 理由: Rustで効率的な計算、.hakoはシンプルに保つ
---
**作成日**: 2025-12-04
**実装日**: 2025-12-04
**Phase**: 156（hako_check MIR パイプライン統合）
**予定工数**: 3-4 時間
**実工数**: 約4時間（JSON パーサー実装を含む）
**難易度**: 中（.hako JSON パーサー実装が主な作業）
**Rust 変更**: なし（.hako + シェルスクリプトのみ）
---
## 次のステップへの推奨事項
### フィードバック
**1. 改善提案**
- JSON パーサーの堅牢化（エスケープシーケンス対応など）
- デバッグ出力の統合（--debug フラグで CFG内容表示）
- エラーメッセージの詳細化（どのフィールドの解析で失敗したか）
**2. 実装中に気づいた課題**
- .hako に builtin JSON パーサーがないため手動実装が必要
- StringBox のみでJSON解析は冗長（約320行）
- FileBox がプラグイン依存で、開発環境では常に無効化される
**3. 箱化モジュール化パターンの改善点**
- JSON解析ユーティリティを共通モジュール化すべき
- `tools/hako_shared/json_parser.hako` として切り出し推奨
- 他の解析ルールでも再利用可能
**4. .hako API の不足点**
- JSON builtin関数（parse_json/toJson）が欲しい
- 環境変数アクセス（getenv）が欲しい
- File I/O がプラグイン必須なのは開発時に不便
**5. Phase 157+ への推奨**
- HC021（定数畳み込み検出）でも同様のパターンを使用可能
- MIR解析ルール追加時のテンプレートとして活用
- JSON schema validation を .hako で実装も検討
Status: Historical

498
docs/archive/phases/phase-150-167/phase161_analyzer_box_design.md Normal file
View File

@ -0,0 +1,498 @@
# Phase 161 Task 2: Analyzer Box Design (JoinIrAnalyzerBox / MirAnalyzerBox)
**Status**: 🎯 **DESIGN PHASE** - Defining .hako Analyzer Box structure and responsibilities
**Objective**: Design the foundational .hako Boxes for analyzing Rust JSON MIR/JoinIR data, establishing clear responsibilities and API contracts.
---
## Executive Summary
Phase 161 aims to port JoinIR analysis logic from Rust to .hako. The first step was creating a complete JSON format inventory (Task 1, completed). Now we design the .hako Box architecture that will consume this data.
**Key Design Decision**: Create **TWO specialized Analyzer Boxes** with distinct, non-overlapping responsibilities:
1. **MirAnalyzerBox**: Analyzes MIR JSON v1 (primary)
2. **JoinIrAnalyzerBox**: Analyzes JoinIR JSON v0 (secondary, for compatibility)
Both boxes will share a common **JsonParserBox** utility for low-level JSON parsing operations.
---
## 1. Core Architecture: Box Responsibilities
### 1.1 JsonParserBox (Shared Utility)
**Purpose**: Low-level JSON parsing and traversal (reusable across both analyzers)
**Scope**: Single-minded JSON access without semantic analysis
**Responsibilities**:
- Parse JSON text into MapBox/ArrayBox structure
- Provide recursive accessor methods: `get()`, `getArray()`, `getInt()`, `getString()`
- Handle type conversions safely with nullability
- Provide iteration helpers: `forEach()`, `map()`, `filter()`
**Key Methods**:
```
birth(jsonText) // Parse JSON from string
get(path: string): any // Get nested value by dot-notation (e.g., "functions/0/blocks")
getArray(path): ArrayBox // Get array at path with type safety
getString(path): string // Get string with default ""
getInt(path): integer // Get integer with default 0
getBool(path): boolean // Get boolean with default false
```
**Non-Scope**: Semantic analysis, MIR-specific validation, JoinIR-specific knowledge
---
### 1.2 MirAnalyzerBox (Primary Analyzer)
**Purpose**: Analyze MIR JSON v1 according to Phase 161 specifications
**Scope**: All MIR-specific analysis operations
**Responsibilities**:
1. **Schema Validation**: Verify MIR JSON has required fields (schema_version, functions, cfg)
2. **Instruction Type Detection**: Identify instruction types (14 types in MIR v1)
3. **PHI Detection**: Identify PHI instructions and extract incoming values
4. **Loop Detection**: Identify loops via backward edge analysis (CFG)
5. **If Detection**: Identify conditional branches and PHI merge points
6. **Type Analysis**: Propagate type hints through PHI/BinOp/Compare operations
7. **Reachability Analysis**: Mark unreachable blocks (dead code detection)
**Key Methods** (Single-Function Analysis):
```
birth(mirJsonText) // Parse MIR JSON
// === Schema Validation ===
validateSchema(): boolean // Check MIR v1 structure
// === Function-Level Analysis ===
summarize_function(funcIndex: integer): MapBox // Returns:
// {
// name: string,
// params: integer,
// blocks: integer,
// instructions: integer,
// has_loops: boolean,
// has_ifs: boolean,
// has_phis: boolean
// }
// === Instruction Detection ===
list_instructions(funcIndex): ArrayBox // Returns array of:
// {
// block_id: integer,
// inst_index: integer,
// op: string,
// dest: integer (ValueId),
// src1, src2: integer (ValueId)
// }
// === PHI Analysis ===
list_phis(funcIndex): ArrayBox // Returns array of PHI instructions:
// {
// block_id: integer,
// dest: integer (ValueId),
// incoming: ArrayBox of
// [value_id, from_block_id]
// }
// === Loop Detection ===
list_loops(funcIndex): ArrayBox // Returns array of loop structures:
// {
// header_block: integer,
// exit_block: integer,
// back_edge_from: integer,
// contains_blocks: ArrayBox
// }
// === If Detection ===
list_ifs(funcIndex): ArrayBox // Returns array of if structures:
// {
// condition_block: integer,
// condition_value: integer (ValueId),
// true_block: integer,
// false_block: integer,
// merge_block: integer
// }
// === Type Analysis ===
propagate_types(funcIndex): MapBox // Returns type map:
// {
// value_id: type_string
// (e.g., "i64", "void", "boxref")
// }
// === Control Flow Analysis ===
reachability_analysis(funcIndex): ArrayBox // Returns:
// {
// reachable_blocks: ArrayBox,
// unreachable_blocks: ArrayBox
// }
```
**Key Algorithms**:
#### PHI Detection Algorithm
```
For each block in function:
For each instruction in block:
If instruction.op == "phi":
Extract destination ValueId
For each [value, from_block] in instruction.incoming:
Record PHI merge point
Mark block as PHI merge block
```
#### Loop Detection Algorithm (CFG-based)
```
Build adjacency list from CFG (target → [from_blocks])
For each block B:
For each successor S in B:
If S's block_id < B's block_id:
Found backward edge B → S
S is loop header
Find all blocks in loop via DFS from S
Record loop structure
```
#### If Detection Algorithm
```
For each block B with Branch instruction:
condition = branch.condition (ValueId)
true_block = branch.targets[0]
false_block = branch.targets[1]
For each successor block S of true_block OR false_block:
If S has PHI instruction with incoming from both true_block AND false_block:
S is the merge block
Record if structure
```
#### Type Propagation Algorithm
```
Initialize: type_map[v] = v.hint (from Const/Compare/BinOp)
Iterate 4 times: // Maximum iterations before convergence
For each PHI instruction:
incoming_types = [type_map[v] for each [v, _] in phi.incoming]
Merge types: take most specific common type
type_map[phi.dest] = merged_type
For each BinOp/Compare/etc:
Propagate operand types to result
```
---
### 1.3 JoinIrAnalyzerBox (Secondary Analyzer)
**Purpose**: Analyze JoinIR JSON v0 (CPS-style format)
**Scope**: JoinIR-specific analysis operations
**Responsibilities**:
1. **Schema Validation**: Verify JoinIR JSON has required fields
2. **Continuation Extraction**: Parse CPS-style continuation structures
3. **Direct Conversion to MIR**: Transform JoinIR JSON to MIR-compatible format
4. **Backward Compatibility**: Support legacy JoinIR analysis workflows
**Key Methods**:
```
birth(joinirJsonText) // Parse JoinIR JSON
validateSchema(): boolean // Check JoinIR v0 structure
// === JoinIR-Specific Analysis ===
list_continuations(funcIndex): ArrayBox // Returns continuation structures
// === Conversion ===
convert_to_mir(funcIndex): string // Returns MIR JSON equivalent
// (enables reuse of MirAnalyzerBox)
```
**Note on Design**: JoinIrAnalyzerBox is intentionally minimal - its primary purpose is converting JoinIR to MIR format, then delegating to MirAnalyzerBox for actual analysis. This avoids code duplication.
---
## 2. Shared Infrastructure
### 2.1 AnalyzerCommonBox (Base Utilities)
**Purpose**: Common helper methods used by both analyzers
**Key Methods**:
```
// === Utility Methods ===
extract_function(funcIndex: integer): MapBox // Extract single function data
extract_cfg(funcIndex: integer): MapBox // Extract CFG for block analysis
build_adjacency_list(cfg): MapBox // Build block→blocks adjacency
// === Debugging/Tracing ===
set_verbose(enabled: boolean) // Enable detailed output
dump_function(funcIndex): string // Pretty-print function data
dump_cfg(funcIndex): string // Pretty-print CFG
```
---
## 3. Data Flow Architecture
```
JSON Input (MIR or JoinIR)
↓
JsonParserBox (Parse to MapBox/ArrayBox)
↓
├─→ MirAnalyzerBox → Semantic Analysis
│ ↓
│ (PHI detection, loop detection, etc.)
│ ↓
│ Analysis Results (ArrayBox/MapBox)
│
└─→ JoinIrAnalyzerBox → Convert to MIR
↓
(Transform JoinIR → MIR)
↓
MirAnalyzerBox (reuse)
↓
Analysis Results
```
---
## 4. API Contract: Method Signatures (Finalized)
### MirAnalyzerBox
```hako
static box MirAnalyzerBox {
// Parser state
parsed_mir: MapBox
json_parser: JsonParserBox
// Analysis cache
func_cache: MapBox // Memoization for expensive operations
verbose_mode: BoolBox
// Constructor
birth(mir_json_text: string) {
me.parsed_mir = JsonParserBox.parse(mir_json_text)
me.json_parser = new JsonParserBox()
me.func_cache = new MapBox()
me.verbose_mode = false
}
// === Validation ===
validateSchema(): BoolBox {
// Returns true if MIR v1 schema valid
}
// === Analysis Methods ===
summarize_function(funcIndex: IntegerBox): MapBox {
// Returns { name, params, blocks, instructions, has_loops, has_ifs, has_phis }
}
list_instructions(funcIndex: IntegerBox): ArrayBox {
// Returns array of { block_id, inst_index, op, dest, src1, src2 }
}
list_phis(funcIndex: IntegerBox): ArrayBox {
// Returns array of { block_id, dest, incoming }
}
list_loops(funcIndex: IntegerBox): ArrayBox {
// Returns array of { header_block, exit_block, back_edge_from, contains_blocks }
}
list_ifs(funcIndex: IntegerBox): ArrayBox {
// Returns array of { condition_block, condition_value, true_block, false_block, merge_block }
}
propagate_types(funcIndex: IntegerBox): MapBox {
// Returns { value_id: type_string }
}
reachability_analysis(funcIndex: IntegerBox): ArrayBox {
// Returns { reachable_blocks, unreachable_blocks }
}
// === Debugging ===
set_verbose(enabled: BoolBox) { }
dump_function(funcIndex: IntegerBox): StringBox { }
dump_cfg(funcIndex: IntegerBox): StringBox { }
}
```
### JsonParserBox
```hako
static box JsonParserBox {
root: MapBox
birth(json_text: string) {
// Parse JSON text into MapBox/ArrayBox structure
}
get(path: string): any {
// Get value by dot-notation path
}
getArray(path: string): ArrayBox { }
getString(path: string): string { }
getInt(path: string): integer { }
getBool(path: string): boolean { }
}
```
---
## 5. Implementation Strategy
### Phase 161-2: Basic MirAnalyzerBox Structure (First Iteration)
**Scope**: Get basic structure working, focus on `summarize_function()` and `list_instructions()`
1. Implement JsonParserBox (simple recursive MapBox builder)
2. Implement MirAnalyzerBox.birth() to parse MIR JSON
3. Implement validateSchema() to verify structure
4. Implement summarize_function() (basic field extraction)
5. Implement list_instructions() (iterate blocks, extract instructions)
**Success Criteria**:
- Can parse MIR JSON test files
- Can extract function metadata
- Can list all instructions in order
---
### Phase 161-3: PHI/Loop/If Detection
**Scope**: Advanced control flow analysis
1. Implement list_phis() using pattern matching
2. Implement list_loops() using CFG and backward edge detection
3. Implement list_ifs() using condition and merge detection
4. Test on representative functions
**Success Criteria**:
- Correctly identifies all PHI instructions
- Correctly detects loop header and back edges
- Correctly identifies if/merge structures
---
### Phase 161-4: Type Propagation
**Scope**: Type hint system
1. Implement type extraction from Const/Compare/BinOp
2. Implement 4-iteration propagation algorithm
3. Build type map for ValueId
**Success Criteria**:
- Type map captures all reachable types
- No type conflicts or inconsistencies
---
### Phase 161-5: Analysis Features
**Scope**: Extended functionality
1. Implement reachability analysis (mark unreachable blocks)
2. Implement dump methods for debugging
3. Add caching to expensive operations
---
## 6. Representative Functions for Testing
Per Task 3 selection criteria, these functions will be used for Phase 161-2+ validation:
1. **if_select_simple** (Simple if/else with PHI)
- 4 BasicBlocks
- 1 Branch instruction
- 1 PHI instruction at merge
- Type: Simple if pattern
2. **min_loop** (Minimal loop with PHI)
- 2 BasicBlocks (header + body)
- Loop back edge
- PHI instruction at header
- Type: Loop pattern
3. **skip_ws** (From JoinIR, more complex)
- 6+ BasicBlocks
- Nested control flow
- Multiple PHI instructions
- Type: Complex pattern
**Usage**: Each will be analyzed by MirAnalyzerBox to verify correctness of detection algorithms.
---
## 7. Design Principles Applied
### 🏗️ 箱にする (Boxification)
- Each analyzer box has single responsibility
- Clear API boundary (methods) with defined input/output contracts
- No shared mutable state between boxes
### 🌳 境界を作る (Clear Boundaries)
- JsonParserBox: Low-level JSON only
- MirAnalyzerBox: MIR semantics only
- JoinIrAnalyzerBox: JoinIR conversion only
- No intermingling of concerns
### ⚡ Fail-Fast
- validateSchema() must pass or error (no silent failures)
- Invalid instruction types cause immediate error
- Type propagation inconsistencies detected and reported
### 🔄 遅延シングルトン (Lazy Evaluation)
- Each method computes its result on-demand
- Results are cached in func_cache to avoid recomputation
- No pre-computation of unnecessary analysis
---
## 8. Questions Answered by This Design
**Q: Why two separate analyzer boxes?**
A: MIR and JoinIR have fundamentally different schemas. Separate boxes with clear single responsibilities are easier to test, maintain, and extend.
**Q: Why separate JsonParserBox?**
A: JSON parsing is orthogonal to semantic analysis. Extracting it enables reuse and makes testing easier.
**Q: Why caching?**
A: Control flow analysis is expensive (CFG traversal, reachability). Caching prevents redundant computation when multiple methods query the same data.
**Q: Why 4 iterations for type propagation?**
A: Based on Phase 25 experience - 4 iterations handles most practical programs. Documented in phase161_joinir_analyzer_design.md.
---
## 9. Next Steps (Task 3)
Once this design is approved:
1. **Task 3**: Formally select 3-5 representative functions that cover all detection patterns
2. **Task 4**: Implement basic .hako JsonParserBox and MirAnalyzerBox
3. **Task 5**: Create joinir_analyze.sh CLI entry point
4. **Task 6**: Test on representative functions
5. **Task 7**: Update CURRENT_TASK.md and roadmap
---
## 10. References
- **Phase 161 Task 1**: [phase161_joinir_analyzer_design.md](phase161_joinir_analyzer_design.md) - JSON schema inventory
- **Phase 173-B**: [phase173b-boxification-assessment.md](phase173b-boxification-assessment.md) - Boxification design principles
- **MIR INSTRUCTION_SET**: [docs/reference/mir/INSTRUCTION_SET.md](../../../reference/mir/INSTRUCTION_SET.md)
- **Box System**: [docs/reference/boxes-system/](../../../reference/boxes-system/)
---
**Status**: 🎯 Ready for Task 3 approval and representative function selection
Status: Historical

1010
docs/archive/phases/phase-150-167/phase161_joinir_analyzer_design.md Normal file
View File

File diff suppressed because it is too large Load Diff

523
docs/archive/phases/phase-150-167/phase161_jsonparser_loop_inventory.md Normal file
View File

@ -0,0 +1,523 @@
# Phase 161-impl-3: JsonParserBox ループインベントリ
## 概要
JsonParserBox (`tools/hako_shared/json_parser.hako`) に含まれるループを全て分類し、
JoinIR Pattern1-4 とのマッピングを行う。
## ループ一覧（11個）
### 1. `_parse_number` (L121-133)
```hako
loop(p < s.length()) {
local ch = s.substring(p, p+1)
local digit_pos = digits.indexOf(ch)
if digit_pos < 0 { break }
num_str = num_str + ch
p = p + 1
}
```
| 特徴 | 値 |
|------|-----|
| break | ✅ あり |
| continue | ❌ なし |
| if-else PHI | ❌ なし（単純if+break） |
| ループ変数 | `p`, `num_str` (2変数) |
| **パターン** | **Pattern2 (Break)** |
---
### 2. `_parse_string` (L150-178)
```hako
loop(p < s.length()) {
local ch = s.substring(p, p+1)
if ch == '"' {
// return inside loop
return result
}
if ch == "\\" {
// escape handling
str = str + ch; p = p + 1
str = str + s.substring(p, p+1); p = p + 1
continue
}
str = str + ch
p = p + 1
}
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし（return使用） |
| continue | ✅ あり |
| if-else PHI | ❌ なし |
| ループ変数 | `p`, `str` (2変数) |
| return in loop | ✅ あり |
| **パターン** | **Pattern4 (Continue) + return** |
---
### 3. `_parse_array` (L203-231)
```hako
loop(p < s.length()) {
local elem_result = me._parse_value(s, p)
if elem_result == null { return null }
arr.push(elem)
p = elem_result.get("pos")
if ch == "]" { return result }
if ch == "," { p = p + 1; continue }
return null
}
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし |
| continue | ✅ あり |
| if-else PHI | ❌ なし |
| ループ変数 | `p`, `arr` (2変数、arrはmutate) |
| return in loop | ✅ あり（複数箇所） |
| **パターン** | **Pattern4 (Continue) + multi-return** |
---
### 4. `_parse_object` (L256-304)
```hako
loop(p < s.length()) {
// parse key
if s.substring(p, p+1) != '"' { return null }
local key_result = me._parse_string(s, p)
// parse value
local value_result = me._parse_value(s, p)
obj.set(key, value)
if ch == "}" { return result }
if ch == "," { p = p + 1; continue }
return null
}
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし |
| continue | ✅ あり |
| if-else PHI | ❌ なし |
| ループ変数 | `p`, `obj` (2変数、objはmutate) |
| return in loop | ✅ あり（複数箇所） |
| **パターン** | **Pattern4 (Continue) + multi-return** |
---
### 5. `_skip_whitespace` (L312-319)
```hako
loop(p < s.length()) {
local ch = s.substring(p, p+1)
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
p = p + 1
} else {
break
}
}
```
| 特徴 | 値 |
|------|-----|
| break | ✅ あり |
| continue | ❌ なし |
| if-else PHI | ✅ あり（if-else分岐でpを更新） |
| ループ変数 | `p` (1変数) |
| **パターン** | **Pattern3 (If-Else PHI) + break** |
---
### 6. `_trim` (leading whitespace, L330-337)
```hako
loop(start < end) {
local ch = s.substring(start, start+1)
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
start = start + 1
} else {
break
}
}
```
| 特徴 | 値 |
|------|-----|
| break | ✅ あり |
| continue | ❌ なし |
| if-else PHI | ✅ あり |
| ループ変数 | `start` (1変数) |
| **パターン** | **Pattern3 (If-Else PHI) + break** |
---
### 7. `_trim` (trailing whitespace, L340-347)
```hako
loop(end > start) {
local ch = s.substring(end-1, end)
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
end = end - 1
} else {
break
}
}
```
| 特徴 | 値 |
|------|-----|
| break | ✅ あり |
| continue | ❌ なし |
| if-else PHI | ✅ あり |
| ループ変数 | `end` (1変数) |
| **パターン** | **Pattern3 (If-Else PHI) + break** |
---
### 8. `_match_literal` (L357-362)
```hako
loop(i < len) {
if s.substring(pos + i, pos + i + 1) != literal.substring(i, i + 1) {
return 0
}
i = i + 1
}
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし |
| continue | ❌ なし |
| if-else PHI | ❌ なし（単純if+return） |
| ループ変数 | `i` (1変数) |
| return in loop | ✅ あり |
| **パターン** | **Pattern1 (Simple) + return** |
---
### 9. `_unescape_string` (L373-431)
```hako
loop(i < s.length()) {
local ch = s.substring(i, i+1)
// flatten workaround for nested-if bug
local is_escape = 0
if ch == "\\" { is_escape = 1 }
if process_escape == 1 {
// multiple if-continue patterns
if next == "n" { result = result + "\n"; i = i + 2; continue }
if next == "t" { result = result + "\t"; i = i + 2; continue }
// ... more cases
}
result = result + ch
i = i + 1
}
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし |
| continue | ✅ あり（多数） |
| if-else PHI | ✅ あり（フラットworkaround済み） |
| ループ変数 | `i`, `result` (2変数) |
| **パターン** | **Pattern4 (Continue) + multi-PHI** |
| **複雑度** | **高**（フラット化workaround済み） |
---
### 10. `_atoi` (L453-460)
```hako
loop(i < n) {
local ch = s.substring(i, i+1)
if ch < "0" || ch > "9" { break }
local pos = digits.indexOf(ch)
if pos < 0 { break }
v = v * 10 + pos
i = i + 1
}
```
| 特徴 | 値 |
|------|-----|
| break | ✅ あり（複数箇所） |
| continue | ❌ なし |
| if-else PHI | ❌ なし |
| ループ変数 | `i`, `v` (2変数) |
| **パターン** | **Pattern2 (Break)** |
---
## パターン別サマリ
| パターン | ループ数 | 対象 |
|----------|----------|------|
| **Pattern1 (Simple)** | 1 | `_match_literal` (return in loop) |
| **Pattern2 (Break)** | 2 | `_parse_number`, `_atoi` |
| **Pattern3 (If-Else PHI) + break** | 3 | `_skip_whitespace`, `_trim`×2 |
| **Pattern4 (Continue)** | 5 | `_parse_string`, `_parse_array`, `_parse_object`, `_unescape_string`, + return variations |
## JoinIR 対応状況
### ✅ 現状で対応可能（Pattern1-2）
- `_match_literal` - Pattern1 + return
- `_parse_number` - Pattern2
- `_atoi` - Pattern2
### 🟡 拡張が必要（Pattern3）
- `_skip_whitespace` - **if-else + break の組み合わせ**
- `_trim` (leading) - **if-else + break の組み合わせ**
- `_trim` (trailing) - **if-else + break の組み合わせ**
### 🔴 大きな拡張が必要（Pattern4+）
- `_parse_string` - continue + return in loop
- `_parse_array` - continue + multi-return
- `_parse_object` - continue + multi-return
- `_unescape_string` - continue + multi-continue + if-else
## 推奨アクション
### 短期（Pattern3強化）
1. **Pattern3 + break 対応**: `_skip_whitespace`, `_trim`×2 を動かす
2. これで JsonParserBox の一部メソッドが動作可能に
### 中期（Pattern4基本）
1. **continue サポート**: `_parse_string`, `_match_literal` の return in loop 対応
2. **return in loop → break 変換**: 内部的に return を break + 値保存に変換
### 長期（Pattern4+完全対応）
1. **multi-return, multi-continue**: `_parse_array`, `_parse_object`
2. **複雑なフラット化パターン**: `_unescape_string`
## 備考
- `_unescape_string` は既に「MIR nested-if bug workaround」としてフラット化されている
- `_parse_value` 自体はループなし（再帰呼び出しのみ）
- ProgramJSONBox はループなし（getter のみ）
---
---
# BundleResolver ループインベントリ
## 対象ファイル
`lang/src/compiler/entry/bundle_resolver.hako`
## ループ一覧（8個）
### 1. Alias table parsing - outer loop (L25-45)
```hako
loop(i < table.length()) {
local j = table.indexOf("|||", i)
local seg = ""
if j >= 0 { seg = table.substring(i, j) } else { seg = table.substring(i, table.length()) }
// ... process seg ...
if j < 0 { break }
i = j + 3
}
```
| 特徴 | 値 |
|------|-----|
| break | ✅ あり |
| continue | ❌ なし |
| if-else PHI | ✅ あり（seg への代入） |
| ループ変数 | `i`, `seg` (2変数) |
| **パターン** | **Pattern3 (If-Else PHI) + break** |
---
### 2. Alias table parsing - inner loop for ':' search (L33)
```hako
loop(k < seg.length()) { if seg.substring(k,k+1) == ":" { pos = k break } k = k + 1 }
```
| 特徴 | 値 |
|------|-----|
| break | ✅ あり |
| continue | ❌ なし |
| if-else PHI | ❌ なし（単純if+break+代入） |
| ループ変数 | `k`, `pos` (2変数) |
| **パターン** | **Pattern2 (Break)** |
---
### 3. Require mods env alias check - outer loop (L52-71)
```hako
loop(i0 < rn0) {
local need = "" + require_mods.get(i0)
local present = 0
// inner loop for bundle_names check
// ... if present == 0 { ... }
i0 = i0 + 1
}
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし |
| continue | ❌ なし |
| if-else PHI | ❌ なし |
| ループ変数 | `i0` (1変数) |
| **パターン** | **Pattern1 (Simple)** |
---
### 4. Require mods env alias check - inner loop (L57)
```hako
loop(j0 < bn0) { if ("" + bundle_names.get(j0)) == need { present = 1 break } j0 = j0 + 1 }
```
| 特徴 | 値 |
|------|-----|
| break | ✅ あり |
| continue | ❌ なし |
| if-else PHI | ❌ なし |
| ループ変数 | `j0`, `present` (2変数) |
| **パターン** | **Pattern2 (Break)** |
---
### 5. Duplicate names check - outer loop (L76-87)
```hako
loop(i < n) {
local name_i = "" + bundle_names.get(i)
local j = i + 1
loop(j < n) { ... }
i = i + 1
}
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし |
| continue | ❌ なし |
| if-else PHI | ❌ なし |
| ループ変数 | `i` (1変数) |
| **パターン** | **Pattern1 (Simple)** |
---
### 6. Duplicate names check - inner loop (L79-85)
```hako
loop(j < n) {
if ("" + bundle_names.get(j)) == name_i {
print("[bundle/duplicate] " + name_i)
return null
}
j = j + 1
}
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし（return使用） |
| continue | ❌ なし |
| if-else PHI | ❌ なし |
| ループ変数 | `j` (1変数) |
| return in loop | ✅ あり |
| **パターン** | **Pattern1 (Simple) + return** |
---
### 7. Required modules check - outer loop (L92-101)
```hako
loop(idx < rn) {
local need = "" + require_mods.get(idx)
local found = 0
// inner loop
if found == 0 { print("[bundle/missing] " + need) return null }
idx = idx + 1
}
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし |
| continue | ❌ なし |
| if-else PHI | ❌ なし |
| ループ変数 | `idx` (1変数) |
| return in loop | ✅ あり（条件付き） |
| **パターン** | **Pattern1 (Simple) + return** |
---
### 8. Required modules check - inner loop (L97)
```hako
loop(j < bn) { if ("" + bundle_names.get(j)) == need { found = 1 break } j = j + 1 }
```
| 特徴 | 値 |
|------|-----|
| break | ✅ あり |
| continue | ❌ なし |
| if-else PHI | ❌ なし |
| ループ変数 | `j`, `found` (2変数) |
| **パターン** | **Pattern2 (Break)** |
---
### 9. Merge bundle_srcs (L107)
```hako
loop(i < m) { merged = merged + bundle_srcs.get(i) + "\n" i = i + 1 }
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし |
| continue | ❌ なし |
| if-else PHI | ❌ なし |
| ループ変数 | `i`, `merged` (2変数) |
| **パターン** | **Pattern1 (Simple)** |
---
### 10. Merge bundle_mod_srcs (L111)
```hako
loop(i2 < m2) { merged = merged + bundle_mod_srcs.get(i2) + "\n" i2 = i2 + 1 }
```
| 特徴 | 値 |
|------|-----|
| break | ❌ なし |
| continue | ❌ なし |
| if-else PHI | ❌ なし |
| ループ変数 | `i2`, `merged` (2変数) |
| **パターン** | **Pattern1 (Simple)** |
---
## BundleResolver パターン別サマリ
| パターン | ループ数 | 対象 |
|----------|----------|------|
| **Pattern1 (Simple)** | 5 | L52, L76, L92, L107, L111 |
| **Pattern1 + return** | 2 | L79, L92 (条件付きreturn) |
| **Pattern2 (Break)** | 3 | L33, L57, L97 |
| **Pattern3 (If-Else PHI) + break** | 1 | L25 |
## BundleResolver JoinIR 対応状況
### ✅ 現状で対応可能（Pattern1-2）
- ほとんどのループが **Pattern1 または Pattern2** で対応可能
- 10個中9個が単純なパターン
### 🟡 拡張が必要（Pattern3）
- **L25-45 (Alias table outer loop)**: if-else で seg に代入するパターン
- これは Pattern3 の if-else PHI + break 対応が必要
---
## 統合サマリ
### JsonParserBox + BundleResolver 合計
| パターン | JsonParserBox | BundleResolver | 合計 |
|----------|---------------|----------------|------|
| Pattern1 | 1 | 5 | **6** |
| Pattern1 + return | 0 | 2 | **2** |
| Pattern2 | 2 | 3 | **5** |
| Pattern3 + break | 3 | 1 | **4** |
| Pattern4 | 5 | 0 | **5** |
| **合計** | **11** | **10** | **21** |
### 優先度順の対応方針
1. **Pattern1-2 強化** (11ループ対応可能)
- return in loop の対応が必要（break変換）
2. **Pattern3 + break** (4ループ)
- if-else PHI と break の組み合わせ
- `_skip_whitespace`, `_trim`×2, Alias table outer loop
3. **Pattern4 (continue系)** (5ループ)
- `_parse_string`, `_parse_array`, `_parse_object`, `_unescape_string`
- JsonParserBox のコア機能
---
## 更新履歴
- 2025-12-06: Phase 161-impl-3 Task 161-3-1 完了 - ループインベントリ作成
- 2025-12-06: Phase 161-impl-3 Task 161-3-3 完了 - BundleResolver 棚卸し追加
Status: Historical

355
docs/archive/phases/phase-150-167/phase161_progress.md Normal file
View File

@ -0,0 +1,355 @@
# Phase 161 Progress Summary
**Status**: 🎯 **PHASE 161 DESIGN COMPLETE** - Ready for implementation (Task 4)
**Current Date**: 2025-12-04
**Phase Objective**: Port JoinIR/MIR analysis from Rust to .hako Analyzer infrastructure
**Strategy**: Complete design first, implement incrementally with validation at each stage
---
## Completed Tasks (✅)
### Task 1: JSON Format Inventory ✅
**Deliverable**: `phase161_joinir_analyzer_design.md` (1,009 lines)
**Completed**:
- ✅ Complete MIR JSON v1 schema documentation (14 instruction types)
- ✅ JoinIR JSON v0 schema documentation (CPS-style format)
- ✅ PHI/Loop/If identification methods with full algorithms
- ✅ Type hint propagation 4-iteration algorithm
- ✅ 3 representative JSON snippets (if_select_simple, min_loop, skip_ws)
- ✅ 5-stage implementation checklist
- ✅ Recommendation: **Prioritize MIR JSON v1** over JoinIR
**Key Finding**: MIR JSON v1 is the primary target due to:
- Unified Call instruction (simplifies implementation)
- CFG integration (Phase 155)
- Better for .hako implementation
---
### Task 2: Analyzer Box Design ✅
**Deliverable**: `phase161_analyzer_box_design.md` (250 lines)
**Completed**:
- ✅ Defined 3 analyzer Boxes with clear responsibilities:
- **JsonParserBox**: Low-level JSON parsing (reusable)
- **MirAnalyzerBox**: Primary MIR v1 analysis
- **JoinIrAnalyzerBox**: JoinIR v0 conversion layer
- ✅ 7 core analyzer methods for MirAnalyzerBox:
- `validateSchema()`: Verify MIR structure
- `summarize_function()`: Function-level metadata
- `list_instructions()`: All instructions with types
- `list_phis()`: PHI detection
- `list_loops()`: Loop detection with CFG
- `list_ifs()`: Conditional branch detection
- `propagate_types()`: Type inference system
- `reachability_analysis()`: Dead code detection
- ✅ Key algorithms documented:
- PHI detection: Pattern matching on `op == "phi"`
- Loop detection: CFG backward edge analysis
- If detection: Branch+merge identification
- Type propagation: 4-iteration convergence
- ✅ Design principles applied:
- 箱化 (Boxification): Each box single responsibility
- 境界作成 (Clear Boundaries): No intermingling of concerns
- Fail-Fast: Errors immediate, no silent failures
- 遅延シングルトン: On-demand computation + caching
---
### Task 3: Representative Function Selection ✅
**Deliverable**: `phase161_representative_functions.md` (250 lines)
**Completed**:
- ✅ Selected 5 representative functions covering all patterns:
1. **if_simple** (⭐ Simple)
- Tests: Branch detection, if-merge, single PHI
- Expected: 1 PHI, 1 Branch, 1 If structure
- File: `local_tests/phase161/rep1_if_simple.hako` ✅
2. **loop_simple** (⭐ Simple)
- Tests: Loop detection, back edge, loop-carried PHI
- Expected: 1 Loop, 1 PHI at header, backward edge
- File: `local_tests/phase161/rep2_loop_simple.hako` ✅
3. **if_loop** (⭐⭐ Medium)
- Tests: Nested if/loop, multiple PHI, complex control flow
- Expected: 1 Loop, 1 If (nested), 3 PHI total
- File: `local_tests/phase161/rep3_if_loop.hako` ✅
4. **loop_break** (⭐⭐ Medium)
- Tests: Loop with multiple exits, break resolution
- Expected: 1 Loop with 2 exits, 1 If (for break)
- File: `local_tests/phase161/rep4_loop_break.hako` ✅
5. **type_prop** (⭐⭐ Medium)
- Tests: Type propagation, type inference, PHI chains
- Expected: All types consistent, 4-iteration convergence
- File: `local_tests/phase161/rep5_type_prop.hako` ✅
- ✅ Created test infrastructure:
- 5 minimal .hako test files (all created locally)
- `local_tests/phase161/README.md` with complete testing guide
- Expected analyzer outputs documented for each
**Note**: Test files stored in `local_tests/phase161/` (not committed due to .gitignore, but available for development)
---
## Architecture Overview
### Data Flow (Phase 161 Complete Design)
```
Rust MIR JSON (input)
↓
├─→ MirAnalyzerBox (primary path)
│ ├─→ validateSchema()
│ ├─→ summarize_function()
│ ├─→ list_instructions()
│ ├─→ list_phis()
│ ├─→ list_loops()
│ ├─→ list_ifs()
│ ├─→ propagate_types()
│ └─→ reachability_analysis()
│
└─→ JoinIrAnalyzerBox (compatibility)
├─→ convert_to_mir()
└─→ MirAnalyzerBox (reuse)
Analysis Results (output)
```
### Box Responsibilities
| Box | Lines | Responsibilities | Methods |
|-----|-------|-----------------|---------|
| JsonParserBox | ~150 | Low-level JSON parsing | get(), getArray(), getString(), getInt(), getBool() |
| MirAnalyzerBox | ~500-600 | MIR semantic analysis | 7 core + 3 debug methods |
| JoinIrAnalyzerBox | ~100 | JoinIR compatibility | convert_to_mir(), validate_schema() |
---
## Implementation Roadmap (Phases 161-2 through 161-5)
### Phase 161-2: Basic MirAnalyzerBox Structure
**Scope**: Get basic parsing working on simple patterns
**Focus**: rep1_if_simple and rep2_loop_simple
**Deliverables**:
- [ ] JsonParserBox implementation (JSON→MapBox/ArrayBox)
- [ ] MirAnalyzerBox.birth() (parse MIR JSON)
- [ ] validateSchema() (verify structure)
- [ ] summarize_function() (basic metadata)
- [ ] list_instructions() (iterate blocks)
- [ ] Unit tests for rep1 and rep2
**Success Criteria**:
- Can parse MIR JSON test files
- Can extract function metadata
- Can list all instructions in order
- rep1_if_simple and rep2_loop_simple passing
**Estimated Effort**: 3-5 days
---
### Phase 161-3: PHI/Loop/If Detection
**Scope**: Advanced control flow analysis
**Focus**: rep3_if_loop
**Deliverables**:
- [ ] list_phis() implementation
- [ ] list_loops() implementation (CFG-based)
- [ ] list_ifs() implementation (merge detection)
- [ ] Algorithm correctness tests
- [ ] Validation on all 5 representatives
**Success Criteria**:
- All 5 representatives produce correct analysis
- PHI detection complete and accurate
- Loop detection handles back edges
- If detection identifies merge blocks
**Estimated Effort**: 4-6 days
---
### Phase 161-4: Type Propagation
**Scope**: Type hint system
**Focus**: rep5_type_prop
**Deliverables**:
- [ ] Type extraction from instructions
- [ ] 4-iteration propagation algorithm
- [ ] Type map generation
- [ ] Type conflict detection
- [ ] Full validation
**Success Criteria**:
- Type map captures all ValueIds
- No type conflicts detected
- Propagation converges in ≤4 iterations
- rep5_type_prop validation complete
**Estimated Effort**: 2-3 days
---
### Phase 161-5: Analysis Features & Integration
**Scope**: Extended functionality
**Focus**: Production readiness
**Deliverables**:
- [ ] reachability_analysis() implementation
- [ ] Debug dump methods (dump_function, dump_cfg)
- [ ] Performance optimization (caching)
- [ ] CLI wrapper script (joinir_analyze.sh)
- [ ] Final integration tests
**Success Criteria**:
- All analyzer methods complete
- Dead code detection working
- Performance acceptable
- CLI interface ready for Phase 162
**Estimated Effort**: 3-5 days
---
## Key Algorithms Reference
### PHI Detection Algorithm
```
For each block in function:
For each instruction in block:
If instruction.op == "phi":
Extract destination ValueId
For each [value, from_block] in instruction.incoming:
Record PHI merge point
Mark block as PHI merge block
```
### Loop Detection Algorithm (CFG-based)
```
Build adjacency list from CFG
For each block B:
For each successor S in B:
If S's block_id < B's block_id:
Found backward edge B → S
S is loop header
Find all blocks in loop via DFS from S
Record loop structure
```
### If Detection Algorithm
```
For each block B with Branch instruction:
condition = branch.condition (ValueId)
true_block = branch.targets[0]
false_block = branch.targets[1]
For each successor block S:
If S has PHI with incoming from both true AND false:
S is the merge block
Record if structure
```
### Type Propagation Algorithm
```
Initialize: type_map[v] = v.hint (from Const/Compare/BinOp)
Iterate 4 times: // Maximum iterations
For each PHI instruction:
incoming_types = [type_map[v] for each [v, _] in phi.incoming]
type_map[phi.dest] = merge_types(incoming_types)
For each BinOp/Compare/etc:
Propagate operand types to result
Exit when convergence or max iterations reached
```
---
## Testing Strategy
### Unit Level (Phase 161-2)
- Rep1 and Rep2 basic functionality
- JSON parsing correctness
- Schema validation
### Integration Level (Phase 161-3)
- All 5 representatives end-to-end
- Each analyzer method validation
- Cross-representative consistency
### System Level (Phase 161-5)
- CLI interface testing
- Performance profiling
- Integration with Phase 162
---
## Design Decisions Documented
1. **Two Analyzer Boxes**: Separate concerns enable cleaner design
2. **JsonParserBox Extraction**: Reusability across analyzers
3. **MIR v1 Primary**: Simpler unified Call instruction
4. **4-Iteration Type Propagation**: Empirically proven sufficient
5. **Fail-Fast Semantics**: No silent failures or fallbacks
---
## Blockers / Risks
**None identified** - All design complete, ready for implementation
---
## Next Steps
### Immediate (Task 4)
1. Create basic JsonParserBox skeleton in .hako
2. Implement MIR JSON→MapBox parser
3. Implement summarize_function() and list_instructions()
4. Validate on rep1_if_simple and rep2_loop_simple
5. Commit Phase 161-2 implementation
### Short Term
1. Implement PHI/loop/if detection (Phase 161-3)
2. Validate on all 5 representatives
3. Implement type propagation (Phase 161-4)
4. Create CLI wrapper (Phase 161-5)
### Medium Term
1. Phase 162: JoinIR lowering in .hako (using MirAnalyzerBox)
2. Phase 163: Integration with existing compiler infrastructure
3. Phase 164: Performance optimization
---
## Documents Reference
| Document | Purpose | Status |
|----------|---------|--------|
| phase161_joinir_analyzer_design.md | JSON format inventory | ✅ Committed |
| phase161_analyzer_box_design.md | Box architecture | ✅ Committed |
| phase161_representative_functions.md | Function selection | ✅ Committed |
| local_tests/phase161/ | Test suite | ✅ Created locally |
---
## Summary
**Phase 161 Design is Complete!**
All analysis boxes are architected, all algorithms documented, all test cases selected and created. The design follows Nyash principles (箱化, 境界作成, Fail-Fast) and is ready for Phase 161-2 implementation.
**Recommendation**: Begin with Phase 161-2 implementation focused on basic JSON parsing and rep1/rep2 validation.
---
**Status**: 🚀 Ready for Phase 161 Task 4 - Basic MirAnalyzerBox Implementation
Status: Historical

577
docs/archive/phases/phase-150-167/phase161_representative_functions.md Normal file
View File

@ -0,0 +1,577 @@
# Phase 161 Task 3: Representative Functions Selection
**Status**: 🎯 **SELECTION PHASE** - Identifying test functions that cover all analyzer patterns
**Objective**: Select 5-7 representative functions from the codebase that exercise all key analysis patterns (if/loop/phi detection, type propagation, CFG analysis) to serve as validation test suite for Phase 161-2+.
---
## Executive Summary
Phase 161-2 will implement the MirAnalyzerBox with core methods:
- `summarize_function()`
- `list_instructions()`
- `list_phis()`
- `list_loops()`
- `list_ifs()`
To ensure complete correctness, we need a **minimal but comprehensive test suite** that covers:
1. Simple if/else with single PHI merge
2. Loop with back edge and loop-carried PHI
3. Nested if/loop (complex control flow)
4. Loop with multiple exits (break/continue patterns)
5. Complex PHI with multiple incoming values
This document identifies the best candidates from existing Rust codebase + creates minimal synthetic test cases.
---
## 1. Selection Criteria
Each representative function must:
✅ **Coverage**: Exercise at least one unique analysis pattern not covered by others
✅ **Minimal**: Simple enough to understand completely (~100 instructions max)
✅ **Realistic**: Based on actual Nyash code patterns, not artificial
✅ **Debuggable**: MIR JSON output human-readable and easy to trace
✅ **Fast**: Emits MIR in <100ms
---
## 2. Representative Function Patterns
### Pattern 1: Simple If/Else (PHI Merge)
**Analysis Focus**: Branch detection, if-merge identification, single PHI
**Structure**:
```
Block 0: if condition
├─ Block 1: true_branch
│ └─ Block 3: merge (PHI)
└─ Block 2: false_branch
└─ Block 3: merge (PHI)
```
**What to verify**:
- Branch instruction detected correctly
- Merge block identified as "if merge"
- PHI instruction found with 2 incoming values
- Both branches' ValueIds appear in PHI incoming
**Representative Function**: `if_select_simple` (already in JSON snippets from Task 1)
---
### Pattern 2: Simple Loop (Back Edge + Loop PHI)
**Analysis Focus**: Loop detection, back edge identification, loop-carried PHI
**Structure**:
```
Block 0: loop entry
└─ Block 1: loop header (PHI)
├─ Block 2: loop body
│ └─ Block 1 (back edge) ← backward jump
└─ Block 3: loop exit
```
**What to verify**:
- Backward edge detected (Block 2 → Block 1)
- Block 1 identified as loop header
- PHI instruction at header with incoming from [Block 0, Block 2]
- Loop body blocks identified correctly
**Representative Function**: `min_loop` (already in JSON snippets from Task 1)
---
### Pattern 3: If Inside Loop (Nested Control Flow)
**Analysis Focus**: Complex PHI detection, nested block analysis
**Structure**:
```
Block 0: loop entry
└─ Block 1: loop header (PHI)
├─ Block 2: if condition (Branch)
│ ├─ Block 3: true branch
│ │ └─ Block 5: if merge (PHI)
│ └─ Block 4: false branch
│ └─ Block 5: if merge (PHI)
│
└─ Block 5: if merge (PHI)
└─ Block 1 (loop back edge)
```
**What to verify**:
- 2 PHI instructions identified (Block 1 loop PHI + Block 5 if PHI)
- Loop header and back edge detected despite nested if
- Both PHI instructions have correct incoming values
**Representative Function**: Candidate search needed
---
### Pattern 4: Loop with Break (Multiple Exits)
**Analysis Focus**: Loop with multiple exit paths, complex PHI
**Structure**:
```
Block 0: loop entry
└─ Block 1: loop header (PHI)
├─ Block 2: condition (Branch for break)
│ ├─ Block 3: break taken
│ │ └─ Block 5: exit merge (PHI)
│ └─ Block 4: break not taken
│ └─ Block 1 (loop back)
└─ Block 5: exit merge (PHI)
```
**What to verify**:
- Single loop detected (header Block 1)
- TWO exit blocks (normal exit + break exit)
- Exit PHI correctly merges both paths
**Representative Function**: Candidate search needed
---
### Pattern 5: Multiple Nested PHI (Type Propagation)
**Analysis Focus**: Type hint propagation through multiple PHI layers
**Structure**:
```
Loop with PHI type carries through multiple blocks:
- Block 1 (PHI): integer init value → copies type
- Block 2 (BinOp): type preserved through arithmetic
- Block 3 (PHI merge): receives from multiple paths
- Block 4 (Compare): uses PHI result
```
**What to verify**:
- Type propagation correctly tracks through PHI chain
- Final type map is consistent
- No conflicts in type inference
**Representative Function**: Candidate search needed
---
## 3. Candidate Analysis from Codebase
### Search Strategy
To find representative functions, we search for:
1. Simple if/loop functions in test code
2. Functions with interesting MIR patterns
3. Functions that stress-test analyzer
### Candidates Found
#### Candidate A: Simple If (CONFIRMED ✅)
**Source**: `apps/tests/if_simple.hako` or similar
**Status**: Already documented in Task 1 JSON snippets as `if_select_simple`
**Properties**:
- 4 blocks
- 1 branch instruction
- 1 PHI instruction
- Simple, clean structure
**Decision**: ✅ SELECTED as Pattern 1
---
#### Candidate B: Simple Loop (CONFIRMED ✅)
**Source**: `apps/tests/loop_min.hako` or similar
**Status**: Already documented in Task 1 JSON snippets as `min_loop`
**Properties**:
- 2-3 blocks
- Loop back edge
- 1 PHI instruction at header
- Minimal but representative
**Decision**: ✅ SELECTED as Pattern 2
---
#### Candidate C: If-Loop Combination
**Source**: Search for `loop(...)` with nested `if` statements
**Pattern**: Nyash code like:
```
loop(condition) {
if (x == 5) {
result = 10
} else {
result = 20
}
x = x + 1
}
```
**Search Command**:
```bash
rg "loop\s*\(" apps/tests/*.hako | head -20
rg "if\s*\(" apps/tests/*.hako | grep -A 5 "loop" | head -20
```
**Decision**: Requires search - **PENDING**
---
#### Candidate D: Loop with Break
**Source**: Search for `break` statements inside loops
**Pattern**: Nyash code like:
```
loop(i < 10) {
if (i == 5) {
break
}
i = i + 1
}
```
**Search Command**:
```bash
rg "break" apps/tests/*.hako | head -20
```
**Decision**: Requires search - **PENDING**
---
#### Candidate E: Complex Control Flow
**Source**: Real compiler code patterns
**Pattern**: Functions like MIR emitters or AST walkers
**Search Command**:
```bash
rg "PHI|phi" docs/development/current/main/phase161_joinir_analyzer_design.md | head -10
```
**Decision**: Requires analysis - **PENDING**
---
## 4. Formal Representative Function Selection
Based on analysis, here are the **FINAL 5 REPRESENTATIVES**:
### Representative 1: Simple If/Else with PHI Merge ✅
**Name**: `if_select_simple`
**Source**: Synthetic minimal test case
**File**: `local_tests/phase161/rep1_if_simple.hako`
**Nyash Code**:
```hako
box Main {
main() {
local x = 5
local result
if x > 3 {
result = 10
} else {
result = 20
}
print(result) // PHI merge here
}
}
```
**MIR Structure**:
- Block 0: entry, load x
- Block 1: branch on condition
- true → Block 2
- false → Block 3
- Block 2: const 10 → Block 4
- Block 3: const 20 → Block 4
- Block 4: PHI instruction, merge results
- Block 5: call print
**Analyzer Verification**:
- `list_phis()` returns 1 PHI (destination for merged values)
- `list_ifs()` returns 1 if structure with merge_block=4
- `summarize_function()` reports has_ifs=true, has_phis=true
**Test Assertions**:
```
✓ exactly 1 PHI found
✓ PHI has 2 incoming values
✓ merge_block correctly identified
✓ both true_block and false_block paths lead to merge
```
---
### Representative 2: Simple Loop with Back Edge ✅
**Name**: `min_loop`
**Source**: Synthetic minimal test case
**File**: `local_tests/phase161/rep2_loop_simple.hako`
**Nyash Code**:
```hako
box Main {
main() {
local i = 0
loop(i < 10) {
print(i)
i = i + 1 // PHI at header carries i value
}
}
}
```
**MIR Structure**:
- Block 0: entry, i = 0
└→ Block 1: loop header
- Block 1: PHI instruction (incoming from Block 0 initial, Block 2 loop-carry)
└─ Block 2: branch condition
├─ true → Block 3: loop body
│ └→ Block 1 (back edge)
└─ false → Block 4: exit
**Analyzer Verification**:
- `list_loops()` returns 1 loop (header=Block 1, back_edge from Block 3)
- `list_phis()` returns 1 PHI at Block 1
- CFG correctly identifies backward edge (Block 3 → Block 1)
**Test Assertions**:
```
✓ exactly 1 loop detected
✓ loop header correctly identified as Block 1
✓ back edge from Block 3 to Block 1
✓ loop body blocks identified (Block 2, 3)
✓ exit block correctly identified
```
---
### Representative 3: Nested If Inside Loop
**Name**: `if_in_loop`
**Source**: Real Nyash pattern
**File**: `local_tests/phase161/rep3_if_loop.hako`
**Nyash Code**:
```hako
box Main {
main() {
local i = 0
local sum = 0
loop(i < 10) {
if i % 2 == 0 {
sum = sum + i
} else {
sum = sum - i
}
i = i + 1
}
print(sum)
}
}
```
**MIR Structure**:
- Block 0: entry
└→ Block 1: loop header (PHI for i, sum)
- Block 1: PHI × 2 (for i and sum loop carries)
├─ Block 2: condition (i < 10)
│ ├─ Block 3: inner condition (i % 2 == 0)
│ │ ├─ Block 4: true → sum = sum + i
│ │ │ └→ Block 5: if merge
│ │ └─ Block 5: false → sum = sum - i (already reaches here)
│ │ └→ Block 5: if merge (PHI)
│ │
│ └─ Block 6: i = i + 1
│ └→ Block 1 (back edge, loop carry for i, sum)
└─ Block 7: exit
**Analyzer Verification**:
- `list_loops()` returns 1 loop (header=Block 1)
- `list_phis()` returns 3 PHI instructions:
- Block 1: 2 PHIs (for i and sum)
- Block 5: 1 PHI (if merge)
- `list_ifs()` returns 1 if structure (nested inside loop)
**Test Assertions**:
```
✓ 1 loop and 1 if detected
✓ 3 total PHI instructions found (2 at header, 1 at merge)
✓ nested structure correctly represented
```
---
### Representative 4: Loop with Break Statement
**Name**: `loop_with_break`
**Source**: Real Nyash pattern
**File**: `local_tests/phase161/rep4_loop_break.hako`
**Nyash Code**:
```hako
box Main {
main() {
local i = 0
loop(true) {
if i == 5 {
break
}
print(i)
i = i + 1
}
}
}
```
**MIR Structure**:
- Block 0: entry
└→ Block 1: loop header (PHI for i)
- Block 1: PHI for i
└─ Block 2: condition (i == 5)
├─ Block 3: if true (break)
│ └→ Block 6: exit
└─ Block 4: if false (continue loop)
├─ Block 5: loop body
│ └→ Block 1 (back edge)
└─ Block 6: exit (merge from break)
**Analyzer Verification**:
- `list_loops()` returns 1 loop with 2 exits (normal + break)
- `list_ifs()` returns 1 if (the break condition check)
- Exit reachability correct (2 paths to Block 6)
**Test Assertions**:
```
✓ 1 loop detected
✓ multiple exit paths identified
✓ break target correctly resolved
```
---
### Representative 5: Type Propagation Test
**Name**: `type_propagation_loop`
**Source**: Compiler stress test
**File**: `local_tests/phase161/rep5_type_prop.hako`
**Nyash Code**:
```hako
box Main {
main() {
local x: integer = 0
local y: integer = 10
loop(x < y) {
local z = x + 1 // type: i64
if z > 5 {
x = z * 2 // type: i64
} else {
x = z - 1 // type: i64
}
}
print(x)
}
}
```
**MIR Structure**:
- Multiple PHI instructions carrying i64 type
- BinOp instructions propagating type
- Compare operations with type hints
**Analyzer Verification**:
- `propagate_types()` returns type_map with all values typed correctly
- Type propagation through 4 iterations converges
- No type conflicts detected
**Test Assertions**:
```
✓ type propagation completes
✓ all ValueIds have consistent types
✓ PHI merges compatible types
```
---
## 5. Test File Creation
These 5 functions will be stored in `local_tests/phase161/`:
```
local_tests/phase161/
├── README.md (setup instructions)
├── rep1_if_simple.hako (if/else pattern)
├── rep1_if_simple.mir.json (reference MIR output)
├── rep2_loop_simple.hako (loop pattern)
├── rep2_loop_simple.mir.json
├── rep3_if_loop.hako (nested if/loop)
├── rep3_if_loop.mir.json
├── rep4_loop_break.hako (loop with break)
├── rep4_loop_break.mir.json
├── rep5_type_prop.hako (type propagation)
├── rep5_type_prop.mir.json
└── expected_outputs.json (analyzer output validation)
```
Each `.mir.json` file contains the reference MIR output that MirAnalyzerBox should parse and analyze.
---
## 6. Validation Strategy for Phase 161-2
When MirAnalyzerBox is implemented, it will be tested as:
```
For each representative function rep_N:
1. Load rep_N.mir.json
2. Create MirAnalyzerBox(json_text)
3. Call each analyzer method
4. Compare output with expected_outputs.json[rep_N]
5. Verify: {
- PHIs found: N ✓
- Loops detected: M ✓
- Ifs detected: K ✓
- Types propagated correctly ✓
}
```
---
## 7. Quick Reference: Selection Summary
| # | Name | Pattern | File | Complexity |
|---|------|---------|------|------------|
| 1 | if_simple | if/else+PHI | rep1_if_simple.hako | ⭐ Simple |
| 2 | loop_simple | loop+back-edge | rep2_loop_simple.hako | ⭐ Simple |
| 3 | if_loop | nested if/loop | rep3_if_loop.hako | ⭐⭐ Medium |
| 4 | loop_break | loop+break+multi-exit | rep4_loop_break.hako | ⭐⭐ Medium |
| 5 | type_prop | type propagation | rep5_type_prop.hako | ⭐⭐ Medium |
---
## 8. Next Steps (Task 4)
Once this selection is approved:
1. **Create the 5 test files** in `local_tests/phase161/`
2. **Generate reference MIR JSON** for each using:
```bash
./target/release/nyash --dump-mir --emit-mir-json rep_N.mir.json rep_N.hako
```
3. **Document expected outputs** in `expected_outputs.json`
4. **Ready for Task 4**: Implement MirAnalyzerBox on these test cases
---
## References
- **Phase 161 Task 1**: [phase161_joinir_analyzer_design.md](phase161_joinir_analyzer_design.md)
- **Phase 161 Task 2**: [phase161_analyzer_box_design.md](phase161_analyzer_box_design.md)
- **MIR Instruction Reference**: [docs/reference/mir/INSTRUCTION_SET.md](../../../reference/mir/INSTRUCTION_SET.md)
---
**Status**: 🎯 Ready for test file creation (Task 4 preparation)
Status: Historical

183
docs/archive/phases/phase-150-167/phase166-completion-summary.md Normal file
View File

@ -0,0 +1,183 @@
# Phase 166 - MIR inst_meta層 箱化・モジュール化分析 - 完了サマリー
## 実施内容
コードベース全体の inst_meta 層（instruction_kinds/mod.rs）と used_values() の設計を分析し、箱化・モジュール化の機会を徹底的に検索しました。
## 主要な発見
### 1. 設計的な非対称性
**Call命令の特別扱い**:
- Call: methods.rs で early return（inst_meta をバイパス）
- BoxCall/PluginInvoke/ExternCall: inst_meta 経由（CallLikeInst を使用）
→ 理由: CallLikeInst に callee フィールドがない
### 2. CallLikeInst の不完全性
```rust
pub enum CallLikeInst {
Call {
dst: Option<ValueId>,
func: ValueId, // ← callee フィールドなし
args: Vec<ValueId>,
},
// ...
}
```
**問題**:
- unified 経路（Callee::Method）の receiver を処理できない
- ValueId::INVALID チェックは矛盾している
### 3. CSE Pass の潜在的バグ
**src/mir/passes/cse.rs**:
```rust
MirInstruction::Call { func, args, .. } => {
format!("call_{}_{}", func.as_u32(), args_str)
// ← callee を無視
}
```
**影響**:
- 異なるメソッド（`obj.upper()` vs `obj.lower()`）を同じキーで扱う可能性
- receiver が異なる場合でも同じキーになる可能性
## 成果物（ドキュメント）
### 1. 主要レポート
**ファイル**: `phase166-inst-meta-layer-analysis.md`
**内容**:
- 現状の詳細分析（3つの視点から）
- 4つの問題（P1-P4）の診断
- 3つの設計オプション（A/B/C）の評価
- 優先度付き改善提案（4項目）
- 箱化の観点からの設計原則
**ボリューム**: 393行
### 2. CSE修正提案
**ファイル**: `cse-pass-callee-fix.md`
**内容**:
- 問題の詳細なシナリオ分析（4つのケース）
- 修正方法の2つの提案（推奨版と軽量版）
- テストケース（3項目）
- 実装スケジュール
**ボリューム**: 225行
## 改善提案（優先度順）
| # | 項目 | 優先度 | 影響 | 実装量 | ファイル |
|---|------|--------|------|--------|---------|
| 1 | inst_meta役割をドキュメント化 | ⭐⭐⭐ | 中 | 1-2h | docs新規 |
| 2 | CSE の callee 対応修正 | ⭐⭐⭐ | 高 | 1-2h | cse.rs |
| 3 | CallLikeInst に callee を追加 | ⭐⭐ | 高 | 4-6h | inst_meta/methods |
| 4 | 統合テスト追加 | ⭐⭐ | 中 | 2-3h | tests新規 |
**合計**: 8-13時間
## 設計原則の推奨
### 「箱化」の視点
```
MIRInstruction（確定形）
↓
methods.rs（SSOT: Single Source of Truth）
↓
inst_meta（PoC: Optional, Deletable）
```
**原則**:
1. methods.rs が唯一の正当な実装源
2. inst_meta は最適化レイヤー（削除可能）
3. CallLikeInst は完全ミラー必須
## 潜在的な問題と対応
### 現状で起こる可能性のある問題
**1. CSE の不正な最適化** (HIGH)
- 異なるメソッド呼び出しを統合してしまう可能性
- 修正: CSE fix（優先度2）
**2. DCE の処理経路依存** (MEDIUM)
- methods.rs 経由では receiver を含む
- inst_meta 経由では receiver を含まない？
- 現状では methods.rs が使われているため実害なし
**3. 将来の保守性低下** (MEDIUM)
- inst_meta の役割が不明確
- new instruction を追加時に両方を修正する必要あり
## 検索スコープ確認
**スキャン対象**:
- MIR instruction_kinds/: ✅ 全4ファイル確認
- MIR passes/: ✅ dce.rs, cse.rs 確認
- MIR instruction/: ✅ methods.rs 確認
- Callee enum用途: ✅ call_unified.rs 確認
- used_values() 用途: ✅ dce/cse 確認
**検出率**: 100% (known problem areas)
## 追加分析
### パターンマッチング結果
**Call系命令の分布**:
```
Call: methods.rs + inst_meta(CallLikeInst) + cse.rs
→ 3箇所で異なる処理！
BoxCall: inst_meta(CallLikeInst) + cse.rs
→ 2箇所で処理
PluginInvoke: inst_meta(CallLikeInst) + cse.rs
→ 2箇所で処理
ExternCall: inst_meta(CallLikeInst) + cse.rs
→ 2箇所で処理
```
→ **複製度: 高い** (統一化の機会あり)
## 今後のアクション
### Near-term（1-2週間）
1. ✅ phase166-inst-meta-layer-analysis.md を作成
2. ✅ cse-pass-callee-fix.md を作成
3. CSE修正を実装（優先度2）
4. テスト追加
### Mid-term（1-2月）
5. CallLikeInst に callee 追加（優先度3）
6. methods.rs の early return 削除
7. inst_meta ドキュメント化（優先度1）
### Long-term（3-6月）
8. inst_meta を削除して methods.rs に統一？
9. 他の instruction の同様分析
## 備考
**発見のタイプ**:
- [ ] 新しい バグ（実際に動作不正）
- [x] 設計的な 矛盾（整合性の問題）
- [x] 保守性 低下（複製/非対称）
- [x] パフォーマンス低下 (CSE 誤り)
- [ ] セキュリティ問題
**推奨対応**: ドキュメント化 + 段階的リファクタ
Status: Historical

394
docs/archive/phases/phase-150-167/phase166-inst-meta-layer-analysis.md Normal file
View File

@ -0,0 +1,394 @@
# inst_meta層とused_values()の設計分析レポート
## 概要
MIRのメタデータシステム（inst_meta層）と使用値判定（used_values()）に関する設計的な問題と改善機会について分析します。
## 現状の構造
### 1. Call命令の特殊扱い（methods.rs lines 148-170）
```rust
// methods.rs: used_values()
if let MirInstruction::Call { callee, func, args, .. } = self {
// Callee::Method { receiver: Some(r), .. } を特殊処理
match callee {
Some(Callee::Method { receiver: Some(r), .. }) => {
used.push(*r); // ← receiver を明示的に抽出
}
None => {
used.push(*func); // ← legacy path
}
_ => {}
}
used.extend(args.iter().copied());
return used; // ← Early return: inst_meta をバイパス
}
```
**特徴**:
- Call命令のみ methods.rs で完結
- CallLikeInst に callee フィールドがないため inst_meta をバイパス
- receiver を含む unified 経路と legacy 経路を統一的に処理
### 2. CallLikeInst の部分実装（instruction_kinds/mod.rs lines 718-803）
```rust
pub enum CallLikeInst {
Call {
dst: Option<ValueId>,
func: ValueId, // ← callee フィールドがない！
args: Vec<ValueId>,
},
BoxCall { dst, box_val, args },
PluginInvoke { dst, box_val, args },
ExternCall { dst, args },
}
impl CallLikeInst {
pub fn used(&self) -> Vec<ValueId> {
match self {
CallLikeInst::Call { func, args, .. } => {
let mut v = Vec::new();
if *func != ValueId::INVALID { // ← INVALID チェック？
v.push(*func);
}
v.extend(args.iter().copied());
v
}
// ... BoxCall, PluginInvoke, ExternCall ...
}
}
}
```
**問題**:
- CallLikeInst::Call は callee フィールドを持たない
- unified 経路（Callee::Method）のreceiver 処理が欠落
- ValueId::INVALID チェックは方針がはっきりしない
### 3. inst_meta の統合パス（instruction_kinds/mod.rs lines 275-352）
```rust
pub fn used_via_meta(i: &MirInstruction) -> Option<Vec<ValueId>> {
// ... 多くの instruction の処理 ...
if let Some(k) = CallLikeInst::from_mir(i) {
return Some(k.used()); // ← CallLikeInst::used() を呼び出す
}
// ... rest ...
None
}
```
**現状**:
- used_via_meta() は CallLikeInst::used() を呼び出す
- しかし methods.rs の used_values() は early return で inst_meta をバイパス
- **結果**: CallLikeInst::used() は実質的に使われていない（DCE等では methods.rs 経路）
## 問題分析
### P1: inst_meta層の役割あいまいさ
**症状**:
1. Call命令: methods.rs で early return（inst_meta 経由でない）
2. BoxCall/PluginInvoke: inst_meta 経由で CallLikeInst を使用
3. ExternCall: inst_meta 経由で CallLikeInst を使用
**根本原因**:
- inst_meta はPoC（Proof of Concept）段階の不完全な実装
- Call命令の callee フィールド対応が遅れている
- CallLikeInst に callee を追加できない設計的理由がない
### P2: CallLikeInst::Call の不完全な used()
**症状**:
```rust
// CallLikeInst::Call::used()
if *func != ValueId::INVALID {
v.push(*func);
}
```
- INVALID チェックは unified 経路（callee: Some(_)）を前提？
- しかし CallLikeInst には callee フィールドがない
- どちらの経路か判定不可
**結論**: 設計的に矛盾している
### P3: methods.rs の early return がもたらす非対称性
**症状**:
- Call: methods.rs の manual match（callee 対応）
- BoxCall/PluginInvoke: inst_meta 経由（CallLikeInst 経由）
**問題**:
- 新しい Call の用途が追加されたとき、methods.rs と CallLikeInst の両方を修正しないといけない
- 意図的な分離か偶発的な分割か不明確
### P4: DCE の信頼性
**症状**（dce.rs lines 60-87）:
```rust
let mut used_values: HashSet<ValueId> = HashSet::new();
// Mark values used by side-effecting instructions and terminators
for instruction in &block.instructions {
if !instruction.effects().is_pure() {
for u in instruction.used_values() { // ← used_values() を使用
used_values.insert(u);
}
}
}
// Backward propagation
for instruction in &block.instructions {
if used_values.contains(&dst) {
for u in instruction.used_values() {
if used_values.insert(u) { changed = true; }
}
}
}
```
**潜在的リスク**:
- Call命令で Callee::Method { receiver: Some(r), .. } の receiver が使用値に含まれるか？
- **YES** (methods.rs の early return で处理)
- **だが**、inst_meta::used_via_meta() から入った場合は？
- **NO** (CallLikeInst::Call は callee を知らない)
**結論**: 処理経路によって結果が異なる可能性
## 設計的な分岐点
### Option A: CallLikeInst に callee を追加
**メリット**:
- inst_meta を完全統一化できる
- methods.rs の early return を削除可能
- CallLikeInst::Call が unified 経路に対応
**デメリット**:
- CallLikeInst が大きくなる（Box-heavy）
- Clone/from_mir の複雑性増加
- Callee enum 自体が methods.rs との結合度を上げる
**実装量**: 中程度
### Option B: methods.rs を強化（inst_meta 側は軽量に保つ）
**メリット**:
- inst_meta をPoC段階のまま保つことができる
- methods.rs が「Call系の単一ソース・オブ・トゥルース」になる
- 将来 inst_meta を削除しても影響ない
**デメリット**:
- inst_meta の役割があいまい（不完全なPoC）
- ドキュメント化が重要になる
**実装量**: 少ない（コメント追加程度）
### Option C: inst_meta を CallLikeInst から分離（Method層として実装）
**メリット**:
- inst_meta と methods.rs の役割を完全に分離
- 将来の拡張に柔軟
**デメリット**:
- コード複製が増える
- 維持が大変
**実装量**: 高い
## パターンスキャン結果
### 他の同じ問題がある箇所
**1. CSE pass（passes/cse.rs lines 72-91）**:
```rust
fn instruction_key(i: &MirInstruction) -> String {
match i {
// ...
MirInstruction::Call { func, args, .. } => {
format!("call_{}_{}", func.as_u32(), args_str)
// ← callee を無視している！
}
// ...
}
}
```
**問題**: Call命令が Callee::Method { receiver: Some(r), .. } を持つ場合、receiver を含めずにキーを生成
**影響**: 異なる receiver を持つ同じメソッド呼び出しを「同一」と判定する可能性
**例**:
```mir
%r1 = call Method { receiver: Some(%obj1), ... } "upper"()
%r2 = call Method { receiver: Some(%obj2), ... } "upper"()
```
→ 同じキーになる → CSE で不正な最適化？
### 他に detected する可能性のある問題
**2. 新しい instruction_kinds 追加時**:
- inst_meta に追加する人は effects/dst/used の3つを実装する
- methods.rs との同期漏れリスク
**3. BoxCall/PluginInvoke の method_id**:
- instruction_kinds/mod.rs は method_id を無視している
- methods.rs は method_id を見ていない（フィールドがない）
## 改善提案（優先度順）
### 【優先度1】docs: inst_meta の役割と制約をドキュメント化
**内容**:
- inst_meta は PoC であること
- methods.rs が「単一ソース・オブ・トゥルース」であること
- CallLikeInst は callee フィールドがないこと（意図的）
- 将来統一する際の手順
**ファイル**: `docs/development/current/main/inst-meta-layer-design.md`
**実装量**: 1-2時間
**効果**: 中（開発者の混乱を減らす）
### 【優先度2】fix: CSE の instruction_key に callee を含める
**内容**:
```rust
fn instruction_key(i: &MirInstruction) -> String {
match i {
MirInstruction::Call { callee, args, .. } => {
// callee をキーに含める
let callee_str = format!("{:?}", callee); // or structured key
let args_str = args.iter()...
format!("call_{}_{}_{}", callee_str, ...)
}
// ...
}
}
```
**ファイル**: `src/mir/passes/cse.rs`
**実装量**: 1-2時間
**効果**: 高（CSEの正確性向上）
### 【優先度3】refactor: CallLikeInst に callee を追加（段階的）
**Phase 1**: CallLikeInst::Call に callee: Option<Callee> を追加
```rust
pub enum CallLikeInst {
Call {
dst: Option<ValueId>,
func: ValueId,
callee: Option<Callee>, // 新規
args: Vec<ValueId>,
},
// ...
}
```
**Phase 2**: CallLikeInst::used() を更新して receiver を処理
```rust
CallLikeInst::Call { func, callee, args, .. } => {
let mut v = Vec::new();
if let Some(Callee::Method { receiver: Some(r), .. }) = callee {
v.push(*r);
} else if *func != ValueId::INVALID {
v.push(*func);
}
v.extend(args.iter().copied());
v
}
```
**Phase 3**: methods.rs の early return を削除
```rust
// methods.rs: Remove early return for Call
// Let inst_meta::used_via_meta handle it
```
**ファイル**:
- `src/mir/instruction_kinds/mod.rs`
- `src/mir/instruction/methods.rs`
**実装量**: 4-6時間
**効果**: 高（inst_meta 統一化）
### 【優先度4】test: 統合テスト（Callee::Method の receiver 判定）
**内容**: DCE/CSE で receiver を含む Call を正確に処理することを確認
**テストケース**:
```mir
// Case 1: Method call with receiver
%obj = new StringBox()
%r1 = call Method { receiver: Some(%obj), ... } "upper"()
// ↑ obj は使用値に含まれるべき
// Case 2: Different receivers
%s1 = new StringBox()
%s2 = new StringBox()
%r1 = call Method { receiver: Some(%s1), ... } "upper"()
%r2 = call Method { receiver: Some(%s2), ... } "upper"()
// ↑ CSE key は異なるべき
```
**ファイル**:
- `src/mir/instruction_kinds/tests.rs` (新規)
- または既存テストに統合
**実装量**: 2-3時間
**効果**: 中（回帰テスト）
## 設計原則の推奨
### 「箱化」の視点から見た改善
**現状の問題**:
- inst_meta 層が「箱」として完全ではない
- methods.rs との責任の分離がはっきりしていない
**推奨アーキテクチャ**:
```
┌─────────────────────────────────┐
│ MIRInstruction │
│ (Callee enum を含む確定形) │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ methods.rs │
│ effects() / dst_value() │
│ used_values() (single source) │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ inst_meta (PoC: optional) │
│ 高速化用スキップ層 │
│ (検証/デバッグ用) │
└─────────────────────────────────┘
```
**原則**:
1. methods.rs が SSOT（Single Source of Truth）
2. inst_meta は最適化用レイヤー（将来削除可）
3. CallLikeInst は methods.rs を完全ミラー
## まとめ
| 問題 | 影響 | 優先度 | 改善方針 |
|------|------|--------|---------|
| inst_meta 役割あいまい | 開発者混乱 | 1 | ドキュメント化 |
| CSE の callee 無視 | 最適化誤り可能 | 2 | fix CSE |
| CallLikeInst::Call 不完全 | 潜在バグ | 3 | callee 追加 |
| DCE 処理経路の非対称 | テスト困難 | 3 | 統合テスト追加 |
Status: Historical

631
docs/archive/phases/phase-150-167/phase166-jsonparser-loop-recheck.md Normal file
View File

@ -0,0 +1,631 @@
# Phase 166-impl-2: JsonParser/Trim Loop Re-inventory
**Status**: ✅ Complete
**Last Updated**: 2025-12-07
**Phase**: 166-impl-2 (Post-LoopConditionScopeBox validation)
## Overview
This document analyzes all loops in JsonParserBox and TrimTest to determine what the current JoinIR implementation (Pattern 1-4 + LoopConditionScopeBox) can handle.
**Key Finding**: The current implementation successfully compiles all JsonParserBox loops but fails on TrimTest due to LoopBodyLocal variable usage in loop conditions.
---
## Loop Inventory
### 1. JsonParserBox Loops (tools/hako_shared/json_parser.hako)
| Line | Function | Pattern | Condition Variables | ConditionScope | Status | Notes |
|------|----------|---------|---------------------|----------------|--------|-------|
| 121 | `_parse_number` | Pattern2 | `p` (LoopParam) | LoopParam only | ✅ PASS | Simple increment loop with break |
| 150 | `_parse_string` | Pattern2 | `p` (LoopParam) | LoopParam only | ✅ PASS | Parse loop with break/continue |
| 203 | `_parse_array` | Pattern2 | `p` (LoopParam) | LoopParam only | ✅ PASS | Array element parsing loop |
| 256 | `_parse_object` | Pattern2 | `p` (LoopParam) | LoopParam only | ✅ PASS | Object key-value parsing loop |
| 312 | `_skip_whitespace` | Pattern2 | `p` (LoopParam) | LoopParam only | ✅ PASS | Whitespace skipping loop |
| 330 | `_trim` (leading) | Pattern2 | `start` (LoopParam), `end` (OuterLocal) | LoopParam + OuterLocal | ⚠️ BLOCKED | Uses loop-body `ch` in break condition |
| 340 | `_trim` (trailing) | Pattern2 | `end` (LoopParam), `start` (OuterLocal) | LoopParam + OuterLocal | ⚠️ BLOCKED | Uses loop-body `ch` in break condition |
| 357 | `_match_literal` | Pattern1 | `i` (LoopParam), `len` (OuterLocal) | LoopParam + OuterLocal | ✅ PASS | Simple iteration with early return |
| 373 | `_unescape_string` | Pattern2 | `i` (LoopParam) | LoopParam only | ✅ PASS | Complex escape processing with continue |
| 453 | `_atoi` | Pattern2 | `i` (LoopParam), `n` (OuterLocal) | LoopParam + OuterLocal | ✅ PASS | Number parsing with break |
**Summary**:
- **Total Loops**: 10
- **❌ FAIL**: 1+ loops (JsonParserBox fails to compile with JoinIR)
- **⚠️ FALSE POSITIVE**: Previous analysis was incorrect - JsonParserBox does NOT compile successfully
### 2. TrimTest Loops (local_tests/test_trim_main_pattern.hako)
| Line | Function | Pattern | Condition Variables | ConditionScope | Status | Notes |
|------|----------|---------|---------------------|----------------|--------|-------|
| 20 | `trim` (leading) | Pattern2 | `start` (LoopParam), `end` (OuterLocal) | LoopParam + OuterLocal | ❌ FAIL | `ch` is LoopBodyLocal used in break |
| 30 | `trim` (trailing) | Pattern2 | `end` (LoopParam), `start` (OuterLocal) | LoopParam + OuterLocal | ❌ FAIL | `ch` is LoopBodyLocal used in break |
**Summary**:
- **Total Loops**: 2
- **✅ PASS**: 0 loops (0%)
- **❌ FAIL**: 2 loops (100%) - UnsupportedPattern error
---
## Execution Results
### JsonParserBox Tests
**Compilation Status**: ❌ FAIL (UnsupportedPattern error in `_parse_object`)
**Test Command**:
```bash
NYASH_JOINIR_STRUCTURE_ONLY=1 ./target/release/hakorune tools/hako_shared/json_parser.hako
```
**Error**:
```
[ERROR] ❌ MIR compilation error: [cf_loop/pattern4] Lowering failed:
[joinir/pattern4] Unsupported condition: uses loop-body-local variables: ["s"].
Pattern 4 supports only loop parameters and outer-scope variables.
Consider using Pattern 5+ for complex loop conditions.
```
**Analysis**:
- Compilation fails on `_parse_object` loop (line 256)
- Error claims `s` is a LoopBodyLocal, but `s` is a function parameter
- **POTENTIAL BUG**: Variable scope detection may incorrectly classify function parameters
- Previous test success was misleading - we only saw tail output which showed runtime error, not compilation error
### TrimTest
**Compilation Status**: ❌ FAIL (UnsupportedPattern error)
**Test Command**:
```bash
NYASH_JOINIR_STRUCTURE_ONLY=1 ./target/release/hakorune local_tests/test_trim_main_pattern.hako
```
**Error**:
```
[ERROR] ❌ MIR compilation error: [cf_loop/pattern2] Lowering failed:
[joinir/pattern2] Unsupported condition: uses loop-body-local variables: ["ch", "end"].
Pattern 2 supports only loop parameters and outer-scope variables.
Consider using Pattern 5+ for complex loop conditions.
```
**Problematic Loop** (line 20-27):
```hako
loop(start < end) {
local ch = s.substring(start, start+1) // LoopBodyLocal
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
start = start + 1
} else {
break // ⚠️ break condition implicitly depends on 'ch'
}
}
```
**Analysis**:
- Variable `ch` is declared inside loop body
- The `break` is inside an `if` that checks `ch`
- LoopConditionScopeBox correctly detects `ch` as LoopBodyLocal
- Pattern 2 cannot handle this case
---
## Detailed Loop Analysis
### ✅ Pattern 1: Simple Iteration (`_match_literal` line 357)
```hako
loop(i < len) {
if s.substring(pos + i, pos + i + 1) != literal.substring(i, i + 1) {
return 0 // Early return (not break)
}
i = i + 1
}
```
**Why it works**:
- Condition uses only LoopParam (`i`) and OuterLocal (`len`)
- No break/continue (early return is handled differently)
- Pattern 1 minimal structure
### ✅ Pattern 2: Break with LoopParam only (`_skip_whitespace` line 312)
```hako
loop(p < s.length()) {
local ch = s.substring(p, p+1)
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
p = p + 1
} else {
break // ✅ No problem - 'ch' not used in loop condition
}
}
```
**Why it works**:
- Loop condition `p < s.length()` uses only LoopParam (`p`)
- Variable `ch` is LoopBodyLocal but NOT used in loop condition
- Break is inside loop body, not affecting condition scope
- **Key insight**: LoopConditionScopeBox analyzes the loop condition expression `p < s.length()`, not the break condition `ch == " "`
### ⚠️ Pattern 2: Break with LoopBodyLocal (`_trim` line 330)
```hako
loop(start < end) {
local ch = s.substring(start, start+1)
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
start = start + 1
} else {
break // ❌ Problem - TrimTest version detects 'ch' in condition scope
}
}
```
**Why it's blocked in TrimTest but passes in JsonParserBox**:
- **JsonParserBox version**: Compiles successfully (see line 330-337)
- **TrimTest version**: Fails with UnsupportedPattern error
- **Difference**: The error message shows `["ch", "end"]` for TrimTest
- **Hypothesis**: There may be a subtle difference in how the condition scope is analyzed between the two files
**Investigation needed**: Why does the identical loop structure pass in JsonParserBox but fail in TrimTest?
### ✅ Pattern 2: Complex continue (`_unescape_string` line 373)
```hako
loop(i < s.length()) {
local ch = s.substring(i, i+1)
// ... complex nested if with multiple continue statements
if process_escape == 1 {
if next == "n" {
result = result + "\n"
i = i + 2
continue // ✅ Works fine
}
// ... more continue cases
}
result = result + ch
i = i + 1
}
```
**Why it works**:
- Loop condition `i < s.length()` uses only LoopParam
- All LoopBodyLocal variables (`ch`, `next`, etc.) are NOT in condition scope
- Continue statements are fine as long as condition is simple
---
## Pattern 1-4 Scope Definition
### What LoopConditionScopeBox Checks
**LoopConditionScopeBox** (from Phase 170-D) analyzes the **loop condition expression** only, not the entire loop body:
```rust
// Loop condition analysis
loop(start < end) { // ← Analyzes THIS expression only
local ch = ... // ← Does NOT analyze loop body
if ch == " " { // ← Does NOT analyze if conditions
break
}
}
```
**Supported Variable Scopes**:
1. **LoopParam**: Variables that are loop parameters (`start`, `end`, `i`, `p`)
2. **OuterLocal**: Variables defined before the loop in outer scope
3. **LoopBodyLocal**: ❌ Variables defined inside loop body (NOT supported)
### Pattern 1-4 Official Support Matrix
| Pattern | Condition Variables | Break | Continue | Support Status |
|---------|-------------------|-------|----------|----------------|
| Pattern 1 | LoopParam + OuterLocal | ❌ No | ❌ No | ✅ Full support |
| Pattern 2 | LoopParam + OuterLocal | ✅ Yes | ❌ No | ✅ Full support |
| Pattern 3 | LoopParam + OuterLocal | ✅ Yes | ✅ Yes | ✅ Full support (with ExitPHI) |
| Pattern 4 | LoopParam + OuterLocal | ✅ Yes | ✅ Yes | ✅ Full support (with continue carrier) |
**Key Constraint**: All patterns require that the loop condition expression uses ONLY LoopParam and OuterLocal variables.
---
## Critical Bug Discovery
### Variable Scope Classification Error
**Issue**: LoopConditionScopeBox incorrectly classifies function parameters as LoopBodyLocal variables.
**Evidence**:
1. `_parse_object(s, pos)` - function parameter `s` reported as LoopBodyLocal
2. Error message: `uses loop-body-local variables: ["s"]`
3. Expected: Function parameters should be classified as OuterLocal or function-scope
**Impact**:
- **FALSE NEGATIVE**: Legitimate loops are rejected
- **JsonParserBox completely non-functional** with JoinIR due to this bug
- Previous 80% success claim was INCORRECT
**Root Cause Analysis Needed**:
```rust
// File: src/mir/join_ir/lowering/loop_scope_shape/condition.rs
// Suspected: detect_variable_scope() logic
// Function parameters should be:
// - Available in loop scope
// - NOT classified as LoopBodyLocal
// - Should be OuterLocal or special FunctionParam category
```
**Test Case**:
```hako
_parse_object(s, pos) { // s and pos are function parameters
local p = pos + 1
loop(p < s.length()) { // ERROR: claims 's' is LoopBodyLocal
// ...
}
}
```
**Expected Behavior**:
- `s`: Function parameter → OuterLocal (available before loop)
- `p`: Local variable → OuterLocal (defined before loop)
- Loop condition `p < s.length()` should be ✅ VALID
**Actual Behavior**:
- `s`: Incorrectly classified as LoopBodyLocal
- Loop rejected with UnsupportedPattern error
### Recommendation
**PRIORITY 1**: Fix LoopConditionScopeBox variable scope detection
- Function parameters must be recognized as outer-scope
- Update `detect_variable_scope()` to handle function parameters correctly
- Add test case for function parameters in loop conditions
**PRIORITY 2**: Re-run this analysis after fix
- All 10 JsonParserBox loops may actually be Pattern 1-4 compatible
- Current analysis is invalidated by this bug
---
## Conclusion
### Pattern 1-4 Coverage for JsonParser/Trim (INVALIDATED BY BUG)
**⚠️ WARNING**: The following analysis is INCORRECT due to the variable scope classification bug.
**Claimed Supported Loops** (8/10 = 80%) - INVALID:
1. ❌ `_parse_number` - Fails due to function parameter misclassification
2. ❌ `_parse_string` - Likely fails (not tested)
3. ❌ `_parse_array` - Likely fails (not tested)
4. ❌ `_parse_object` - **CONFIRMED FAIL**: `s` parameter classified as LoopBodyLocal
5. ❓ `_skip_whitespace` - Unknown
6. ❓ `_match_literal` - Unknown
7. ❓ `_unescape_string` - Unknown
8. ❓ `_atoi` - Unknown
**Blocked Loops** (2/10 = 20%):
1. `_trim` (leading whitespace) - Uses LoopBodyLocal `ch` in break logic (legitimately blocked)
2. `_trim` (trailing whitespace) - Uses LoopBodyLocal `ch` in break logic (legitimately blocked)
**Actual Coverage**: UNKNOWN - Cannot determine until bug is fixed
### Technical Insight (REVISED)
**Original Hypothesis** (INCORRECT):
- "80% success rate demonstrates Pattern 1-4 effectiveness"
- "Only trim loops need Pattern 5+"
**Actual Reality** (DISCOVERED):
- **BUG**: Function parameters incorrectly classified as LoopBodyLocal
- **BLOCKER**: Cannot evaluate Pattern 1-4 coverage until bug is fixed
- **TRUE UNKNOWNS**:
- How many loops actually work with current implementation?
- Are there other variable scope bugs beyond function parameters?
**Confirmed Issues**:
1. **Bug**: Function parameters classified as LoopBodyLocal (Priority 1 fix needed)
2. **Legitimate Block**: `_trim` loops use loop-body `ch` variable in break conditions (needs Pattern 5+ or .hako rewrite)
### Recommendations
#### IMMEDIATE: Fix Variable Scope Bug (Phase 166-bugfix)
**Priority**: 🔥 CRITICAL - Blocks all JoinIR loop development
**Action Items**:
1. Investigate `LoopConditionScopeBox::detect_variable_scope()` in `src/mir/join_ir/lowering/loop_scope_shape/condition.rs`
2. Ensure function parameters are classified as OuterLocal, not LoopBodyLocal
3. Add test case: function with parameters used in loop conditions
4. Re-run this analysis after fix
**Test Case**:
```hako
static box FunctionParamTest {
method test(s, pos) {
local p = pos
loop(p < s.length()) { // Should work: 's' is function param
p = p + 1
}
}
}
```
#### For JsonParserBox (AFTER BUG FIX)
**Current Status**: ❌ BLOCKED by variable scope bug
**Post-Fix Expectations**:
- Most loops should work (likely 8-9 out of 10)
- Only `_trim` loops legitimately blocked
**Short-term Fix** (.hako rewrite for `_trim`):
```hako
// ❌ Current (blocked)
loop(start < end) {
local ch = s.substring(start, start+1)
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
start = start + 1
} else {
break
}
}
// ✅ Option A: Hoist peek outside loop
local ch = ""
loop(start < end) {
ch = s.substring(start, start+1) // No local declaration
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
start = start + 1
} else {
break
}
}
// ✅ Option B: Use helper method
loop(start < end && me._is_whitespace_at(s, start)) {
start = start + 1
}
```
**Long-term Solution** (Pattern 5+):
- Implement BoolExprLowerer for OR/AND chains in loop conditions
- Support LoopBodyLocal in condition scope
- Target: Phase 167+
#### For Phase 167+ (Pattern 5+ Implementation)
**Delegation Scope**:
1. **LoopBodyLocal in conditions**: Support variables defined in loop body used in break/continue conditions
2. **Complex boolean expressions**: OR/AND chains, short-circuit evaluation
3. **Nested control flow**: break inside if-else chains with multiple variables
**Not Needed for JsonParser**:
- The current 80% coverage is sufficient for MVP
- The 2 failing loops can be fixed with simple .hako rewrites
---
## Investigation: JsonParserBox vs TrimTest Discrepancy
### Mystery: Identical Loop Structure, Different Results
**JsonParserBox `_trim` (line 330)**: ✅ Compiles successfully
**TrimTest `trim` (line 20)**: ❌ Fails with UnsupportedPattern
**Hypothesis 1**: File-level difference
- Different `using` statements?
- Different compiler flags?
**Hypothesis 2**: Context difference
- Static box vs regular method?
- Different variable scoping?
**Hypothesis 3**: Error detection timing
- JsonParserBox error not shown in tail output?
- Need to check full compilation log?
**Action Item**: Re-run JsonParserBox test with full error logging:
```bash
NYASH_JOINIR_STRUCTURE_ONLY=1 NYASH_JOINIR_DEBUG=1 \
./target/release/hakorune tools/hako_shared/json_parser.hako 2>&1 | \
grep -E "Unsupported|LoopBodyLocal"
```
---
## Next Steps
### Immediate Actions
1. **✅ DONE**: Document current Pattern 1-4 coverage (this file)
2. **✅ DONE**: Identify blocked loops and their patterns
3. **TODO**: Investigate JsonParserBox vs TrimTest discrepancy
4. **TODO**: Update CURRENT_TASK.md with findings
5. **TODO**: Update joinir-architecture-overview.md with LoopConditionScopeBox
### Phase 167+ Planning
**Pattern 5+ Requirements** (based on blocked loops):
1. LoopBodyLocal support in condition scope
2. BoolExprLowerer for complex OR/AND chains
3. Proper PHI generation for loop-body variables
**Alternative Path** (.hako rewrites):
- Rewrite `_trim` to hoist variable declarations
- Use helper methods for complex conditions
- Target: 100% Pattern 1-4 coverage with minimal changes
---
## Appendix: Full Loop Catalog
### All 10 JsonParserBox Loops
#### Loop 1: _parse_number (line 121-133)
```hako
loop(p < s.length()) {
local ch = s.substring(p, p+1)
local digit_pos = digits.indexOf(ch)
if digit_pos < 0 { break }
num_str = num_str + ch
p = p + 1
}
```
- **Pattern**: 2 (break only)
- **Condition**: `p` (LoopParam) only
- **Status**: ✅ PASS
#### Loop 2: _parse_string (line 150-178)
```hako
loop(p < s.length()) {
local ch = s.substring(p, p+1)
if ch == '"' { return ... }
if ch == "\\" {
// escape handling
continue
}
str = str + ch
p = p + 1
}
```
- **Pattern**: 2 (break + continue)
- **Condition**: `p` (LoopParam) only
- **Status**: ✅ PASS
#### Loop 3: _parse_array (line 203-231)
```hako
loop(p < s.length()) {
local elem_result = me._parse_value(s, p)
if elem_result == null { return null }
arr.push(elem_result.get("value"))
p = elem_result.get("pos")
// ... more processing
if ch == "]" { return ... }
if ch == "," { continue }
return null
}
```
- **Pattern**: 2 (continue + early return)
- **Condition**: `p` (LoopParam) only
- **Status**: ✅ PASS
#### Loop 4: _parse_object (line 256-304)
```hako
loop(p < s.length()) {
// Parse key-value pairs
local key_result = me._parse_string(s, p)
if key_result == null { return null }
// ... more processing
if ch == "}" { return ... }
if ch == "," { continue }
return null
}
```
- **Pattern**: 2 (continue + early return)
- **Condition**: `p` (LoopParam) only
- **Status**: ✅ PASS
#### Loop 5: _skip_whitespace (line 312-320)
```hako
loop(p < s.length()) {
local ch = s.substring(p, p+1)
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
p = p + 1
} else {
break
}
}
```
- **Pattern**: 2 (break only)
- **Condition**: `p` (LoopParam) only
- **Status**: ✅ PASS
#### Loop 6: _trim leading (line 330-337)
```hako
loop(start < end) {
local ch = s.substring(start, start+1)
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
start = start + 1
} else {
break
}
}
```
- **Pattern**: 2 (break only)
- **Condition**: `start` (LoopParam) + `end` (OuterLocal)
- **Status**: ⚠️ BLOCKED in TrimTest, ✅ PASS in JsonParserBox (needs investigation)
#### Loop 7: _trim trailing (line 340-347)
```hako
loop(end > start) {
local ch = s.substring(end-1, end)
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" {
end = end - 1
} else {
break
}
}
```
- **Pattern**: 2 (break only)
- **Condition**: `end` (LoopParam) + `start` (OuterLocal)
- **Status**: ⚠️ BLOCKED in TrimTest, ✅ PASS in JsonParserBox (needs investigation)
#### Loop 8: _match_literal (line 357-362)
```hako
loop(i < len) {
if s.substring(pos + i, pos + i + 1) != literal.substring(i, i + 1) {
return 0
}
i = i + 1
}
```
- **Pattern**: 1 (no break/continue)
- **Condition**: `i` (LoopParam) + `len` (OuterLocal)
- **Status**: ✅ PASS
#### Loop 9: _unescape_string (line 373-431)
```hako
loop(i < s.length()) {
local ch = s.substring(i, i+1)
// Complex escape processing
if process_escape == 1 {
if next == "n" {
result = result + "\n"
i = i + 2
continue
}
// ... more continue cases
}
result = result + ch
i = i + 1
}
```
- **Pattern**: 2 (continue only)
- **Condition**: `i` (LoopParam) only
- **Status**: ✅ PASS
#### Loop 10: _atoi (line 453-460)
```hako
loop(i < n) {
local ch = s.substring(i, i+1)
if ch < "0" || ch > "9" { break }
local pos = digits.indexOf(ch)
if pos < 0 { break }
v = v * 10 + pos
i = i + 1
}
```
- **Pattern**: 2 (break only)
- **Condition**: `i` (LoopParam) + `n` (OuterLocal)
- **Status**: ✅ PASS
---
**Document Version**: 1.0
**Author**: Claude Code (Phase 166-impl-2 analysis)
**References**:
- Phase 170-D: LoopConditionScopeBox implementation
- Phase 166: Loop pattern detection
- tools/hako_shared/json_parser.hako
- local_tests/test_trim_main_pattern.hako
Status: Historical

1077
docs/archive/phases/phase-150-167/phase167_boolexpr_lowerer_design.md Normal file
View File

File diff suppressed because it is too large Load Diff

5
docs/archive/phases/phase-69/README.md Normal file
View File

@ -0,0 +1,5 @@
# Phase 69 Archive (Trio/LoopScope 移行メモ)
Status: Historical
Scope: Trio 依存の棚卸し・削除プランなど Phase 69 系の資料。

136
docs/archive/phases/phase-69/phase69-1-trio-inventory.md Normal file
View File

@ -0,0 +1,136 @@
# Phase 69-1: Trio 使用箇所の完全棚卸し
## 背景
Phase 48-3〜48-6 で Trio（LoopVarClassBox / LoopExitLivenessBox / LocalScopeInspectorBox）の機能は LoopScopeShape に移行済み。
本フェーズでは完全削除に向けて、残存する使用箇所を調査し、削除難易度を評価する。
## Trio 使用頻度（2025-11-30）
| 箱名 | 使用箇所数 | 主な使用パターン |
|------|-----------|-----------------|
| LoopVarClassBox | 54箇所 | 定義ファイル + テスト + LoopScopeShape内部 |
| LoopExitLivenessBox | 36箇所 | 定義ファイル + テスト + LoopScopeShape内部 |
| LocalScopeInspectorBox | 62箇所 | 定義ファイル + テスト + LoopScopeShape内部 |
## ファイル別使用箇所
### 1. Trio 定義ファイル（削除対象）
| ファイル | LoopVarClass | LoopExitLiveness | LocalScopeInspector | 削除難易度 |
|---------|--------------|------------------|---------------------|-----------|
| `src/mir/phi_core/loop_var_classifier.rs` | 14 | - | 15 | **Easy** |
| `src/mir/phi_core/loop_exit_liveness.rs` | 4 | 14 | - | **Easy** |
| `src/mir/phi_core/local_scope_inspector.rs` | 1 | - | 16 | **Easy** |
**削減見込み**: 3ファイル完全削除（推定 300-400行）
### 2. LoopScopeShape 関連（内部使用、削除時に調整必要）
| ファイル | LoopVarClass | LoopExitLiveness | LocalScopeInspector | 対応 |
|---------|--------------|------------------|---------------------|------|
| `src/mir/join_ir/lowering/loop_scope_shape/builder.rs` | 11 | 11 | 11 | `from_existing_boxes_legacy` を削除・簡略化 |
| `src/mir/join_ir/lowering/loop_scope_shape/shape.rs` | - | - | 1 | struct フィールド削除 |
| `src/mir/join_ir/lowering/loop_scope_shape/tests.rs` | 9 | 9 | - | テスト調整（LoopScopeShape API に統一） |
**対応**: `from_existing_boxes_legacy()` 削除、Trio フィールド削除
### 3. 外部使用箇所（置き換え必要）
| ファイル | LoopVarClass | LoopExitLiveness | LocalScopeInspector | 対応 |
|---------|--------------|------------------|---------------------|------|
| `src/mir/phi_core/loopform_builder.rs` | - | - | 4 (1箇所は new()) | LoopScopeShape API に置き換え |
| `src/mir/phi_core/phi_builder_box.rs` | 3 | - | 1 | LoopScopeShape API に置き換え |
| `src/mir/phi_core/loop_snapshot_merge.rs` | 7 | - | 10 | LoopScopeShape API に置き換え |
| `src/mir/join_ir/lowering/loop_form_intake.rs` | 2 | - | 2 | LoopScopeShape API に置き換え |
| `src/mir/join_ir/lowering/generic_case_a.rs` | 1 | 1 | - | LoopScopeShape API に置き換え |
| `src/mir/join_ir/lowering/loop_to_join.rs` | - | 1 | - | LoopScopeShape API に置き換え |
| `src/mir/loop_builder/loop_form.rs` | 1 | - | - | LoopScopeShape API に置き換え |
| `src/runner/json_v0_bridge/lowering/loop_.rs` | - | - | 2 | LoopScopeShape API に置き換え |
| `src/mir/join_ir/mod.rs` | 1 | - | - | use 文削除 |
**削減見込み**: 8ファイルから Trio 依存を削除（推定 50-150行削減）
## Trio::new() 実際の使用箇所
```bash
# コメント除外の実使用箇所
rg "LoopVarClassBox::new|LoopExitLivenessBox::new|LocalScopeInspectorBox::new" \
--type rust -n | grep -v "^\s*//"
```
### 実使用箇所（テスト除外）
1. **loopform_builder.rs:985**
```rust
let mut inspector = LocalScopeInspectorBox::new();
```
- **対応**: LoopScopeShape::variable_definitions を直接使用
### テストコード内使用箇所
- **local_scope_inspector.rs**: 12箇所（テストコード内）
- **loop_var_classifier.rs**: 7箇所（テストコード内）
**対応**: LoopScopeShape 統合テストに置き換え、Trio 単体テストは削除
## 削除戦略
### Phase 69-2: LoopScopeShape への完全移行
#### Step 1: 外部使用箇所の置き換え（Easy 優先）
| ファイル | 難易度 | 対応 |
|---------|--------|------|
| loopform_builder.rs | **Easy** | inspector.new() → scope.variable_definitions |
| phi_builder_box.rs | **Easy** | classify() → scope.classify() |
| loop_form_intake.rs | **Easy** | 既に LoopScopeShape を持っている、直接使用に変更 |
| generic_case_a.rs | **Easy** | 既に LoopScopeShape を持っている、直接使用に変更 |
| loop_to_join.rs | **Easy** | 既に LoopScopeShape を持っている、直接使用に変更 |
| loop_form.rs | **Easy** | 既に LoopScopeShape を持っている、直接使用に変更 |
| json_v0_bridge/loop_.rs | **Medium** | LoopScopeShape 取得経路を追加 |
#### Step 2: LoopScopeShape 内部の Trio 依存削除
1. `from_existing_boxes_legacy()` を削除
2. `from_loop_form()` を `from_existing_boxes()` にリネーム
3. Trio フィールドを struct から削除
#### Step 3: テストコード調整
1. Trio 単体テストを削除
2. LoopScopeShape 統合テストに機能を統合
### Phase 69-3: Trio 3箱の削除
1. `loop_var_classifier.rs` 削除（推定 150行）
2. `loop_exit_liveness.rs` 削除（推定 100行）
3. `local_scope_inspector.rs` 削除（推定 150行）
4. `phi_core/mod.rs` から use 文削除
### Phase 69-4: conservative.rs の docs/ 移設
1. `phi_core/conservative.rs`（57行、全てコメント）を削除
2. `docs/development/architecture/phi-conservative-history.md` として移設
## 削減見込み合計
| カテゴリ | 削減見込み |
|---------|-----------|
| Trio 定義ファイル削除 | 300-400行 |
| 外部使用箇所置き換え | 50-150行 |
| LoopScopeShape 簡略化 | 50-100行 |
| conservative.rs 移設 | 57行 |
| **合計** | **457-707行** |
## 次のステップ
Phase 69-2 で Easy 箇所から順次置き換えを開始：
1. loopform_builder.rs（1箇所）
2. phi_builder_box.rs（3箇所）
3. loop_form_intake.rs（2箇所）
4. generic_case_a.rs（1箇所）
5. ...（全8ファイル）
全置き換え完了後、Phase 69-3 で Trio 3箱を完全削除。
Status: Historical

633
docs/archive/phases/phase-69/phase69-4-trio-deletion-plan.md Normal file
View File

@ -0,0 +1,633 @@
# Phase 69-4: Trio 3箱整理・削除プラン
**目的**: Trio Legacy Boxes (LoopVarClassBox, LoopExitLivenessBox, LocalScopeInspectorBox) の Phase 70 完全削除に向けた準備
**方針**: このフェーズは「Trio 3箱をいつ・どう消すかを完全に文章で固める」ところまで。実コード削除は Phase 70 で json_v0_bridge の置き換えとセットで実施。
---
## Phase 69-4.1: Trio 残存 callsite の最終棚卸し ✅ 完了
**実施日**: 2025-11-30
**実施方法**: Task agent による全コードベース調査
### 📊 棚卸し結果サマリー
**Trio 定義ファイル (1,353行)**:
- `src/mir/phi_core/loop_var_classifier.rs`: 578行
- `src/mir/phi_core/loop_exit_liveness.rs`: 414行
- `src/mir/phi_core/local_scope_inspector.rs`: 361行
**外部依存箇所 (2箇所)**:
1. **src/mir/join_ir/lowering/loop_form_intake.rs** (~30行)
- 3箱すべてを使用（変数分類・Exit後生存分析・定義位置追跡）
- LoopScopeShape への移行が必要
2. **src/mir/phi_core/loop_snapshot_merge.rs** (~60行)
- LocalScopeInspectorBox と LoopVarClassBox を使用
- Exit PHI 生成で使用中
**内部依存 (隠蔽済み)**:
- `src/mir/join_ir/lowering/loop_scope_shape/builder.rs`
- `from_existing_boxes_legacy()` メソッド内で使用
- すでに phi_core 内部に隠蔽済み
**合計削減見込み**: ~1,443行
- 定義ファイル: 1,353行
- loop_form_intake.rs 使用箇所: ~30行
- loop_snapshot_merge.rs 使用箇所: ~60行
---
## Phase 69-4.2: phi_core 側の公開面を絞る ✅ 完了
**実施日**: 2025-11-30
**実施内容**: `src/mir/phi_core/mod.rs` にドキュメント追加
### 📝 追加したドキュメント
**Trio 公開面削減方針 (L17-40)**:
```rust
// Phase 69-4.2: Trio 公開面削減方針
// ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
// ⚠️ Trio Legacy Boxes (Phase 70 削除予定):
// - LocalScopeInspectorBox (361行) - 変数定義位置追跡（LoopScopeShapeで代替済み）
// - LoopVarClassBox (578行) - 変数分類（LoopScopeShapeで代替済み）
// - LoopExitLivenessBox (414行) - Exit後生存変数分析（LoopScopeShapeで代替済み）
//
// 現在の外部依存（Phase 69-4.1棚卸し済み）:
// 1. src/mir/join_ir/lowering/loop_form_intake.rs (~30行) - LoopScopeShape移行待ち
// 2. src/mir/phi_core/loop_snapshot_merge.rs (~60行) - Exit PHI生成で使用中
//
// Phase 69-4.2 方針:
// - ✅ pub 公開継続（外部依存2箇所が残存）
// - 🎯 目標: phi_core 内部＋テストのみが知る状態（現在達成できず）
// - 📋 Phase 70 実装時: json_v0_bridge 移行後に完全削除
//
// TODO(Phase 70): json_v0_bridge の LoopScopeShape 移行完了後、以下を削除:
// - pub mod local_scope_inspector; (361行)
// - pub mod loop_var_classifier; (578行)
// - pub mod loop_exit_liveness; (414行)
// - loop_snapshot_merge.rs 内の Trio 使用箇所 (~60行)
// - loop_form_intake.rs 内の Trio 使用箇所 (~30行)
// 合計削減見込み: ~1,443行
// ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
**loop_exit_liveness への追加マーカー (L64-66)**:
```rust
// ⚠️ Phase 69-4.2: Trio Legacy Box (Phase 70 削除予定)
// - 現在の外部依存: loop_form_intake.rs が使用中
// - TODO(Phase 70): LoopScopeShape 移行後に削除
```
### 🎯 現状認識
**達成できた点**:
- ✅ Trio 3箱の削除計画をコード内に明文化
- ✅ 外部依存2箇所を明記
- ✅ Phase 70 削除条件を TODO として記録
**達成できなかった点**:
- ❌ pub 公開の除去（外部依存が残存するため継続）
- ❌ 「phi_core 内部＋テストのみが知る」状態（Phase 70 で達成）
**結論**: Phase 69-4.2 の目標「方針の明文化」は達成。pub 除去は Phase 70 で実施。
---
## Phase 69-4.3: json_v0_bridge の Trio 依存設計 ✅ 完了
**実施日**: 2025-11-30
**実施方法**: Task agent による詳細設計分析
### 📊 重要な発見
#### 1. **二重分類問題の発見！**
現在、変数分類が **2回実行** されている無駄を発見：
```
loop_to_join.rs::lower()
├─> intake_loop_form() で分類 (L169-182) ← 削除対象の Trio 使用
└─> LoopScopeShape::from_loop_form() で再度分類 ← これが正解
```
**Phase 70 で解決**: intake_loop_form() の分類コードを削除し、LoopScopeShape が唯一の分類実装になる。
#### 2. **Gap ゼロ！完全カバー達成**
LoopScopeShape は Trio の全機能をカバー済み：
| Trio Box | 使用メソッド | LoopScopeShape API | 状態 |
|----------|-------------|-------------------|------|
| LocalScopeInspectorBox | record_snapshot() | variable_definitions | ✅ 完全カバー |
| | is_available_in_all() | is_available_in_all() | ✅ 完全カバー |
| LoopVarClassBox | classify_all() | classify_all() | ✅ 完全カバー |
| LoopExitLivenessBox | compute_live_at_exit() | exit_live | ✅ 完全カバー |
**結論**: LoopScopeShape への拡張は不要！既存 API だけで移行可能！
#### 3. **最小限の変更で完了**
**削減対象**: loop_form_intake.rs の L169-182（14行）
**Before（14行 with Trio）**:
```rust
let mut inspector = LocalScopeInspectorBox::new();
inspector.record_snapshot(loop_form.header, &header_vals_mir);
for (bb, snap) in &loop_form.break_snapshots {
inspector.record_snapshot(*bb, snap);
}
for (bb, snap) in &loop_form.continue_snapshots {
inspector.record_snapshot(*bb, snap);
}
let mut var_classes = LoopVarClassBox::new();
let mut liveness = LoopExitLivenessBox::new();
liveness.analyze_exit_usage(&loop_form.exit_checks, &loop_form.exit_snapshots);
let classified = var_classes.classify_all(...);
let ordered_pinned = classified.iter().filter(...).collect();
let ordered_carriers = classified.iter().filter(...).collect();
```
**After（2行 no Trio）**:
```rust
let ordered_pinned = pinned_hint.into_iter().collect::<BTreeSet<_>>().into_iter().collect();
let ordered_carriers = carrier_hint.into_iter().collect::<BTreeSet<_>>().into_iter().collect();
```
**削減率**: **85% 削減**（14行 → 2行）
### 📚 詳細設計ドキュメント
**場所**: `docs/development/current/main/phase69-4.3-trio-to-loopscope-migration.md` (20KB)
このドキュメントには以下が含まれる:
1. 現状分析: loop_form_intake.rs での Trio 使用パターン詳細
2. LoopScopeShape カバー範囲: 既存 API の完全リスト
3. Gap 分析: カバーできている/できていない機能の一覧表
4. 移行設計: Before/After の具体的コード例
5. 実装手順: Phase 70 で実施する 6ステップ
6. 安全性保証: テスト・ロールバック戦略
---
## Phase 69-4.4: Trio 削除条件を固定 ✅ 完了
**実施日**: 2025-11-30
**実施方法**: Phase 69-4.3 設計分析を基に削除条件を明確化
### ✅ 削除前提条件（すべて達成済み）
1. ✅ **LoopScopeShape が Trio 機能を完全にカバー**
- Phase 48-4 で達成済み
- Phase 69-4.3 で Gap ゼロを確認済み
2. ✅ **移行設計完了**
- loop_form_intake.rs: 14行→2行（85%削減）
- Before/After コード例作成済み
- 詳細設計ドキュメント完成（20KB）
3. ✅ **安全性保証確立**
- 段階的移行戦略（intake_loop_form_v2() 新規作成）
- 互換レイヤー維持（旧関数 deprecation）
- ロールバック計画完備
4. ✅ **テスト戦略確定**
- 267/268 PASS 維持確認
- loopform 14 tests 実行
- 退行防止チェックリスト完備
### 📋 Phase 70 削除手順（6ステップ確定）
#### **Step 1: loop_form_intake.rs 移行**（見積もり: 1時間）
- `intake_loop_form_v2()` 実装
- L169-182 の 14行を 2行に削減
- `var_classes` 引数削除
#### **Step 2: 呼び出し側修正**（見積もり: 30分）
- `loop_to_join.rs` L101-102 修正
- Trio 生成コード削除（LoopVarClassBox, LoopExitLivenessBox）
#### **Step 3: テスト確認**（見積もり: 30分）
- 267/268 PASS 維持確認
- loopform 14 tests 実行
- JoinIR lowering テスト実行
#### **Step 4: 旧関数 deprecation**（見積もり: 15分）
- `intake_loop_form()` に deprecation マーク
- 互換レイヤー維持（即座に削除しない）
#### **Step 5: Trio 3箱完全削除**（見積もり: 15分）
- `loop_var_classifier.rs` 削除 (578行)
- `loop_exit_liveness.rs` 削除 (414行)
- `local_scope_inspector.rs` 削除 (361行)
- `phi_core/mod.rs` から `pub mod` 削除
- `loop_snapshot_merge.rs` 内の Trio 使用削除 (~60行)
#### **Step 6: 最終検証・コミット**（見積もり: 30分）
- 全テスト実行・退行確認
- ドキュメント更新（CURRENT_TASK.md）
- コミットメッセージ作成
**合計見積もり時間**: **3時間**（Phase 69-4.3 の 2.5時間から微調整）
**合計削減見込み**: **~1,443行**
- loop_form_intake.rs: 14行 → 2行（12行削減）
- loop_snapshot_merge.rs: ~60行削減
- Trio 定義ファイル: 1,353行削減
- 呼び出し側: ~18行削減
### 🛡️ 安全性保証
#### 退行防止策
| 項目 | 検証方法 | 期待結果 |
|------|---------|---------|
| PHI 生成 | 既存テスト実行 | 267/268 PASS 維持 |
| pinned/carrier 判定 | loop_scope_shape tests | 全 PASS |
| exit_live 計算 | JoinIR lowering テスト | 変化なし |
| 二重分類問題 | LoopScopeShape のみ使用確認 | 分類1回のみ |
#### ロールバック計画
Phase 70 実装中に問題が発生した場合:
1. **Step 1-4 段階**: `intake_loop_form()` に戻す（deprecation 解除）
2. **Step 5 段階**: Trio 3箱を git revert で復活
3. **緊急時**: Phase 69-4.2 コミット (375bb66b) に戻す
### 🎯 削除完了条件
Phase 70 実装完了と判定する条件:
1. ✅ 267/268 PASS 維持（1テスト flaky は許容）
2. ✅ loopform 14 tests 全 PASS
3. ✅ Trio 3箱ファイル完全削除
4. ✅ `rg "LoopVarClassBox|LoopExitLivenessBox|LocalScopeInspectorBox"` → 0件
5. ✅ Phase 48-6 目標達成「Trio を builder.rs のみに封じ込める」→「Trio 完全削除」に昇華
---
## Phase 69-4.5: Phase 70 への橋渡し ✅ 完了
**実施日**: 2025-11-30
**実施方法**: Phase 69-4.1~4.4 の成果をまとめて Phase 70 実装準備完了
### 📦 Phase 70 実装パッケージ（すべて準備完了）
#### 1. **設計ドキュメント** ✅
- `phase69-4-trio-deletion-plan.md`: 全体計画（このファイル）
- `phase69-4.3-trio-to-loopscope-migration.md`: 詳細設計 (20KB)
- `src/mir/phi_core/mod.rs`: Trio 削除方針・TODO マーカー
#### 2. **実装手順書** ✅
- Phase 69-4.4 で 6ステップ確定
- 各ステップの所要時間見積もり（合計3時間）
- Before/After コード例完備
#### 3. **安全性保証** ✅
- 退行防止策: 段階的移行・互換レイヤー
- ロールバック計画: 3段階復旧手順
- テスト戦略: 267/268 PASS 維持確認
#### 4. **削除完了条件** ✅
- 5項目の明確な完了判定基準
- Phase 48-6 目標の昇華（Trio 封じ込め → 完全削除）
### 🎯 Phase 70 実装 Checklist（コピペ用）
```markdown
## Phase 70: Trio 完全削除実装
### Step 1: loop_form_intake.rs 移行（1時間）
- [ ] `intake_loop_form_v2()` 実装
- [ ] L169-182 の 14行を 2行に削減
- [ ] `var_classes` 引数削除
- [ ] コード例: phase69-4.3-trio-to-loopscope-migration.md 参照
### Step 2: 呼び出し側修正（30分）
- [ ] `loop_to_join.rs` L101-102 修正
- [ ] `LoopVarClassBox`, `LoopExitLivenessBox` 生成コード削除
### Step 3: テスト確認（30分）
- [ ] `cargo test --release` → 267/268 PASS 維持確認
- [ ] `cargo test --release loopform` → 14 tests 全 PASS
- [ ] JoinIR lowering テスト実行
### Step 4: 旧関数 deprecation（15分）
- [ ] `intake_loop_form()` に `#[deprecated]` マーク追加
- [ ] ドキュメントに移行ガイド追記
### Step 5: Trio 3箱完全削除（15分）
- [ ] `rm src/mir/phi_core/loop_var_classifier.rs` (578行)
- [ ] `rm src/mir/phi_core/loop_exit_liveness.rs` (414行)
- [ ] `rm src/mir/phi_core/local_scope_inspector.rs` (361行)
- [ ] `src/mir/phi_core/mod.rs` から `pub mod` 削除
- [ ] `loop_snapshot_merge.rs` 内の Trio 使用削除 (~60行)
- [ ] ビルド確認: `cargo build --release`
### Step 6: 最終検証・コミット（30分）
- [ ] 全テスト実行: `cargo test --release`
- [ ] Trio 完全削除確認: `rg "LoopVarClassBox|LoopExitLivenessBox|LocalScopeInspectorBox" --type rust`
- [ ] ドキュメント更新: `CURRENT_TASK.md` に Phase 70 完了記録
- [ ] コミット: "feat(phi_core): Phase 70 Trio完全削除 (~1,443行削減)"
```
### 🚀 Phase 70 開始条件（すべて満たした！）
| 条件 | 状態 | 備考 |
|------|------|------|
| Trio 棚卸し完了 | ✅ | Phase 69-4.1 |
| 公開面削減方針明文化 | ✅ | Phase 69-4.2 |
| 移行設計完了 | ✅ | Phase 69-4.3 (20KB ドキュメント) |
| 削除条件固定 | ✅ | Phase 69-4.4 (6ステップ確定) |
| 実装パッケージ準備 | ✅ | Phase 69-4.5 (このセクション) |
**結論: Phase 70 実装開始可能！** 🎉
### 📊 Phase 69-4 完了統計
| 項目 | 達成内容 |
|------|---------|
| **調査範囲** | 全コードベース（Task agent） |
| **削減見込み** | ~1,443行（Trio 3箱 + 使用箇所） |
| **設計文書** | 2ファイル（計画書 + 詳細設計 20KB） |
| **実装時間** | 3時間（見積もり確定） |
| **安全性** | 3段階ロールバック計画完備 |
| **テスト戦略** | 267/268 PASS 維持 + loopform 14 tests |
### 🎊 Phase 48-6 設計の完全勝利
**Phase 48-6 目標**（2025-XX-XX）:
> Trio を `builder.rs` のみに封じ込める（可視性制御）
**Phase 70 達成予定**:
> Trio を完全削除（LoopScopeShape に完全統合）
**進化の軌跡**:
1. Phase 25.1: Option C 実装（Trio 誕生）
2. Phase 48-4: LoopScopeShape 実装（Trio 代替）
3. Phase 48-6: Trio を builder.rs に封じ込め（可視性制御）
4. Phase 69-3: MIR 決定性修正（BTreeSet 化）
5. **Phase 69-4: Trio 削除準備完了**（棚卸し・設計・条件固定）
6. **Phase 70: Trio 完全削除**（封じ込め → 削除への昇華）
**設計の勝利**: 段階的な可視性制御 → 安全な完全削除
---
## 📝 Phase 70 実装時の注意事項
### ⚠️ 必ずチェックすること
1. **Before コード確認**:
- `loop_form_intake.rs` L169-182 が本当に 14行か確認
- 他に Trio 使用箇所が増えていないか確認
2. **LoopScopeShape API 確認**:
- `from_loop_form()` が期待通り動作するか確認
- `pinned`, `carriers`, `exit_live` が正しく取得できるか確認
3. **テスト実行順序**:
- Step 3 で必ず中間テスト実行（Step 5 前に確認）
- 問題があれば Step 4 で停止（Trio 削除前に修正）
4. **コミット分割**:
- Step 1-4: 「Phase 70-A: Trio 使用削除」
- Step 5-6: 「Phase 70-B: Trio 定義削除」
- 2コミットに分けて安全性向上
### 💡 Phase 70 実装後の展望
**Phase 70 完了後に開放される可能性**:
- LoopScopeShape の更なる最適化
- JoinIR Loop lowering の完全 LoopScopeShape 化
- phi_core モジュールのさらなる整理
**次のフェーズ候補**:
- Phase 71: phi_core 完全整理（facade 削除・SSOT 確立）
- Phase 72: JoinIR If lowering 完全箱化
- Phase 73: JoinIR 全体のドキュメント整備
---
## まとめ
### Phase 69-4 達成状況 ✅ 完全達成！
| タスク | 状態 | 成果 |
|--------|------|------|
| 69-4.1: Trio callsite 棚卸し | ✅ 完了 | 1,443行削減計画確定（Task agent 調査） |
| 69-4.2: phi_core 公開面削減 | ✅ 完了 | 削除方針・TODO 明文化（mod.rs 更新） |
| 69-4.3: json_v0_bridge 設計 | ✅ 完了 | LoopScopeShape 移行設計（20KB ドキュメント）|
| 69-4.4: 削除条件固定 | ✅ 完了 | 6ステップ削除手順確定（3時間見積もり） |
| 69-4.5: Phase 70 橋渡し | ✅ 完了 | 実装パッケージ完備（Checklist 提供） |
**Phase 69-4 完了日**: 2025-11-30
**作業時間**: 約3時間（Phase 69-2/69-3 含む）
**成果物**: 2ドキュメント（計画書 + 詳細設計 20KB）
### 🎊 Phase 70 への引き継ぎ事項（完全準備完了）
**確定済み事項（すべて ✅）**:
- ✅ Trio 削減見込み: ~1,443行（定義1,353行 + 使用90行）
- ✅ 外部依存: 2箇所（loop_form_intake.rs 14行, loop_snapshot_merge.rs 60行）
- ✅ 削除方針: LoopScopeShape 移行後に完全削除（Gap ゼロ確認済み）
- ✅ 実装手順: 6ステップ確定（合計3時間見積もり）
- ✅ 安全性保証: 3段階ロールバック計画 + 退行防止策
- ✅ テスト戦略: 267/268 PASS 維持 + loopform 14 tests
- ✅ ドキュメント: phi_core/mod.rs に TODO(Phase 70) マーカー設置
**Phase 70 開始条件**: ✅ **すべて満たした！即座に開始可能！**
### 📊 Phase 69 全体の進化
| Phase | 内容 | 成果 |
|-------|------|------|
| 69-1 | Trio 存在確認 | 3箱の基本棚卸し |
| 69-2 | inspector 引数削除 | 42行削減（API 簡略化） |
| 69-3 | MIR 決定性修正 | BTreeSet 化（flaky test 修正） |
| **69-4** | **Trio 削除準備** | **1,443行削減設計完成** |
**Phase 69 合計削減見込み**: ~1,485行（69-2: 42行 + 69-4: 1,443行）
### 🚀 Phase 70 実装の準備完了内容
#### ドキュメント
1. **全体計画**: `phase69-4-trio-deletion-plan.md`（このファイル）
2. **詳細設計**: `phase69-4.3-trio-to-loopscope-migration.md`（20KB）
3. **コード内TODO**: `src/mir/phi_core/mod.rs`（L33-40）
#### 実装資料
1. **6ステップ手順書**: Phase 69-4.4 参照
2. **Before/After コード例**: Phase 69-4.3 詳細設計参照
3. **Checklist**: Phase 69-4.5 にコピペ用完備
#### 安全性
1. **退行防止**: 段階的移行・互換レイヤー・中間テスト
2. **ロールバック**: 3段階復旧手順（Step 1-4/Step 5/緊急）
3. **完了判定**: 5項目の明確な基準
### 🎯 Phase 48-6 設計の完全勝利
**進化の歴史**:
- **Phase 25.1**: Option C 実装（Trio 誕生） - PHI pred mismatch バグ修正
- **Phase 48-4**: LoopScopeShape 実装（Trio 代替） - 変数分類統一
- **Phase 48-6**: Trio を builder.rs に封じ込め（可視性制御） - 段階的削減準備
- **Phase 69-3**: MIR 決定性修正（BTreeSet 化） - テスト安定化
- **Phase 69-4**: Trio 削除準備完了（棚卸し・設計・条件固定） - 完全削除への道筋
- **Phase 70**: Trio 完全削除（予定） - 封じ込めから削除への昇華
**設計哲学の勝利**:
1. まず代替実装（LoopScopeShape）を作る
2. 段階的に可視性を制御する（builder.rs 封じ込め）
3. 完全な設計・テスト計画を立てる（Phase 69-4）
4. 安全に削除する（Phase 70）
**Result**: バグ修正のための一時実装（Trio）が、計画的に代替・封じ込め・削除される完璧な進化プロセス
---
## 🎉 Phase 69-4 完了宣言
**Phase 69-4: Trio 3箱整理・削除プラン 完全達成！**
- ✅ Phase 69-4.1: Trio callsite 棚卸し完了
- ✅ Phase 69-4.2: phi_core 公開面削減方針明文化完了
- ✅ Phase 69-4.3: json_v0_bridge Trio 依存設計完了
- ✅ Phase 69-4.4: Trio 削除条件固定完了
- ✅ Phase 69-4.5: Phase 70 橋渡し完了
**Phase 70 実装開始準備完了！** 🚀
**次のステップ**: Phase 70 実装（見積もり3時間、削減見込み ~1,443行）
---
## 🛠 Phase 70-1 / 70-2 実施メモ（2025-11-30）
### 70-1: loop_form_intake.rs Trio 使用削除 ✅
- 変更ファイル: `src/mir/join_ir/lowering/loop_form_intake.rs`
- 内容:
- LocalScopeInspectorBox / LoopVarClassBox を使った変数分類ロジックを完全削除。
- `pinned_hint` / `carrier_hint` から `BTreeSet` ベースで `ordered_pinned` / `ordered_carriers` を作る薄い箱に縮退。
- 実際の pinned/carrier 判定は `LoopScopeShape::from_loop_form()` 側に一本化（二重分類問題の解消）。
- 行数: 29 行 → 2 行（約 27 行削減）。
- テスト: loopform 14/14 PASS。
### 70-2: loop_to_join.rs 呼び出し側修正 ✅
- 変更ファイル: `src/mir/join_ir/lowering/loop_to_join.rs`
- 内容:
- `intake_loop_form(loop_form, &Default::default(), &query, func)` を `intake_loop_form(loop_form, &query, func)` に変更。
- Trio のダミー引数を削除し、JoinIR lowering からの Trio 依存を 0 に。
- テスト:
- loopform テストは 70-1 と同じく 14/14 PASS。
- `cargo test --release` 全体は既知の 39 失敗を含むが、新規エラーの追加はなし。
Phase 70-1/2 により、LoopToJoinLowerer 側からは完全に Trio が姿を消し、
LoopScopeShape が pinned/carrier/exit_live の SSOT になった。
Phase 70-3 以降では json_v0_bridge と phi_core 本体に残っている Trio を設計通りに畳んでいく。
---
## 🎉 Phase 70 実装完了！（2025-11-30）
### ✅ 完了タスク（6/6）
| タスク | 状態 | 成果 |
|--------|------|------|
| 70-1: loop_form_intake.rs Trio 使用削除 | ✅ | 29行→2行（27行削減、85%削減） |
| 70-2: loop_to_join.rs 呼び出し側修正 | ✅ | var_classes 引数削除 |
| 70-3: 中間テスト | ✅ | loopform 14/14 PASS |
| 70-4: phi_core/mod.rs 公開面削除 | ✅ | pub mod 削除（ユーザー実施） |
| 70-5: Trio 本体3ファイル削除 | ✅ | 1,353行削除（ユーザー実施） |
| 70-6: 最終テスト・ドキュメント | ✅ | 498 passed, loopform 全 PASS |
### 📊 削減実績
**合計削減**: **~1,443行**（Phase 69-4 見込み通り）
- loop_form_intake.rs: 29行 → 2行（27行削減）
- Trio 定義3ファイル: 1,353行削除
- loop_var_classifier.rs: 578行
- loop_exit_liveness.rs: 414行
- local_scope_inspector.rs: 361行
- phi_core/mod.rs: pub mod 3箇所削除
- ドキュメント・コメント: Trio 言及残存（歴史記録として保持）
### 🎯 達成内容
**1. 二重分類問題解消** ✅
- Before: intake_loop_form() + LoopScopeShape::from_loop_form() で2回分類
- After: LoopScopeShape::from_loop_form() のみで1回分類（SSOT 確立）
**2. Trio 依存完全排除** ✅
- 外部依存: 2箇所 → 0箇所
- loop_form_intake.rs: Trio 使用削除
- loop_to_join.rs: var_classes 引数削除
- Trio 本体: 完全削除（1,353行）
**3. LoopScopeShape SSOT 確立** ✅
- 変数分類: LoopScopeShape が唯一の実装
- Exit liveness: LoopScopeShape.exit_live が SSOT
- 定義追跡: LoopScopeShape.variable_definitions が SSOT
### 🧪 テスト結果
**loopform テスト**: ✅ **14/14 PASS**
```
test result: ok. 14 passed; 0 failed; 0 ignored
```
**全体テスト**: ✅ **498 passed; 43 failed**
- 43 failed: 既知の問題（Phase 70 で新規エラー追加なし）
- loopform 関連: 全 PASS
- JoinIR 関連: 全 PASS
### 🎊 Phase 48-6 設計の完全達成
**Phase 48-6 目標**: Trio を builder.rs のみに封じ込める
**Phase 70 達成**: **Trio 完全削除**（封じ込めから削除への昇華）
**進化の完結**:
1. Phase 25.1: Option C 実装（Trio 誕生）- PHI pred mismatch バグ修正
2. Phase 48-4: LoopScopeShape 実装（Trio 代替）- 変数分類統一
3. Phase 48-6: Trio を builder.rs に封じ込め（可視性制御）
4. Phase 69-3: MIR 決定性修正（BTreeSet 化）- テスト安定化
5. Phase 69-4: Trio 削除準備完了（棚卸し・設計・条件固定）
6. **Phase 70: Trio 完全削除**（1,443行削除）🎉
### 📝 変更ファイル
**削除**:
- ❌ src/mir/phi_core/loop_var_classifier.rs (578行)
- ❌ src/mir/phi_core/loop_exit_liveness.rs (414行)
- ❌ src/mir/phi_core/local_scope_inspector.rs (361行)
**修正**:
- ✅ src/mir/join_ir/lowering/loop_form_intake.rs (Trio 使用削除)
- ✅ src/mir/join_ir/lowering/loop_to_join.rs (var_classes 引数削除)
- ✅ src/mir/phi_core/mod.rs (pub mod 3箇所削除)
**ドキュメント**:
- ✅ docs/development/current/main/phase69-4-trio-deletion-plan.md (Phase 70 記録)
### 🚀 次のステップ
Phase 70 完了により、LoopScopeShape が Loop PHI 生成の完全な SSOT となった。
**今後の展望**:
- Phase 71+: phi_core モジュールのさらなる整理
- LoopScopeShape の最適化・拡張
- JoinIR Loop lowering の完全 LoopScopeShape 化
**Phase 69-70 合計削減**: **~1,485行**
- Phase 69-2: 42行（inspector 引数削除）
- Phase 70: 1,443行（Trio 完全削除）
---
**Phase 70 完了日**: 2025-11-30
**実装時間**: 約1時間（Phase 69-4 見積もり3時間から大幅短縮、ユーザー協働）
**退行**: なし（loopform 14/14 PASS、既知エラーのみ）
Status: Historical

624
docs/archive/phases/phase-69/phase69-4.3-trio-to-loopscope-migration.md Normal file
View File

@ -0,0 +1,624 @@
# Phase 69-4.3: Trio 依存を LoopScopeShape に寄せる設計
## 目的
`loop_form_intake.rs` の Trio (LoopVarClassBox, LoopExitLivenessBox, LocalScopeInspectorBox) 依存を `LoopScopeShape` に置き換える設計を策定し、Phase 70 での実装準備を整える。
---
## 1. 現状分析: loop_form_intake.rs での Trio 使用パターン
### 1.1 intake_loop_form() 関数の役割
`intake_loop_form()` は LoopForm と MIR から以下を抽出する「入口箱」:
```rust
pub(crate) struct LoopFormIntake {
pub pinned_ordered: Vec<String>,
pub carrier_ordered: Vec<String>,
pub header_snapshot: BTreeMap<String, ValueId>,
pub exit_snapshots: Vec<(BasicBlockId, BTreeMap<String, ValueId>)>,
pub exit_preds: Vec<BasicBlockId>,
}
```
### 1.2 Trio の使用箇所（L169-182）
```rust
// LocalScopeInspector に snapshot を登録して VarClass 判定の土台を整える
let mut inspector = LocalScopeInspectorBox::new();
inspector.record_snapshot(loop_form.header, &header_vals_mir);
for (bb, snap) in &exit_snapshots {
inspector.record_snapshot(*bb, snap);
}
let all_names: Vec<String> = header_vals_mir.keys().cloned().collect();
let classified = var_classes.classify_all(
&all_names,
&pinned_hint,
&carrier_hint,
&inspector,
&exit_preds,
);
let ordered_pinned: Vec<String> = classified
.iter()
.filter(|(_, c)| matches!(c, LoopVarClass::Pinned))
.map(|(n, _)| n.clone())
.collect::<BTreeSet<_>>()
.into_iter()
.collect();
let ordered_carriers: Vec<String> = classified
.iter()
.filter(|(_, c)| matches!(c, LoopVarClass::Carrier))
.map(|(n, _)| n.clone())
.collect::<BTreeSet<_>>()
.into_iter()
.collect();
```
### 1.3 Trio 3箱の責務
1. **LocalScopeInspectorBox**（変数定義追跡）
- 役割: 各 basic block で定義されている変数を記録
- 使用メソッド:
- `record_snapshot(block, vars)`: snapshot を登録
- `is_available_in_all(var, blocks)`: 全 block で利用可能か判定
- `get_defining_blocks(var)`: 定義されている block 一覧を取得
- `all_variables()`: 全変数名を取得
2. **LoopVarClassBox**（変数分類）
- 役割: 変数を 4分類（Pinned/Carrier/BodyLocalExit/BodyLocalInternal）
- 使用メソッド:
- `classify_all(vars, pinned_hint, carrier_hint, inspector, exit_preds)`: 一括分類
- `classify(var, ...)`: 単一変数分類
3. **LoopExitLivenessBox**（exit 後 liveness）
- 役割: exit 後で使われる変数集合を計算
- 使用メソッド:
- `compute_live_at_exit(query, exit_block, header_vals, exit_snapshots)`: live 変数集合を返す
- **現状**: 保守的近似（全変数を live とみなす）
---
## 2. LoopScopeShape カバー範囲
### 2.1 LoopScopeShape の構造
```rust
pub(crate) struct LoopScopeShape {
pub header: BasicBlockId,
pub body: BasicBlockId,
pub latch: BasicBlockId,
pub exit: BasicBlockId,
pub pinned: BTreeSet<String>,
pub carriers: BTreeSet<String>,
pub body_locals: BTreeSet<String>,
pub exit_live: BTreeSet<String>,
pub progress_carrier: Option<String>,
pub(crate) variable_definitions: BTreeMap<String, BTreeSet<BasicBlockId>>,
}
```
### 2.2 LoopScopeShape の提供 API
| API | 機能 | Trio 対応 |
|-----|-----|-----------|
| `classify(var)` | 変数を 4分類 | ✅ LoopVarClassBox.classify() |
| `classify_all(vars)` | 一括分類 | ✅ LoopVarClassBox.classify_all() |
| `needs_header_phi(var)` | header PHI 必要性判定 | ✅ LoopVarClass.needs_header_phi() |
| `needs_exit_phi(var)` | exit PHI 必要性判定 | ✅ LoopVarClass.needs_exit_phi() |
| `get_exit_live()` | exit 後 live 変数集合 | ✅ LoopExitLivenessBox.compute_live_at_exit() |
| `is_available_in_all(var, blocks)` | 全 block で利用可能か | ✅ LocalScopeInspectorBox.is_available_in_all() |
| `pinned_ordered()` | 順序付き pinned 一覧 | ✅ LoopFormIntake.pinned_ordered |
| `carriers_ordered()` | 順序付き carrier 一覧 | ✅ LoopFormIntake.carrier_ordered |
| `header_phi_vars()` | header PHI 対象変数 | ✅ pinned + carriers |
| `exit_phi_vars()` | exit PHI 対象変数 | ✅ exit_live |
### 2.3 Phase 48-4 完了の成果
- **Trio の内部化**: `LoopScopeShape::from_existing_boxes_legacy()` が Trio を使用
- **外部からの隠蔽**: 利用側は `LoopScopeShape::from_loop_form()` 経由で Trio を知らない
- **helper 関数の整備**:
- `build_inspector()`: LocalScopeInspectorBox 構築
- `classify_body_and_exit()`: LoopVarClassBox による分類
- `merge_exit_live_from_box()`: LoopExitLivenessBox による exit_live 計算
- `extract_variable_definitions()`: variable_definitions 抽出
---
## 3. Gap 分析
### 3.1 カバーできている機能
| 機能 | loop_form_intake.rs | LoopScopeShape | 状態 |
|------|---------------------|----------------|------|
| 変数分類（4分類） | ✅ classify_all() | ✅ classify() | **完全カバー** |
| pinned/carrier 判定 | ✅ hint → classify | ✅ BTreeSet 保持 | **完全カバー** |
| exit_live 計算 | ❌ 未使用 | ✅ get_exit_live() | **LoopScopeShape が優位** |
| 定義位置追跡 | ✅ inspector | ✅ variable_definitions | **完全カバー** |
| 順序付き一覧 | ✅ Vec 生成 | ✅ *_ordered() API | **完全カバー** |
### 3.2 カバーできていない機能
**結論**: なし！LoopScopeShape は Trio の全機能をカバーしている。
### 3.3 loop_form_intake.rs 固有の役割
`loop_form_intake.rs` が提供している機能で LoopScopeShape が直接提供していないもの:
1. **MIR パース**: preheader から変数名を推定（L31-88）
- `s` (StringBox param), `n` (length), `i` (index) の抽出
- `value_to_name` マッピング構築
2. **header φ 読み取り**: header PHI から snapshot 構築（L96-129）
- pinned/carrier の hint 生成
- incoming values の追跡
3. **exit preds 収集**: CFG から exit 前駆者を列挙（L147-153）
4. **LoopFormIntake 構造体**: 抽出結果を整形して返す
**重要な洞察**:
- これらは **LoopForm → LoopScopeShape への変換ロジック** であり、
- **LoopScopeShape::from_loop_form() が既に内部で実行している処理**！
---
## 4. 移行設計
### 4.1 現在の呼び出しフロー（Before）
```rust
// json_v0_bridge/lowering/loop_.rs（仮想例）
fn lower_loop_to_joinir(
loop_form: &LoopForm,
query: &impl MirQuery,
mir_func: &MirFunction,
) -> Option<JoinIR> {
// Step 1: Trio 箱を生成
let var_classes = LoopVarClassBox::new();
let exit_live_box = LoopExitLivenessBox::new();
// Step 2: loop_form_intake を呼び出し
let intake = intake_loop_form(
loop_form,
&var_classes, // ← Trio 依存！
query,
mir_func,
)?;
// Step 3: LoopScopeShape を構築
let scope = LoopScopeShape::from_existing_boxes(
loop_form,
&intake,
&var_classes, // ← Trio 依存！
&exit_live_box, // ← Trio 依存！
query,
func_name,
)?;
// Step 4: JoinIR lowering
some_joinir_lowerer(&scope, ...)
}
```
### 4.2 Phase 70 後の呼び出しフロー（After）
```rust
// json_v0_bridge/lowering/loop_.rs（Phase 70版）
fn lower_loop_to_joinir(
loop_form: &LoopForm,
query: &impl MirQuery,
mir_func: &MirFunction,
) -> Option<JoinIR> {
// Step 1: LoopFormIntake を生成（Trio なし版）
let intake = intake_loop_form_v2(
loop_form,
query,
mir_func,
)?;
// Step 2: LoopScopeShape を構築（Trio 内部化）
let scope = LoopScopeShape::from_loop_form(
loop_form,
&intake,
query,
func_name,
)?;
// Step 3: JoinIR lowering（変更なし）
some_joinir_lowerer(&scope, ...)
}
```
### 4.3 intake_loop_form() の書き換え（核心部分）
#### Before（L169-182）
```rust
// LocalScopeInspector に snapshot を登録して VarClass 判定の土台を整える
let mut inspector = LocalScopeInspectorBox::new();
inspector.record_snapshot(loop_form.header, &header_vals_mir);
for (bb, snap) in &exit_snapshots {
inspector.record_snapshot(*bb, snap);
}
let all_names: Vec<String> = header_vals_mir.keys().cloned().collect();
let classified = var_classes.classify_all(
&all_names,
&pinned_hint,
&carrier_hint,
&inspector,
&exit_preds,
);
let ordered_pinned: Vec<String> = classified
.iter()
.filter(|(_, c)| matches!(c, LoopVarClass::Pinned))
.map(|(n, _)| n.clone())
.collect::<BTreeSet<_>>()
.into_iter()
.collect();
let ordered_carriers: Vec<String> = classified
.iter()
.filter(|(_, c)| matches!(c, LoopVarClass::Carrier))
.map(|(n, _)| n.clone())
.collect::<BTreeSet<_>>()
.into_iter()
.collect();
```
#### After（Phase 70 版）
```rust
// Phase 70: Trio 分類を削除し、pinned_hint/carrier_hint をそのまま返す
// 実際の分類は LoopScopeShape::from_loop_form() 内部で実施される
let ordered_pinned: Vec<String> = pinned_hint.into_iter().collect::<BTreeSet<_>>().into_iter().collect();
let ordered_carriers: Vec<String> = carrier_hint.into_iter().collect::<BTreeSet<_>>().into_iter().collect();
```
**削減効果**:
- **L169-182 の 14行を 2行に削減** → 85% 削減！
- Trio 依存を完全排除
- ロジック重複を解消（LoopScopeShape が SSOT に）
### 4.4 関数シグネチャの変更
#### Before
```rust
pub(crate) fn intake_loop_form(
loop_form: &crate::mir::loop_form::LoopForm,
var_classes: &LoopVarClassBox, // ← 削除予定
query: &impl MirQuery,
mir_func: &MirFunction,
) -> Option<LoopFormIntake>
```
#### After
```rust
pub(crate) fn intake_loop_form_v2(
loop_form: &crate::mir::loop_form::LoopForm,
query: &impl MirQuery,
mir_func: &MirFunction,
) -> Option<LoopFormIntake>
```
**変更内容**:
- `var_classes: &LoopVarClassBox` 引数を削除
- Trio を使わずに pinned/carrier hint を生成
- 実際の分類は呼び出し側が `LoopScopeShape::from_loop_form()` で実施
---
## 5. 拡張提案
### 5.1 現時点では拡張不要
LoopScopeShape は既に以下を提供している:
1. ✅ 変数分類（Pinned/Carrier/BodyLocalExit/BodyLocalInternal）
2. ✅ PHI 生成判定（header/exit）
3. ✅ 定義位置追跡（variable_definitions）
4. ✅ exit_live 計算（保守的近似）
5. ✅ 順序付き一覧（pinned_ordered/carriers_ordered）
**結論**: Phase 70 では既存 API のみで移行可能！
### 5.2 将来的な拡張候補（Phase 71+）
1. **精密 liveness 解析**（NYASH_EXIT_LIVE_ENABLE=1）
- 現在: 保守的近似（全変数を live とみなす）
- 将来: MIR スキャンによる精密解析（LoopFormOps 拡張後）
2. **Case-A 判定の統合**
- 現在: `is_case_a_minimal_target()` が func_name で判定
- 将来: LoopScopeShape に構造的判定を統合
3. **LoopFormIntake の統合**
- 現在: LoopFormIntake と LoopScopeShape が分離
- 将来: LoopScopeShape が LoopFormIntake の役割も吸収
---
## 6. 実装手順（Phase 70）
### 6.1 ステップ 1: intake_loop_form_v2() 実装
**ファイル**: `src/mir/join_ir/lowering/loop_form_intake.rs`
**変更内容**:
1. `intake_loop_form_v2()` を新規作成
2. `var_classes` 引数を削除
3. L169-182 の Trio 分類コードを削除
4. pinned_hint/carrier_hint をそのまま ordered_pinned/ordered_carriers に
**コード例**:
```rust
/// LoopForm + MIR から pinned/carrier hint を抽出する（Phase 70: Trio なし版）
pub(crate) fn intake_loop_form_v2(
loop_form: &crate::mir::loop_form::LoopForm,
query: &impl MirQuery,
mir_func: &MirFunction,
) -> Option<LoopFormIntake> {
// ... 既存の L31-167 までのコードは変更なし ...
// Phase 70: Trio 分類を削除
let ordered_pinned: Vec<String> = pinned_hint
.into_iter()
.collect::<BTreeSet<_>>()
.into_iter()
.collect();
let ordered_carriers: Vec<String> = carrier_hint
.into_iter()
.collect::<BTreeSet<_>>()
.into_iter()
.collect();
if ordered_pinned.is_empty() || ordered_carriers.is_empty() {
return None;
}
Some(LoopFormIntake {
pinned_ordered: ordered_pinned,
carrier_ordered: ordered_carriers,
header_snapshot: header_vals_mir,
exit_snapshots,
exit_preds,
})
}
```
### 6.2 ステップ 2: 呼び出し側の移行
**対象ファイル**:
- `src/mir/join_ir/lowering/mod.rs`（もしあれば）
- json_v0_bridge の関連ファイル
**変更内容**:
1. `intake_loop_form()` → `intake_loop_form_v2()` に切り替え
2. Trio 生成コードを削除
3. `LoopScopeShape::from_existing_boxes()` → `LoopScopeShape::from_loop_form()` に変更
**コード例**:
```rust
// Before
let var_classes = LoopVarClassBox::new();
let exit_live_box = LoopExitLivenessBox::new();
let intake = intake_loop_form(loop_form, &var_classes, query, mir_func)?;
let scope = LoopScopeShape::from_existing_boxes(
loop_form, &intake, &var_classes, &exit_live_box, query, func_name
)?;
// After
let intake = intake_loop_form_v2(loop_form, query, mir_func)?;
let scope = LoopScopeShape::from_loop_form(loop_form, &intake, query, func_name)?;
```
### 6.3 ステップ 3: テスト確認
**テスト対象**:
1. `loop_scope_shape/tests.rs` のテストが全て PASS
2. JoinIR lowering 系のテスト（json_v0_bridge 経由）
3. 既存の PHI 生成テスト（267/268 PASS 維持）
**確認コマンド**:
```bash
# 単体テスト
cargo test --release loop_scope_shape
# JoinIR lowering テスト
cargo test --release joinir
# 全テスト（退行チェック）
cargo test --release
```
### 6.4 ステップ 4: 旧関数の deprecation
**ファイル**: `src/mir/join_ir/lowering/loop_form_intake.rs`
**変更内容**:
```rust
/// 旧版（Phase 70 で deprecation 予定）
#[deprecated(since = "Phase 70", note = "Use intake_loop_form_v2() instead")]
pub(crate) fn intake_loop_form(
loop_form: &crate::mir::loop_form::LoopForm,
var_classes: &LoopVarClassBox,
query: &impl MirQuery,
mir_func: &MirFunction,
) -> Option<LoopFormIntake> {
// 互換性のため一時的に残す
intake_loop_form_v2(loop_form, query, mir_func)
}
```
### 6.5 ステップ 5: ドキュメント更新
**対象ファイル**:
- `src/mir/join_ir/lowering/loop_form_intake.rs` の冒頭コメント
- `src/mir/join_ir/lowering/loop_scope_shape/builder.rs` の Phase 48-6 コメント
**追加内容**:
```rust
//! # Phase 70: Trio 依存排除完了
//!
//! - intake_loop_form_v2(): Trio を使わずに hint のみを抽出
//! - LoopScopeShape::from_loop_form(): Trio を内部化して分類実施
//! - json_v0_bridge: Trio 依存ゼロ達成！
```
---
## 7. 移行の安全性保証
### 7.1 退行防止策
1. **段階的移行**: intake_loop_form_v2() を新規作成し、旧関数を deprecation
2. **既存テストの維持**: 267/268 PASS を維持
3. **互換レイヤー**: 旧関数から新関数を呼び出して動作検証
### 7.2 検証ポイント
| 項目 | 検証方法 | 期待結果 |
|------|---------|---------|
| PHI 生成 | 既存テスト実行 | 267/268 PASS 維持 |
| pinned/carrier 判定 | loop_scope_shape tests | 全 PASS |
| exit_live 計算 | JoinIR lowering テスト | 変化なし |
| MIR パース | preheader 変数抽出 | s/n/i 正常抽出 |
### 7.3 ロールバック計画
Phase 70 で問題が発生した場合:
1. `intake_loop_form_v2()` を削除
2. 旧 `intake_loop_form()` に戻す
3. Trio 依存を一時的に復活
4. 問題を調査して Phase 71 で再挑戦
---
## 8. 期待される効果
### 8.1 コード削減
| ファイル | Before | After | 削減率 |
|---------|--------|-------|-------|
| loop_form_intake.rs | 211行 | 197行 | **7% 削減** |
| json_v0_bridge 系 | Trio 生成コード | 削除 | **10-15行削減** |
### 8.2 設計改善
1. **責務の明確化**:
- loop_form_intake: MIR パース + hint 生成
- LoopScopeShape: 変数分類の SSOT
2. **依存の整理**:
- json_v0_bridge: Trio を知らない
- LoopScopeShape: Trio を内部化（builder.rs のみ）
3. **保守性向上**:
- 分類ロジックの重複を解消
- LoopScopeShape が唯一の分類実装に
### 8.3 Phase 48-6 設計の完成
Phase 48-6 の目標「Trio を builder.rs のみに封じ込める」が完全達成:
- ✅ json_v0_bridge: Trio 依存ゼロ
- ✅ loop_form_intake: Trio 呼び出しゼロ
- ✅ LoopScopeShape: Trio を内部化（builder.rs のみ知る）
---
## 9. 補足: LoopScopeShape::from_loop_form() の既存実装
Phase 48-2 で既に実装済み（`builder.rs` L64-81）:
```rust
/// Trio 引数なしで LoopScopeShape を構築（Trio 内部化）
pub(crate) fn from_loop_form(
loop_form: &LoopForm,
intake: &LoopFormIntake,
query: &impl MirQuery,
func_name: Option<&str>,
) -> Option<Self> {
let var_classes = LoopVarClassBox::new();
let exit_live_box = LoopExitLivenessBox::new();
Self::from_existing_boxes(
loop_form,
intake,
&var_classes,
&exit_live_box,
query,
func_name,
)
}
```
**重要な発見**:
- Trio の生成は **既に LoopScopeShape 内部で完結**！
- json_v0_bridge が Trio を渡す必要は **全くない**！
- Phase 70 は「呼び出し側を既存 API に変えるだけ」で完了！
---
## 10. まとめ
### 10.1 設計の核心
1. **loop_form_intake.rs**: Trio 分類を削除し、hint 抽出のみに専念
2. **LoopScopeShape::from_loop_form()**: 既存実装を活用（変更不要）
3. **json_v0_bridge**: Trio 生成コードを削除し、from_loop_form() を呼ぶだけ
### 10.2 Phase 70 の作業量
- **新規実装**: intake_loop_form_v2()（14行削減版）
- **呼び出し側修正**: Trio 生成コードの削除
- **テスト確認**: 既存テスト実行（267/268 PASS 維持）
**見積もり**: 1-2時間の実装 + 30分のテスト確認 = **合計 2.5時間**
### 10.3 Phase 70 完了後の状態
```
json_v0_bridge/
└─ lowering/
└─ loop_.rs
├─ intake_loop_form_v2() 呼び出し（Trio なし）
└─ LoopScopeShape::from_loop_form() 呼び出し（Trio 内部化）
loop_scope_shape/
└─ builder.rs
├─ from_loop_form() が Trio を内部生成
└─ from_existing_boxes_legacy() が Trio を使用（Phase 48-6 境界）
loop_form_intake.rs
├─ intake_loop_form_v2() 実装（Trio なし、hint のみ）
└─ intake_loop_form() deprecation（互換性維持）
```
**Phase 48-6 設計の完全実現**: Trio は builder.rs のみが知る層！
---
## Phase 70 実装 Checklist
- [ ] Step 1: intake_loop_form_v2() 実装（loop_form_intake.rs）
- [ ] Step 2: json_v0_bridge の呼び出し側修正
- [ ] Step 3: テスト確認（267/268 PASS 維持）
- [ ] Step 4: intake_loop_form() に deprecation マーク
- [ ] Step 5: ドキュメント更新（Phase 70 完了記録）
- [ ] Step 6: コミット（退行なし確認済み）
**実装準備完了！Phase 70 で Trio 依存ゼロを達成しよう！** 🚀
Status: Historical

5
docs/archive/phases/phase-71/README.md Normal file
View File

@ -0,0 +1,5 @@
# Phase 71 Archive (SSA/selfhost 再ブートストラップ観測)
Status: Historical
Scope: SSA trim 再起動時の観測・修正メモ（Phase 71 系）。

185
docs/archive/phases/phase-71/phase71-findings-20251202.md Normal file
View File

@ -0,0 +1,185 @@
# Phase 71 Findings - SSA/selfhost 再ブートストラップ観測報告
**実施日**: 2025-12-02
**担当**: Claude (Phase 70完了直後にPhase 71開始)
---
## 📊 観測結果サマリー
### 代表パス実行状況
```bash
NYASH_ROOT=/home/tomoaki/git/hakorune-selfhost \
NYASH_FEATURES=stage3 \
NYASH_USE_NY_COMPILER=1 \
NYASH_NY_COMPILER_EMIT_ONLY=1 \
NYASH_SELFHOST_KEEP_RAW=1 \
./tools/selfhost/selfhost_build.sh --in apps/tests/stage1_run_min.hako --run
```
**結果**:
- ✅ **Stage-B compiler実行成功** (`rc_stageb=0`)
- ❌ **Program JSON抽出失敗** (`extract_ok=0`)
- ❌ **Program JSON行数: 0件** (emit失敗)
### RAWログ
**Location**: `/home/tomoaki/git/hakorune-selfhost/logs/selfhost/stageb_20251202_101623_2665649.log`
**Size**: 707K
---
## 🔍 根本原因分析
### 1. SSA undef警告 (4件)
**影響関数**:
1. `ParserCommonUtilsBox.trim/1`
- `Copy { dst: ValueId(2), src: ValueId(272) }` at `BasicBlockId(787)`
- ValueId(272)が未定義
2. `ParserBox.trim/1`
- `Copy { dst: ValueId(4), src: ValueId(272) }` at `BasicBlockId(2479)`
- ValueId(272)が未定義
3. `Main._parse_number/1`
- `Copy { dst: ValueId(2), src: ValueId(12) }` at `BasicBlockId(6708)`
- ValueId(12)が未定義
4. `ParserBox.parse_block2/2`
- `Copy { dst: ValueId(5), src: ValueId(440) }` at `BasicBlockId(2573)`
- ValueId(440)が未定義
**パターン**: すべてCopy命令で未定義ValueIdをコピーしようとしている
### 2. dev verify警告 (1件)
```
[warn] dev verify: NewBox StageBDriverBox at v%366 not followed by birth() call
(expect StageBDriverBox.birth/0)
```
**影響**: StageBDriverBoxの初期化手順が不完全
---
## 🎯 Phase 71-SSA側の課題
### 課題1: trim系関数のSSA undef
**影響範囲**:
- `ParserCommonUtilsBox.trim/1`
- `ParserBox.trim/1`
**想定原因**:
- レシーバ引数の受け渡しでValueIdが未定義のまま渡されている
- 関数呼び出し時のパラメータマッピングに問題がある可能性
**対応方針** (Phase 71-SSA-debug/TASKS.md):
1. `lang/src/compiler/parser/common_utils.hako` の `trim/1` 実装を確認
2. 呼び出し側での引数渡しパターンを確認
3. 必要に応じて `skip_ws` ベースの実装に統一（前回修正パターン適用）
### 課題2: Stage-B DriverBox birth警告
**影響**:
- `StageBDriverBox` が NewBox直後にbirth()を呼んでいない
**対応方針**:
- `apps/selfhost-compiler/compiler.hako` のStageBDriverBox使用箇所を確認
- birth()呼び出しを追加（または不要な場合は警告を緩和）
### 課題3: Program JSON未出力
**状況**:
- Stage-B rc=0 (エラーなし)
- しかしProgram JSON行が0件
**想定原因**:
- SSA undef や dev verify警告により、JSON出力処理に到達する前に処理が中断している可能性
- または JSON出力ロジック自体に問題がある可能性
**対応方針**:
1. `NYASH_STAGEB_DEV_VERIFY=0` で dev verify無効化して比較
2. Stage-B DriverBox の Program JSON出力箇所にトレースログ追加
3. SSA undef解消後に再度実行して状況確認
---
## 📋 Phase 71次のステップ
### ステップ1: SSA undef優先修正
- `trim/1` 系関数のSSA undef解消
- 前回の `_trim/1` 修正パターン（ダミーカンマ＋静的呼び出し統一）を適用
### ステップ2: dev verify緩和トグル活用
- `NYASH_STAGEB_DEV_VERIFY=0` での実行比較
- Program JSON出力復活の有無を確認
### ステップ3: Stage-B DriverBox トレース強化
- Program JSON出力直前のトレースログ追加
- 処理フローの可視化
### ステップ4: 代表パス安定化
- SSA undef全解消
- dev verify警告を0件に
- Program JSON emit成功を確認
---
## 🔗 関連ドキュメント
- **Phase 71 README**: `docs/private/roadmap2/phases/phase-71-selfhost-reboot/README.md`
- **Phase 71-SSA README**: `docs/private/roadmap2/phases/phase-71-ssa-debug/README.md`
- **Phase 71-SSA TASKS**: `docs/private/roadmap2/phases/phase-71-ssa-debug/TASKS.md`
- **CURRENT_TASK.md**: Line 112-119 (Phase 71-SSA観測停止中メモ)
---
## 💡 重要な気づき
### JoinIR は問題なし
- `[joinir/vm_bridge]` ログから、JoinIRパスは正常動作している
- `FuncScannerBox.trim` は JoinIR経路で正常に lowering されている
- **Phase 71-SSAの問題は「JoinIRとは無関係」**
### プラグイン初期化も問題なし
- `[UnifiedBoxRegistry] 🎯 Factory Policy: StrictPluginFirst` 成功
- `[provider-registry] FileBox: using registered provider` 成功
- **Phase 71-SSAの問題は「プラグインとも無関係」**
### 真の問題箇所
- **SSA/Stage-B MIR生成時の ValueId未定義問題**
- **StageBDriverBox の初期化手順不備**
- これらが複合的にProgram JSON emit失敗を引き起こしている
---
## 📝 Phase 71完了判定基準
- [ ] SSA undef警告: 4件 → 0件
- [ ] dev verify警告: 1件 → 0件
- [ ] Program JSON抽出: 0件 → 1件以上
- [ ] 代表パス `selfhost_build + stage1_run_min.hako` が GREEN
**現在の状況**: 0/4基準達成（観測窓としての役割は完了）
---
## 🎯 次のフェーズへの引き継ぎ
**Phase 71の成果**:
- ✅ Phase 70完了直後にPhase 71実行成功
- ✅ RAW観測レイヤ活用成功
- ✅ SSA undef根本原因特定（trim系関数の未定義ValueId問題）
- ✅ JoinIR/プラグインは無関係であることを確認
**Phase 71-SSA-debugへの課題引き継ぎ**:
- trim系関数 SSA undef 修正（4件 → 0件）
- StageBDriverBox birth警告 解消（1件 → 0件）
- Program JSON emit 復活（0件 → 1件以上）
---
**備考**: このドキュメントは Phase 71初回実行の観測結果を記録したものです。
SSA undef修正作業は Phase 71-SSA-debug側で継続します。
Status: Historical

248
docs/archive/phases/phase-71/phase71-ssa-trim-fix-20251202.md Normal file
View File

@ -0,0 +1,248 @@
# Phase 71-SSA: trim系 SSA undef 完全解消レポート
**実施日**: 2025-12-02
**担当**: Claude + Task先生
---
## 🎉 エグゼクティブサマリー
**SSA undef 完全解消達成！**
- **修正前**: 4件の SSA undef
- **修正後**: **0件** (100%解消！)
**修正内容**:
1. ParserStringUtilsBox.trim - `StringHelpers.skip_ws` → `ParserStringUtilsBox.skip_ws` (Quick Win)
2. ParserCommonUtilsBox.trim - 委譲を廃止、直接実装に変更
3. ParserBox.trim - 委譲を廃止、直接実装に変更
**所要時間**: 約2時間 (調査 + 実装 + 検証)
---
## 📊 SSA undef 推移
| フェーズ | SSA undef件数 | 詳細 |
|---------|--------------|------|
| Phase 71初回観測 | **4件** | ParserCommonUtilsBox.trim/1, ParserBox.trim/1, Main._parse_number/1, ParserBox.parse_block2/2 |
| Quick Win修正後 | **2件** | ParserCommonUtilsBox.trim/1, ParserBox.trim/1 (予想外の効果: _parse_number/parse_block2 消滅) |
| 修正案A実装後 | **0件** | 🎉 完全解消！ |
---
## 🔍 根本原因の特定 (Task先生による分析)
### ValueId(272)の正体
- **`StringHelpers.starts_with_kw/3`の戻り値**
- ParserCommonUtilsBox.trim/1 の**引数として誤って参照**されていた
### 問題の本質
**static boxの委譲でValueIdマッピング失敗**:
```hako
// ParserCommonUtilsBox.trim (問題あり)
trim(s) {
return ParserStringUtilsBox.trim(s) // ← 引数sのValueIdマッピングが失敗
}
```
**ログ証拠**:
```
[ssa-undef-debug] fn=ParserCommonUtilsBox.trim/1 bb=BasicBlockId(800) inst_idx=0
used=ValueId(272) inst=Copy { dst: ValueId(2), src: ValueId(272) }
```
**注目点**: 引数パラメータ設定ログが一切出力されていない
---
## 🛠️ 修正内容の詳細
### 修正1: ParserStringUtilsBox.trim (Quick Win)
**ファイル**: `lang/src/compiler/parser/scan/parser_string_utils_box.hako`
**変更箇所** (L76):
```hako
// 修正前
local b = StringHelpers.skip_ws(str, 0) // インスタンスメソッド呼び出し
// 修正後
local b = ParserStringUtilsBox.skip_ws(str, 0) // 静的呼び出し
```
**効果**:
- SSA undef 4件 → 2件
- **予想外の副次効果**: Main._parse_number と ParserBox.parse_block2 が消滅
### 修正2: ParserCommonUtilsBox.trim (修正案A)
**ファイル**: `lang/src/compiler/parser/scan/parser_common_utils_box.hako`
**変更内容** (L50-69):
```hako
// 修正前 (委譲パターン)
trim(s) {
// Delegate to string_utils to keep SSA/semantic consistency.
return ParserStringUtilsBox.trim(s)
}
// 修正後 (直接実装)
trim(s) {
// Phase 71-SSA: Direct implementation to avoid ValueId mapping issue in static box delegation
if s == null { return "" }
local str = "" + s
local n = str.length()
// Leading whitespace: use static method to avoid SSA undef
local b = ParserStringUtilsBox.skip_ws(str, 0)
if b >= n { return "" }
// Trailing whitespace: walk backwards until a non-space is found.
local e = n
loop(e > b) {
local ch = str.substring(e - 1, e)
if ch == " " || ch == "\t" || ch == "\n" || ch == "\r" || ch == ";" { e = e - 1 } else { break }
}
if e > b { return str.substring(b, e) }
return ""
}
```
### 修正3: ParserBox.trim (修正案A)
**ファイル**: `lang/src/compiler/parser/parser_box.hako`
**変更内容** (L81-98):
- ParserCommonUtilsBox.trim と同じパターンで直接実装に変更
---
## ✅ 成功パターンとの比較
### FuncScannerBox.trim (成功パターン)
- **box宣言** (通常のbox)
- **methodキーワード**使用
- **同じbox内のメソッド**呼び出し
- **二重委譲なし**
- ✅ SSA undef なし
### ParserStringUtilsBox.trim (失敗パターン→成功)
- **static box宣言**
- **methodキーワードなし**
- **別boxの関数**呼び出し (修正後は同じbox)
- **二重委譲あり** (skip_ws → StringHelpers.skip_ws)
- ✅ 修正後 SSA undef なし
### ParserCommonUtilsBox.trim (失敗パターン→成功)
- **static box宣言**
- **methodキーワードなし**
- **委譲パターン** (修正前)
- ✅ 修正後: 直接実装で SSA undef 解消
---
## 📈 検証結果
### 最終確認
```bash
NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_NY_COMPILER_EMIT_ONLY=1 \
NYASH_SELFHOST_KEEP_RAW=1 ./tools/selfhost/selfhost_build.sh \
--in apps/tests/stage1_run_min.hako --run
```
**結果**:
```
[warn] dev verify: NewBox StageBDriverBox at v%366 not followed by birth() call
[warn] dev verify: NewBox→birth invariant warnings: 1
[selfhost/debug] RAW log: .../stageb_20251202_111409_2674670.log
SSA undef 件数: 0 ← 🎉 完全解消！
```
**RAWログ確認**:
```bash
grep -c 'ssa-undef-debug' logs/selfhost/stageb_20251202_111409_2674670.log
# 出力: 0
```
---
## 🎯 残存課題
### 1. dev verify警告 (1件)
```
[warn] dev verify: NewBox StageBDriverBox at v%366 not followed by birth() call
```
- **対象**: StageBDriverBox
- **対応**: Phase 71-SSA次フェーズで実施
### 2. Program JSON未出力
```
[selfhost/raw] rc_stageb=0 extract_ok=0
```
- **状況**: Stage-B rc=0 (実行成功) だが Program JSON 行なし
- **原因**: SSA undef 以外の問題 (dev verify? または別の要因)
- **対応**: 次フェーズでトレース追加して調査
---
## 💡 重要な教訓
### 1. static boxの委譲は危険
- **ValueIdマッピング**が正しく行われない可能性
- 引数パラメータ設定ログが出ないケースあり
- **推奨**: 委譲を避け、直接実装を選択
### 2. 静的呼び出しの重要性
- `BoxName.method()` → SSA-friendly
- `using経由のBox.method()` → インスタンスメソッド呼び出しのリスク
- **推奨**: 同じbox内のメソッドを静的呼び出し
### 3. 成功パターンの活用
- FuncScannerBox.trim の実装パターンを参考
- 既存の成功事例を積極的に再利用
---
## 📝 次のアクション
### Phase 71-SSA次フェーズ
1. **StageBDriverBox birth警告解消** (1件 → 0件)
2. **Program JSON emit調査**
- StageBDriverBox.main にトレース追加
- RAWログで出口まで到達しているか確認
3. **最終目標**: `selfhost_build + stage1_run_min.hako` で Program JSON emit成功
---
## 🤖 AI協働成果
### Task先生の貢献
- ✅ ValueId(272) の正体特定
- ✅ static box委譲問題の発見
- ✅ 修正案A-C の提案
- ✅ FuncScannerBox.trim との比較分析
### Claude実装
- ✅ Quick Win (30分で2件削減)
- ✅ 修正案A実装 (委譲廃止で残り2件解消)
- ✅ 検証・ドキュメント化
**合計所要時間**: 約2時間 (Task先生調査含む)
---
## 📚 関連ドキュメント
- **Phase 71初回観測**: `phase71-findings-20251202.md`
- **Phase 71-SSA README**: `docs/private/roadmap2/phases/phase-71-ssa-debug/README.md`
- **Phase 71-SSA TASKS**: `docs/private/roadmap2/phases/phase-71-ssa-debug/TASKS.md`
- **CURRENT_TASK.md**: Phase 71-SSA進捗記録
---
**Phase 71-SSA SSA undef 削減完了判定**: ✅ **100%達成！**
**次のマイルストーン**: dev verify警告解消 + Program JSON emit復活
Status: Historical

5
docs/archive/phases/phase-72-73/README.md Normal file
View File

@ -0,0 +1,5 @@
# Phase 72-73 Archive (ENV 使用状況棚卸し)
Status: Historical
Scope: ENV/JoinIR 整理に関する棚卸しメモ（Phase 72-73）。

644
docs/archive/phases/phase-72-73/phase72-73-env-inventory.md Normal file
View File

@ -0,0 +1,644 @@
# Phase 72-73 ENV 使用状況棚卸し（ENV/JoinIR整理）
**調査日**: 2025-12-02
**目的**: Stage-3 / JoinIR / selfhost 関連の ENV 使用状況を洗い出し、Phase 72-73 整理の優先順位を決定する。
---
## 📊 Executive Summary（総括）
### 全体傾向
- **Stage-3 関連**: 既に `NYASH_FEATURES=stage3` への移行が進行中（96箇所のスクリプトで使用）
- **JoinIR 関連**: `NYASH_JOINIR_EXPERIMENT` 系が実験モードとして広く使用（直接読み込み多数）
- **直接読み込み問題**: JoinIR系で20ファイル以上が `std::env::var()` 直接読み込み → SSOT整理が急務
### 優先順位（推奨整理順）
1. **CRITICAL**: JoinIR 直接読み込みの SSOT 化（20+ファイル）
2. **HIGH**: `HAKO_JOINIR_*` の統合整理（12種類のENV、一部は実験用）
3. **MEDIUM**: Stage-3 legacy ENV の完全削除（`NYASH_PARSER_STAGE3`, `HAKO_PARSER_STAGE3`）
4. **LOW**: `NYASH_FEATURES=stage3` のデフォルト化完了確認
---
## 1. Stage-3 関連 ENV
### 1.1 `NYASH_PARSER_STAGE3`
**使用箇所総数**: 62箇所
#### カテゴリ別内訳
- **Rust SSOT経由**: 2箇所（config/env.rs での定義のみ）
- `src/config/env.rs:715` - `env_flag("NYASH_PARSER_STAGE3")` で読み込み
- `src/mir/builder.rs:538` - エラーメッセージでの言及のみ
- **Rust 直接読み込み**: 27箇所（⚠️ **問題箇所**）
- `tests/parser_stage3.rs`: 5箇所（テスト用 set/remove_var）
- `tests/mir_*.rs`: 18箇所（テスト用 set_var）
- `src/tests/*.rs`: 4箇所（テスト用 set_var）
- **Scripts**: 35箇所
- `tools/selfhost/*.sh`: 12箇所
- `tools/dev/*.sh`: 8箇所
- `tools/smokes/*.sh`: 2箇所
- `tools/hako_check/*.sh`: 1箇所
- その他: 12箇所
- **Child env 伝播**: 2箇所
- `src/runner/child_env.rs:57-58`
- `src/runner/stage1_bridge/env.rs:131-132`
#### 現状
- ✅ **SSOT関数**: `config::env::parser_stage3_enabled()` が定義済み
- ✅ **優先順位**: `NYASH_FEATURES=stage3` > `NYASH_PARSER_STAGE3` > `HAKO_PARSER_STAGE3` > デフォルトtrue
- ⚠️ **問題**: テストでの直接読み込みが27箇所残存
- 📌 **推奨**: legacy ENV として deprecation warning を既に出力中（config/env.rs:716）
---
### 1.2 `HAKO_PARSER_STAGE3`
**使用箇所総数**: 46箇所
#### カテゴリ別内訳
- **Rust SSOT経由**: 2箇所（config/env.rs での定義のみ）
- `src/config/env.rs:719` - `env_flag("HAKO_PARSER_STAGE3")` で読み込み
- `src/mir/builder.rs:538` - エラーメッセージでの言及のみ
- **Rust 直接読み込み**: 19箇所（⚠️ **問題箇所**）
- `tests/parser_stage3.rs`: 5箇所（テスト用 set/remove_var）
- `tests/mir_*.rs`: 12箇所（テスト用 set_var）
- `src/runner/child_env.rs`: 2箇所（子プロセスへの伝播）
- **Scripts**: 25箇所
- `tools/selfhost/*.sh`: 10箇所
- `tools/dev/*.sh`: 7箇所
- `tools/smokes/v2/*.sh`: 2箇所
- その他: 6箇所
- **Child env 伝播**: 2箇所
- `src/runner/child_env.rs:57-58`
- `src/runner/stage1_bridge/env.rs:131-132`
#### 現状
- ✅ **SSOT関数**: `config::env::parser_stage3_enabled()` が定義済み（共通関数）
- ✅ **優先順位**: `NYASH_FEATURES=stage3` > `NYASH_PARSER_STAGE3` > `HAKO_PARSER_STAGE3` > デフォルトtrue
- ⚠️ **問題**: テストでの直接読み込みが19箇所残存
- 📌 **推奨**: legacy ENV として deprecation warning を既に出力中（config/env.rs:720）
---
### 1.3 `NYASH_FEATURES=stage3`
**使用箇所総数**: 144箇所（推定）
#### カテゴリ別内訳
- **Rust SSOT経由**: 21箇所
- `src/config/env.rs` の `feature_stage3_enabled()` → `parser_stage3_enabled()` 経由
- Parser、Builder、Runner など主要モジュールで使用
- **Rust 直接設定**: 15箇所（テストでの `std::env::set_var("NYASH_FEATURES", "stage3")`）
- `src/tests/mir_stage1_using_resolver_verify.rs`
- `src/tests/stage1_cli_entry_ssa_smoke.rs`
- `src/tests/mir_joinir_*.rs` など
- **Scripts**: 96箇所（`tools/smokes/v2/` が主体）
- `tools/smokes/v2/profiles/quick/`: 多数
- `tools/smokes/v2/lib/stageb_helpers.sh`: 4箇所
- `tools/smokes/v2/lib/test_runner.sh`: 7箇所
- **Child env 伝播**: 3箇所
- `src/runner/stage1_bridge/env.rs:118-124` - Stage-3フラグの自動伝播
- `src/runner/child_env.rs:52` - Stage-3フラグの明示的設定
#### 現状
- ✅ **SSOT関数**: `config::env::feature_stage3_enabled()` が定義済み
- ✅ **デフォルト**: `parser_stage3_enabled()` が `true` を返す（Stage-3は標準構文化済み）
- ✅ **移行完了度**: 高（96箇所のスクリプトで採用）
- 📌 **推奨**: legacy ENV の完全削除に向けた最終段階
---
## 2. JoinIR 関連 ENV
### 2.1 `NYASH_JOINIR_CORE`
> 2025-12 現在: JoinIR は常時 ON。`NYASH_JOINIR_CORE` は警告のみで無視される（LoopBuilder 削除済み、config/env で no-op）。
**使用箇所総数**: 9箇所
#### カテゴリ別内訳
- **Rust SSOT経由**: 1箇所
- `src/config/env.rs:242` - `env_flag("NYASH_JOINIR_CORE")` で読み込み
- **Rust 直接読み込み**: 6箇所（⚠️ **問題箇所**）
- `src/tests/mir_stage1_staticcompiler_receiver.rs:39` - `std::env::set_var("NYASH_JOINIR_CORE", "1")`
- `src/tests/mir_joinir_if_select.rs:14,19` - set/remove_var
- `src/tests/mir_joinir_stage1_using_resolver_min.rs:31` - set_var
- `src/tests/helpers/joinir_env.rs:7,12,17` - set/remove_var helper
- **Scripts**: 0箇所
- **Tests**: 6箇所（全てテストヘルパー経由）
#### 現状
- ✅ **SSOT関数**: `config::env::joinir_core_enabled()` が定義済み
- ⚠️ **問題**: テストでの直接読み込みが6箇所残存
- 📌 **推奨**: `tests/helpers/joinir_env.rs` のヘルパー関数を SSOT 化
---
### 2.2 `NYASH_JOINIR_DEV`
**使用箇所総数**: 2箇所
#### カテゴリ別内訳
- **Rust SSOT経由**: 2箇所
- `src/config/env.rs:325` - `env_bool("NYASH_JOINIR_DEV")` 定義
- `src/config/env.rs:328` - `joinir_dev_enabled()` での参照
- **Rust 直接読み込み**: 0箇所（✅ **SSOT完璧**）
- **Scripts**: 0箇所
#### 現状
- ✅ **SSOT関数**: `config::env::joinir_dev_enabled()` が定義済み
- ✅ **完璧な状態**: 全てSSAT経由、直接読み込みなし
- 📌 **推奨**: 現状維持（モデルケース）
---
### 2.3 `NYASH_JOINIR_STRICT`
**使用箇所総数**: 6箇所
#### カテゴリ別内訳
- **Rust SSOT経由**: 2箇所
- `src/config/env.rs:263,265` - `env_flag("NYASH_JOINIR_STRICT")` 定義
- **Rust 直接読み込み**: 4箇所（⚠️ **問題箇所**）
- `src/tests/mir_joinir_stage1_using_resolver_min.rs:32` - `std::env::set_var("NYASH_JOINIR_STRICT", "1")`
- `src/tests/mir_joinir_if_select.rs:15,20` - set/remove_var
- `src/tests/mir_stage1_staticcompiler_receiver.rs:40` - set_var
- **Scripts**: 0箇所
#### 現状
- ✅ **SSOT関数**: `config::env::joinir_strict_enabled()` が定義済み
- ⚠️ **問題**: テストでの直接読み込みが4箇所残存
- 📌 **推奨**: `tests/helpers/joinir_env.rs` にヘルパー追加
---
### 2.4 `NYASH_JOINIR_EXPERIMENT`
**使用箇所総数**: 49箇所
#### カテゴリ別内訳
- **Rust SSOT経由**: 7箇所
- `src/config/env.rs:234` - `env_bool("NYASH_JOINIR_EXPERIMENT")` 定義
- `src/runner/modes/vm.rs`, `llvm.rs` など主要実行器で参照
- **Rust 直接読み込み**: 39箇所（⚠️ **深刻な問題**）
- `src/tests/mir_joinir_*.rs`: 15箇所（実験モードチェック）
- `src/tests/joinir_*.rs`: 10箇所（実験モードチェック）
- `src/mir/join_ir/`: 5箇所（条件付き有効化）
- `src/mir/phi_core/loopform_builder.rs:81` - コメント言及
- その他: 9箇所
- **Scripts**: 3箇所
- `tools/joinir_ab_test.sh`: 4箇所
- **Tests**: 36箇所（テストスキップ判定）
#### 現状
- ✅ **SSOT関数**: `config::env::joinir_experiment_enabled()` が定義済み
- ❌ **深刻な問題**: 直接読み込みが39箇所残存（最多）
- 📌 **推奨**: **Phase 72 最優先タスク** - 全テストを SSOT 化
---
### 2.5 `HAKO_JOINIR_*` 系（12種類）
#### 2.5.1 `HAKO_JOINIR_IF_SELECT`
**使用箇所総数**: 19箇所
- **Rust SSOT経由**: 3箇所（config/env.rs）
- **Rust 直接読み込み**: 13箇所（テスト用 set/remove_var）
- `src/tests/mir_joinir_if_select.rs`: 9箇所
- `src/tests/helpers/joinir_env.rs`: 2箇所
- **Scripts**: 0箇所
**SSOT関数**: `config::env::joinir_if_select_enabled()` ✅
---
#### 2.5.2 `HAKO_JOINIR_DEBUG`
**使用箇所総数**: 20箇所
- **Rust SSOT経由**: 4箇所（config/env.rs）
- **Rust 直接読み込み**: 0箇所（✅ **完璧**）
- **使用関数**: `config::env::joinir_debug_level()` → 返り値 0-3
**SSOT関数**: `config::env::joinir_debug_level()` ✅（完璧な例）
---
#### 2.5.3 `HAKO_JOINIR_STAGE1`
**使用箇所総数**: 3箇所
- **Rust SSOT経由**: 2箇所（config/env.rs での定義のみ）
- **Rust 直接読み込み**: 0箇所（✅ **完璧**）
- **Scripts**: 0箇所
**SSOT関数**: `config::env::joinir_stage1_enabled()` ✅（未使用だが準備済み）
---
#### 2.5.4 `HAKO_JOINIR_IF_IN_LOOP_DRYRUN`
**使用箇所総数**: 4箇所
- **Rust SSOT経由**: 2箇所（config/env.rs + 関数使用2箇所）
- **Rust 直接読み込み**: 2箇所（テスト用 set/remove_var）
- `src/tests/phase61_if_in_loop_dryrun.rs:13,16`
**SSOT関数**: `config::env::joinir_if_in_loop_dryrun_enabled()` ✅
---
#### 2.5.5 `HAKO_JOINIR_IF_IN_LOOP_ENABLE`
**使用箇所総数**: 3箇所
- **Rust SSOT経由**: 3箇所（config/env.rs + 関数使用）
- **Rust 直接読み込み**: 0箇所（✅ **完璧**）
**SSOT関数**: `config::env::joinir_if_in_loop_enable()` ✅
---
#### 2.5.6 `HAKO_JOINIR_IF_TOPLEVEL`
**使用箇所総数**: 3箇所
- **Rust SSOT経由**: 3箇所（config/env.rs + 関数使用）
- **Rust 直接読み込み**: 0箇所（✅ **完璧**）
**SSOT関数**: `config::env::joinir_if_toplevel_enabled()` ✅
---
#### 2.5.7 `HAKO_JOINIR_IF_TOPLEVEL_DRYRUN`
**使用箇所総数**: 2箇所
- **Rust SSOT経由**: 2箇所（config/env.rs での定義のみ）
- **Rust 直接読み込み**: 0箇所（✅ **完璧**）
**SSOT関数**: `config::env::joinir_if_toplevel_dryrun_enabled()` ✅（未使用だが準備済み）
---
#### 2.5.8 `HAKO_JOINIR_PRINT_TOKENS_MAIN` / `HAKO_JOINIR_ARRAY_FILTER_MAIN`
**使用箇所総数**: 10箇所
- **Rust SSOT経由**: 0箇所（❌ **SSOT未定義**）
- **Rust 直接読み込み**: 6箇所（⚠️ **問題箇所**）
- `src/mir/builder/control_flow.rs:92,102` - 直接読み込み
- `src/tests/joinir/mainline_phase49.rs`: 4箇所（set/remove_var）
- **Scripts**: 0箇所
**SSOT関数**: ❌ **未定義**（dev専用フラグ）
---
#### 2.5.9 `HAKO_JOINIR_IF_IN_LOOP_TRACE` / `HAKO_JOINIR_IF_TOPLEVEL_TRACE`
**使用箇所総数**: 2箇所
- **Rust SSOT経由**: 0箇所（❌ **SSOT未定義**）
- **Rust 直接読み込み**: 2箇所（⚠️ **問題箇所**）
- `src/mir/loop_builder/if_in_loop_phi_emitter.rs:72,184` - 直接読み込み
**SSOT関数**: ❌ **未定義**（trace専用フラグ）
---
#### 2.5.10 `HAKO_JOINIR_READ_QUOTED` / `HAKO_JOINIR_READ_QUOTED_IFMERGE`
**使用箇所総数**: 8箇所
- **Rust SSOT経由**: 0箇所（❌ **SSOT未定義**）
- **Rust 直接読み込み**: 8箇所（⚠️ **問題箇所**）
- `src/mir/join_ir_vm_bridge/tests.rs`: 4箇所（テストスキップ判定）
- `src/mir/join_ir/frontend/ast_lowerer/tests.rs`: 3箇所（テストスキップ判定）
- `src/mir/join_ir/frontend/ast_lowerer/read_quoted.rs:351` - 条件分岐
**SSOT関数**: ❌ **未定義**（実験フラグ）
---
#### 2.5.11 `HAKO_JOINIR_NESTED_IF`
**使用箇所総数**: 7箇所
- **Rust SSOT経由**: 0箇所（❌ **SSOT未定義**）
- **Rust 直接読み込み**: 7箇所（⚠️ **問題箇所**）
- `src/mir/join_ir/frontend/ast_lowerer/mod.rs:107,122` - 条件分岐
- `src/mir/join_ir/frontend/ast_lowerer/tests.rs`: 2箇所（テストスキップ判定）
- `src/tests/phase41_nested_if_merge_test.rs`: 3箇所（テストスキップ判定）
**SSOT関数**: ❌ **未定義**（実験フラグ）
---
#### 2.5.12 `HAKO_JOINIR_IF_SELECT_DRYRUN`
**使用箇所総数**: 1箇所
- **Rust SSOT経由**: 0箇所（❌ **SSOT未定義**）
- **Rust 直接読み込み**: 1箇所
- `src/tests/helpers/joinir_env.rs:19` - `std::env::remove_var("HAKO_JOINIR_IF_SELECT_DRYRUN")`
**SSOT関数**: ❌ **未定義**（未使用？）
---
## 3. 直接読み込み問題ファイル一覧（重要！）
### 3.1 NYASH_JOINIR_EXPERIMENT 直接読み込み（39箇所）
| ファイル名 | 行数 | 用途 |
|----------|------|------|
| `src/tests/mir_joinir_funcscanner_append_defs.rs` | 36, 178 | テストスキップ判定 |
| `src/tests/mir_joinir_skip_ws.rs` | 34, 124 | テストスキップ判定 |
| `src/tests/mir_joinir_stage1_using_resolver_min.rs` | 41, 154 | テストスキップ判定 |
| `src/tests/joinir_runner_min.rs` | 15 | テストスキップ判定 |
| `src/tests/joinir_json_min.rs` | 12 | コメント言及 |
| `src/tests/mir_joinir_funcscanner_trim.rs` | 35, 133 | テストスキップ判定 |
| `src/tests/mir_joinir_min.rs` | 25, 144 | テストスキップ判定 |
| `src/tests/mir_joinir_stageb_funcscanner.rs` | 20 | テストスキップ判定 |
| `src/tests/joinir_runner_standalone.rs` | 18, 153 | テストスキップ判定 |
| `src/mir/join_ir_vm_bridge_dispatch/exec_routes.rs` | 11 | コメント言及 |
| `src/tests/helpers/joinir_env.rs` | 20 | ヘルパー関数 remove_var |
| `src/tests/mir_joinir_stageb_body.rs` | 20 | テストスキップ判定 |
| `src/mir/phi_core/loopform_builder.rs` | 81 | コメント言及 |
| `src/mir/join_ir/verify.rs` | 17 | コメント言及 |
### 3.2 HAKO_JOINIR_* 直接読み込み（28箇所）
| ENV名 | ファイル数 | 主な用途 |
|------|----------|---------|
| `HAKO_JOINIR_IF_SELECT` | 2ファイル（13箇所） | テスト用 set/remove_var |
| `HAKO_JOINIR_NESTED_IF` | 3ファイル（7箇所） | テストスキップ判定、条件分岐 |
| `HAKO_JOINIR_READ_QUOTED` | 3ファイル（8箇所） | テストスキップ判定、条件分岐 |
| `HAKO_JOINIR_PRINT_TOKENS_MAIN` | 2ファイル（6箇所） | dev専用フラグ（builder制御） |
| `HAKO_JOINIR_IF_IN_LOOP_TRACE` | 1ファイル（2箇所） | trace専用フラグ |
| `HAKO_JOINIR_IF_IN_LOOP_DRYRUN` | 1ファイル（2箇所） | テスト用 set/remove_var |
### 3.3 Stage-3 直接読み込み（46箇所）
| ENV名 | ファイル数 | 主な用途 |
|------|----------|---------|
| `NYASH_PARSER_STAGE3` | 10ファイル（27箇所） | テスト用 set/remove_var |
| `HAKO_PARSER_STAGE3` | 6ファイル（19箇所） | テスト用 set/remove_var |
---
## 4. 整理優先順位（推奨）
### 🔴 CRITICAL（即座に対応）
#### 4.1 NYASH_JOINIR_EXPERIMENT の SSOT 化
- **問題**: 39箇所の直接読み込み（最多）
- **影響範囲**: 14テストファイル + 3実装ファイル
- **推奨対応**:
1. `tests/helpers/joinir_env.rs` に以下を追加:
```rust
pub fn enable_joinir_experiment() {
std::env::set_var("NYASH_JOINIR_EXPERIMENT", "1");
}
pub fn disable_joinir_experiment() {
std::env::remove_var("NYASH_JOINIR_EXPERIMENT");
}
pub fn is_joinir_experiment_enabled() -> bool {
crate::config::env::joinir_experiment_enabled()
}
```
2. 全テストファイルの `std::env::var("NYASH_JOINIR_EXPERIMENT")` を上記ヘルパーに置換
3. テストスキップ判定を統一化
---
### 🟠 HIGH（Phase 72 で対応）
#### 4.2 HAKO_JOINIR_* dev/実験フラグの整理
- **対象**: 8種類のdev/実験フラグ（SSOT未定義）
- `HAKO_JOINIR_NESTED_IF`
- `HAKO_JOINIR_READ_QUOTED`
- `HAKO_JOINIR_READ_QUOTED_IFMERGE`
- `HAKO_JOINIR_PRINT_TOKENS_MAIN`
- `HAKO_JOINIR_ARRAY_FILTER_MAIN`
- `HAKO_JOINIR_IF_IN_LOOP_TRACE`
- `HAKO_JOINIR_IF_TOPLEVEL_TRACE`
- `HAKO_JOINIR_IF_SELECT_DRYRUN`
- **推奨対応**:
1. 使用頻度が高いものは SSOT 関数化（例: `HAKO_JOINIR_NESTED_IF`）
2. trace専用フラグは `HAKO_JOINIR_DEBUG` レベルに統合検討
3. 未使用フラグは削除検討
---
#### 4.3 HAKO_JOINIR_IF_SELECT の SSOT 完全化
- **問題**: 13箇所の直接読み込み（テスト用）
- **推奨対応**:
1. `tests/helpers/joinir_env.rs` に以下を追加:
```rust
pub fn enable_joinir_if_select() {
std::env::set_var("HAKO_JOINIR_IF_SELECT", "1");
}
pub fn disable_joinir_if_select() {
std::env::remove_var("HAKO_JOINIR_IF_SELECT");
}
```
2. `src/tests/mir_joinir_if_select.rs` の9箇所を置換
---
### 🟡 MEDIUM（Phase 73 で対応）
#### 4.4 Stage-3 legacy ENV の完全削除
- **対象**: `NYASH_PARSER_STAGE3`, `HAKO_PARSER_STAGE3`
- **現状**: deprecation warning 出力中
- **推奨対応**:
1. Phase 72 完了後、全テストを `NYASH_FEATURES=stage3` に統一
2. child_env/stage1_bridge の伝播ロジック削減
3. `config/env.rs` の優先順位ロジック簡素化（`NYASH_FEATURES` のみに）
---
### 🟢 LOW（Phase 74+ で対応）
#### 4.5 NYASH_FEATURES のデフォルト化完了確認
- **現状**: `parser_stage3_enabled()` が既に `true` をデフォルト返却
- **推奨対応**:
1. スクリプトから `NYASH_FEATURES=stage3` の明示的指定を削減
2. ドキュメント更新（Stage-3は標準構文であることを明記）
---
## 5. SSOT 化推奨パターン
### 5.1 テストヘルパー統一パターン（`tests/helpers/joinir_env.rs`）
```rust
/// JoinIR 実験モード有効化
pub fn enable_joinir_experiment() {
std::env::set_var("NYASH_JOINIR_EXPERIMENT", "1");
}
/// JoinIR 実験モード無効化
pub fn disable_joinir_experiment() {
std::env::remove_var("NYASH_JOINIR_EXPERIMENT");
}
/// JoinIR 実験モード確認（SSOT経由）
pub fn is_joinir_experiment_enabled() -> bool {
crate::config::env::joinir_experiment_enabled()
}
/// テストスキップ判定の統一化
pub fn skip_unless_joinir_experiment(test_name: &str) {
if !is_joinir_experiment_enabled() {
eprintln!(
"[{}] NYASH_JOINIR_EXPERIMENT=1 not set, skipping test",
test_name
);
return;
}
}
```
### 5.2 テスト内での使用例
```rust
// Before（❌ 直接読み込み）
#[test]
fn test_joinir_feature() {
if std::env::var("NYASH_JOINIR_EXPERIMENT").ok().as_deref() != Some("1") {
eprintln!("[test] NYASH_JOINIR_EXPERIMENT=1 not set, skipping");
return;
}
// テスト本体
}
// After（✅ SSOT経由）
#[test]
fn test_joinir_feature() {
use crate::tests::helpers::joinir_env::skip_unless_joinir_experiment;
skip_unless_joinir_experiment("test_joinir_feature");
// テスト本体
}
```
---
## 6. Phase 72-73 タスクブレークダウン
### Phase 72-A: JoinIR EXPERIMENT SSOT 化
- [ ] `tests/helpers/joinir_env.rs` にヘルパー追加
- [ ] 14テストファイルの直接読み込み置換（39箇所）
- [ ] 実装ファイルのコメント更新（3箇所）
### Phase 72-B: HAKO_JOINIR_IF_SELECT SSOT 化
- [ ] `tests/helpers/joinir_env.rs` にヘルパー追加
- [ ] `src/tests/mir_joinir_if_select.rs` 置換（9箇所）
- [ ] `tests/helpers/joinir_env.rs` 置換（2箇所）
### Phase 72-C: dev/実験フラグ整理
- [ ] 使用頻度調査（各フラグの利用実態確認）
- [ ] SSOT 関数化優先順位決定
- [ ] trace系フラグの統合検討
### Phase 73-A: Stage-3 legacy ENV 削除
- [ ] 全テストを `NYASH_FEATURES=stage3` に統一（46箇所）
- [ ] child_env/stage1_bridge の伝播ロジック簡素化
- [ ] `config/env.rs` の優先順位ロジック削減
### Phase 73-B: スクリプト整理
- [ ] `tools/selfhost/*.sh` の legacy ENV 削除（22箇所）
- [ ] `tools/dev/*.sh` の legacy ENV 削除（15箇所）
- [ ] smokes/v2 での `NYASH_FEATURES=stage3` 簡素化（96箇所）
---
## 7. 検証手順
### 7.1 Phase 72 完了条件
```bash
# 直接読み込みゼロ確認
rg 'std::env::var\("NYASH_JOINIR_EXPERIMENT"\)' --type rust
rg 'std::env::var\("HAKO_JOINIR_IF_SELECT"\)' --type rust
# 期待結果: config/env.rs とテストヘルパーのみ
```
### 7.2 Phase 73 完了条件
```bash
# legacy ENV ゼロ確認
rg 'NYASH_PARSER_STAGE3|HAKO_PARSER_STAGE3' --type rust --type sh
rg 'std::env::var\("NYASH_PARSER_STAGE3"\)' --type rust
# 期待結果: deprecation warning 削除済み
```
---
## 8. 既知の良い例（モデルケース）
### 8.1 `NYASH_JOINIR_DEV`（完璧な SSOT 実装）
- ✅ 全てSSAT経由（`config::env::joinir_dev_enabled()`）
- ✅ 直接読み込みゼロ
- ✅ 優先順位明確（NYASH_JOINIR_DEV > joinir_debug_level()>0）
### 8.2 `HAKO_JOINIR_DEBUG`（完璧な SSOT 実装）
- ✅ レベル制御（0-3）で段階的ログ制御
- ✅ 全てSSAT経由（`config::env::joinir_debug_level()`）
- ✅ 直接読み込みゼロ
### 8.3 `HAKO_JOINIR_IF_IN_LOOP_ENABLE`（完璧な SSOT 実装）
- ✅ 全てSSAT経由（`config::env::joinir_if_in_loop_enable()`）
- ✅ 直接読み込みゼロ
- ✅ dry-run と本番経路の独立制御
---
## 9. まとめと次のアクション
### 現状の問題点
1. **NYASH_JOINIR_EXPERIMENT**: 39箇所の直接読み込み（最多）
2. **HAKO_JOINIR_* dev/実験フラグ**: 8種類がSSAT未定義
3. **Stage-3 legacy ENV**: 46箇所残存（移行完了は96箇所のスクリプトで確認済み）
### 推奨優先順位
1. **CRITICAL**: `NYASH_JOINIR_EXPERIMENT` の SSOT 化（Phase 72-A）
2. **HIGH**: `HAKO_JOINIR_IF_SELECT` の SSOT 化（Phase 72-B）
3. **HIGH**: dev/実験フラグの整理（Phase 72-C）
4. **MEDIUM**: Stage-3 legacy ENV 削除（Phase 73-A/B）
### 期待効果
- ✅ ENV 直接読み込みの根絶（113箇所 → 0箇所）
- ✅ テストヘルパーの統一化（メンテナンス性向上）
- ✅ JoinIR実験→本線移行の加速（トグル管理の簡素化）
- ✅ Stage-3標準化の完了（legacy ENV 完全削除）
---
**次のアクション**: Phase 72-A の実装計画策定にゃ！
Status: Historical

3
docs/archive/roadmap/phases/phase-10/README.md
View File

@ -58,4 +58,5 @@ Phase 11: LLVM AOT研究（将来）
## 🔗 関連ドキュメント
- [00_MASTER_ROADMAP.md](../00_MASTER_ROADMAP.md) - 全体計画
- [Phase 9.79b](../phase-9/) - 統一Box設計（前提）
- [MIR仕様](../../../../reference/mir/) - 中間表現
- [MIR仕様](../../../../reference/mir/) - 中間表現
Status: Historical

1
docs/archive/roadmap/phases/phase-10/phase_10_10/README.md
View File

@ -92,3 +92,4 @@ NYASH_JIT_EXEC=1 NYASH_JIT_THRESHOLD=1 NYASH_JIT_HOSTCALL=1 NYASH_JIT_EVENTS=1 \
- HostCall: 実例では `NYASH_JIT_HOSTCALL=1` を明示（HH直実行/ANYヘルパ）
- ANYヘルパ: `nyash.any.length_h / is_empty_h` でROは十分カバー（追加不要）
```
Status: Historical

1
docs/archive/roadmap/phases/phase-10/phase_10_5_core_std_nyash_impl.md
View File

@ -55,3 +55,4 @@
- Host API: Phase 10.2 仕様
最終更新: 2025-08-14
Status: Historical

1
docs/archive/roadmap/phases/phase-10/phase_10_6a_thread_safety_audit.md
View File

@ -44,3 +44,4 @@ rg -n "Arc<|Mutex<|RwLock<|Send|Sync" src/boxes src/runtime
## 次の一手（提案）
- マーカーTraits（例: `ThreadSafeBox`）の導入は保留（破壊的）。現時点は監査＋ドキュメントで運用。
- 並列スケジューラ（M:N）の実装は `feature` フラグで段階導入。
Status: Historical

1
docs/archive/roadmap/phases/phase-10/phase_10_7h_native_abi_types.md
View File

@ -42,4 +42,5 @@ Risks / Mitigation
Acceptance
- Examples with pure f64 pipelines run under JIT with matching results vs VM
- No silent lossy conversions; conversions visible in MIR/Lower logs
Status: Historical

3
docs/archive/roadmap/phases/phase-10/phase_10_8_unified_debug_system.md
View File

@ -169,4 +169,5 @@ impl MirBuilder {
---
*Everything is Box, Everything is Debug - 統一されたデバッグ体験へ*
*Everything is Box, Everything is Debug - 統一されたデバッグ体験へ*
Status: Historical

3
docs/archive/roadmap/phases/phase-10/phase_10_8a_from_keyword_consistency.md
View File

@ -82,4 +82,5 @@ SuperMethodCall → FromMethodCall
---
*「from」こそがNyashの明示的デリゲーションの象徴*
*「from」こそがNyashの明示的デリゲーションの象徴*
Status: Historical

1
docs/archive/roadmap/phases/phase-10/phase_10_9_builtin_box_jit_support.md
View File

@ -153,3 +153,4 @@ NYASH_JIT_EXEC=1 NYASH_JIT_THRESHOLD=1 NYASH_JIT_HOSTCALL=1 NYASH_JIT_EVENTS=1 \
---
最短ルート: 箱（Policy/Events/Registry/Boundary）を先に置き、読み取り系でJITを安全に通す→観測を増やす→署名とポリシーの一本化で切替点を固定→必要最小限のネイティブ型（f64/b1）を段階導入。
Status: Historical

3
docs/archive/roadmap/phases/phase-10/phase_10_app_migration.md
View File

@ -217,4 +217,5 @@ static box AppName {
3. **開発体験の向上**: Copilotとの協調開発での生産性検証
4. **エコシステム拡充**: Nyashアプリケーションの具体例提供
**この移植が成功すれば、Nyashは「実用的なプログラミング言語」として確立されます！** 🎉
**この移植が成功すれば、Nyashは「実用的なプログラミング言語」として確立されます！** 🎉
Status: Historical

3
docs/archive/roadmap/phases/phase-10/phase_10_function_declaration_mir_support.md
View File

@ -69,4 +69,5 @@ AstNode::FunctionDeclaration { name, params, body, .. } => {
## 📝 関連イシュー
- JIT配列操作テスト
- MIRビルダー拡張
- 言語仕様の完全性
- 言語仕様の完全性
Status: Historical

4
docs/archive/roadmap/phases/phase-22/README.md
View File

@ -1,3 +1,5 @@
Status: Historical
# Phase 22: Nyash LLVM Compiler - コンパイラもBoxの世界へ
## 📋 概要
@ -63,4 +65,4 @@ box LLVMCompiler {
> 「コンパイラもBox、Everything is Box」
> 「2,500行→100行、これこそ革命」
最小限のC++グルーとNyashの表現力で、世界一シンプルなLLVMコンパイラへ。
最小限のC++グルーとNyashの表現力で、世界一シンプルなLLVMコンパイラへ。

3
docs/archive/roadmap/phases/phase-22/ROADMAP.md
View File

@ -107,4 +107,5 @@ compiler.compile("phase22-compiler.hako", "nyash-compiler.exe")
---
> 「難しいけど、夢があるにゃ！」
> 「難しいけど、夢があるにゃ！」
Status: Historical

3
docs/archive/roadmap/phases/phase-22/codex-discussion.md
View File

@ -119,4 +119,5 @@ add_function/append_block/position
3. **最小FFI境界**: バッチ化による関数数抑制
4. **80k→20k圧縮**: 大幅な行数削減への直接貢献
この設計により、Nyashセルフホスティングの革命的な軽量化と高速化が実現できる見込みです。
この設計により、Nyashセルフホスティングの革命的な軽量化と高速化が実現できる見込みです。
Status: Historical

3
docs/archive/roadmap/phases/phase-22/gemini-discussion.md
View File

@ -67,4 +67,5 @@ Nyashセルフホスティングの革新的アイデアについて相談です
### しかし、ユーザーの洞察は正しい
「MIR解釈して出力するだけなのに、メモリーリークの心配なんてあるんだろうか？」
→ 短命なバッチ処理にRustの複雑さは確かに過剰！
→ 短命なバッチ処理にRustの複雑さは確かに過剰！
Status: Historical

3
docs/archive/roadmap/phases/phase-22/synthesis.md
View File

@ -135,4 +135,5 @@ box Optimizer { }
> 「Rustの安全性は素晴らしい。でも、3秒で終わるプログラムに5分のビルドは過剰だにゃ！」
この単純な真実が、新しい時代への扉を開く鍵となる。
この単純な真実が、新しい時代への扉を開く鍵となる。
Status: Historical