3beddd6eb4
🔍 根本原因特定: - 問題箇所: stage1_cli.hako:111 の args null チェックパターン local argc = 0; if args != null { argc = args.size() } - 発生条件: 1. 深い制御フロー（BasicBlockId(12266) = 12,266ブロック） 2. using chain 複雑さ（BuildBox → ParserBox → 50+ファイル） 3. 多段階早期return（複数の支配フロンティアとPHIマージ） - なぜShapeテストは通るか: - スタブ実装（複雑な外部Box呼び出しなし） - 単一ファイル（using chain なし） - シンプルなCFG（数十ブロック vs 12,266ブロック） ✅ 解決策4案提示: - Solution A: Fail-Fast Guard（最優先・最簡単） if args == null { args = new ArrayBox() } → PHI merge を 1定義に潰す - Solution B: デバッグロジック抽出 → 問題パターンを小さな関数に隔離 - Solution C: Rust Bridge修正 → stage1_bridge.rs で常に非null保証 - Solution D: MIR Builder根治（長期） → SSA構築ロジック・PHI配置アルゴリズム改善 📋 成果物: - 詳細調査レポート: docs/development/current/main/stage1_cli_ssa_valueid34_analysis.md - ValueId(34)の定義/使用ブロック解析 - 呼び出しチェーン追跡 - 制御フロー複雑度分析 - 4つの解決策の詳細実装手順 - Shapeテスト追加: src/tests/stage1_cli_entry_ssa_smoke.rs - mir_stage1_cli_entry_like_pattern_verifies - mir_stage1_cli_stage1_main_shape_verifies - 構文とCFG形の正しさを検証（PASS） 🎯 技術的成果: - MIRレベルのSSA追跡失敗メカニズムを完全解明 - 「テストは通るが実物は失敗」のギャップを構造的に特定 - 箱レベルでの実装可能な解決策を4案提示 Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Task Assistant <task@anthropic.com>
Nyash Development Documentation 🔧
開発者向けの進行中タスクと開発計画ドキュメントです。
📂 ディレクトリ構造
current/
CURRENT_TASK.md- 現在進行中のタスク- アクティブな開発作業の詳細
- 最新の実装状況
roadmap/
- phases/ - フェーズ別開発計画
- phase-8/ - AST→MIR変換
- phase-9/ - VM/JIT実装
- phase-10/ - AOT最適化
- native-plan/ - ネイティブビルド計画
- 実行バックエンド統合
- パフォーマンス目標
proposals/
- RFC（Request for Comments）
- 新機能提案
- 設計ディスカッション
🎯 重要な参照先
- 進行状況:
current/CURRENT_TASK.md - 開発計画:
roadmap/phases/ - 技術提案:
proposals/
📝 注意事項
このディレクトリの内容は開発中であり、頻繁に変更されます。
安定した仕様はreference/を参照してください。