hakorune/docs/development/current/main/hako_check_design.md

hako_check 設計（Phase 121 時点）

概要

hako_check は .hako ファイルの静的解析・検証を行うツール。 Phase 121 では、この経路を JoinIR 統合に向けて設計する。

hako_check の役割

現在の機能

• 構文チェック: パーサーエラーの検出
• 型チェック: 基本的な型の整合性確認
• MIR 生成: .hako → MIR への変換（検証用）
• 制御フローチェック: unreachable code などの検出
• ルールベース診断: 19種類の診断ルール（HC001-HC031）

hako_check の実装構造（Phase 121 調査時点）

重要: hako_check は Rust バイナリではなく .hako スクリプトとして実装されている。

tools/hako_check.sh               # シェルスクリプトラッパー
  ↓
tools/hako_check/cli.hako         # .hako エントリーポイント
  ↓
HakoAnalyzerBox.run()             # 静的解析メインロジック
  ↓
HakoAnalysisBuilderBox            # IR 生成（analysis_consumer.hako）
  ↓
hakorune --backend vm             # Rust VM で実行
  ↓
MirCompiler::compile()            # AST → MIR 変換
  ↓
MirBuilder::build_module()        # MIR 生成（ここで PHI 生成）

エントリーポイントの詳細

ファイル: tools/hako_check.sh

実行フロー:

1. tools/hako_check.sh がシェルスクリプトとして起動
2. $BIN (通常は ./target/release/hakorune) を使用して cli.hako を実行
3. 環境変数で VM バックエンドを指定: --backend vm

重要な環境変数:

NYASH_DISABLE_PLUGINS=1              # プラグイン無効化（安定性優先）
NYASH_BOX_FACTORY_POLICY=builtin_first  # ビルトイン Box 優先
NYASH_FEATURES=stage3                # Stage-3 パーサー使用
NYASH_ENABLE_USING=1                 # using 文有効化

MIR 生成経路

hako_check での MIR 生成フロー:

1. cli.hako が .hako ファイルを読み込む
   ↓
2. HakoAnalysisBuilderBox.build_from_source_flags() を呼び出す
   ↓
3. 内部で HakoParserCoreBox.parse() を使用（.hako パーサー）
   ↓
4. AST を取得（Rust VM 内部で nyash_rust::parser::NyashParser を使用）
   ↓
5. Rust VM が AST を MirCompiler に渡す
   ↓
6. MirCompiler::compile_with_source() が AST → MIR 変換
   ↓
7. MirBuilder::build_module() で MIR 生成
   ↓
8. If/Loop 文は control_flow.rs で処理

PHI 生成経路（Phase 121 時点）

If 文の PHI 生成:

• ファイル: src/mir/builder/if_form.rs
• 関数: MirBuilder::cf_if() → PHI 生成ロジック
• JoinIR 統合: ❌ 未実装（旧 PHI 生成器を使用中）

Loop の PHI 生成:

• ファイル: src/mir/builder/control_flow.rs
• 関数: MirBuilder::cf_loop() → try_cf_loop_joinir()
• JoinIR 統合: ⚠️ 部分実装（Phase 49 で mainline 統合開始）
  • HAKO_JOINIR_PRINT_TOKENS_MAIN=1: 特定関数のみ JoinIR 経由
  • HAKO_JOINIR_ARRAY_FILTER_MAIN=1: 特定関数のみ JoinIR 経由
  • デフォルトは旧 LoopBuilder へフォールバック

Phase 121 での課題

• 旧 MIR/PHI 経路: 現在は旧 PHI 生成器を主に使用している
• JoinIR 統合: If/Loop の JoinIR Lowering 経由への移行が必要
• Strict モード: NYASH_JOINIR_STRICT=1 での動作確認が未実施

現在の JoinIR 統合状況

Loop PHI 生成（部分統合済み）

Phase 49 Mainline Integration:

// src/mir/builder/control_flow.rs
fn try_cf_loop_joinir(&mut self, condition: &ASTNode, body: &ASTNode) -> Result<Option<ValueId>, String> {
    let core_on = crate::config::env::joinir_core_enabled();
    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);
    }

    // フォールバック: 旧 LoopBuilder
    Ok(None)
}

特徴:

• 選択的統合: 特定関数のみ JoinIR 経由（mainline targets）
• フォールバック: 失敗時は旧 LoopBuilder に戻る
• 環境変数制御:
  • NYASH_JOINIR_CORE=1: JoinIR Core 有効化
  • HAKO_JOINIR_PRINT_TOKENS_MAIN=1: print_tokens/0 を JoinIR 経由
  • HAKO_JOINIR_ARRAY_FILTER_MAIN=1: ArrayExtBox.filter/2 を JoinIR 経由

If PHI 生成（未統合）

Phase 121 調査結果: If 文の PHI 生成は旧経路を使用中

ファイル: src/mir/builder/if_form.rs

// 旧 PHI 生成器（Phase 121 時点で現役）
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 経路ではまだ統合されていない
}

JoinIR 統合設計

統合方針

3段階移行戦略:

1. Phase 122: 環境変数で JoinIR 経路を選択可能に（デフォルトは旧経路）

   • NYASH_HAKO_CHECK_JOINIR=1 で JoinIR 経路を有効化
   • 旧経路との互換性維持（フォールバック可能）

2. Phase 123: JoinIR 経路をデフォルトに（旧経路は NYASH_LEGACY_PHI=1 でのみ有効）

   • デフォルトで JoinIR 経路を使用
   • 旧経路は明示的に有効化した場合のみ使用

3. Phase 124: 旧経路完全削除（JoinIR のみ）

   • 旧 PHI 生成器の完全削除
   • NYASH_LEGACY_PHI=1 環境変数も削除

設計原則

Baseline First:

• Phase 120 で確立した selfhost 経路のベースラインを参考に
• hako_check 経路でも同様のベースライン確立が必要

Fail-Fast:

• フォールバック処理は原則禁止（Phase 123 以降）
• エラーは早期に明示的に失敗させる

環境変数制御:

• NYASH_HAKO_CHECK_JOINIR=1: hako_check で JoinIR 経路を有効化
• NYASH_JOINIR_STRICT=1: フォールバック禁止（厳格モード）

hako_check 特有の考慮事項

1. .hako スクリプトとしての実行:

• hako_check は Rust バイナリではなく .hako スクリプト
• Rust VM 経由で実行されるため、VM の MirBuilder を使用
• JoinIR 統合は VM の MirBuilder に実装する必要がある

2. 診断ルールとの関係:

• hako_check は 19 種類の診断ルール（HC001-HC031）を実装
• MIR 生成は診断の前段階（IR 生成用）
• JoinIR 統合による診断ルールへの影響は最小限

3. selfhost 経路との違い:

• selfhost: .hako コンパイラを実行（実行時 PHI 必要）
• hako_check: 静的解析のみ（MIR 生成は検証用）
• PHI 生成の要件は同じだが、実行環境が異なる

selfhost 経路との違い

項目	selfhost 経路	hako_check 経路
目的	.hako コンパイラ実行	.hako 静的解析
実行	VM/LLVM で実行	MIR 生成のみ（VM で .hako スクリプト実行）
PHI 生成	実行時に必要	検証用のみ
エラー処理	実行時エラー	静的エラー
環境変数	NYASH_USE_NY_COMPILER=1	NYASH_DISABLE_PLUGINS=1
実装形式	Rust バイナリ	.hako スクリプト（VM で実行）

Phase 122+ 実装計画

Phase 122: 環境変数で JoinIR 選択可能に

実装内容:

• NYASH_HAKO_CHECK_JOINIR=1 環境変数追加
• MirBuilder の cf_if() / cf_loop() で環境変数確認
• 条件分岐で JoinIR 経路 or 旧経路を選択

実装箇所:

• src/mir/builder/if_form.rs: If 文の JoinIR 統合
• src/mir/builder/control_flow.rs: Loop の JoinIR 統合拡張

テスト:

• 既存テスト全 PASS（旧経路）
• JoinIR 経路でのスモークテスト作成

Phase 123: JoinIR 経路をデフォルトに

実装内容:

• デフォルトを JoinIR 経路に変更
• NYASH_LEGACY_PHI=1 で旧経路に戻せるように

テスト:

• JoinIR 経路で全テスト PASS
• 旧経路でも互換性維持確認

Phase 124: 旧経路完全削除

実装内容:

• 旧 PHI 生成器削除（if_form.rs の旧ロジック削除）
• NYASH_LEGACY_PHI=1 環境変数削除
• 関連ドキュメント更新

テスト:

• JoinIR 経路のみで全テスト PASS

まとめ

Phase 121 は設計と調査のみ。実装は Phase 122+ で段階的に実施する。

重要な発見:

• hako_check は .hako スクリプトとして実装されている
• JoinIR 統合は VM の MirBuilder に実装する必要がある
• Loop は部分統合済み（Phase 49）、If は未統合
• 段階的移行戦略により互換性を維持しながら統合可能