|
|
ce7517dc21
|
docs(phase-21.7): NamingBox SSOT 統一化チェックリスト作成
Phase 21.7++ の詳細実装計画を文書化
## 作成ファイル
- docs/development/current/main/phase-21.7-naming-ssot-checklist.md
- Phase 0-4 の詳細タスクリスト（チェックボックス付き）
- 各タスクの具体的な実装コード例
- テストケース
- 工数見積もり・優先順位
- 完了条件
## CURRENT_TASK.md 更新
- Phase 21.7 セクションにチェックリストへのリンク追加
## 実装優先順位
1. Phase 0: 観測ライン緊急構築（最優先、2-3時間）
2. Phase 1: 基盤整備（4-6時間）
3. Phase 2: VM 統一（3-4時間）
4. Phase 3-4: 全体統一・ドキュメント（Phase 22+）
次のステップ: Phase 0 実装開始
|
2025-11-22 01:59:27 +09:00 |
|
|
|
380a724b9c
|
debug(stage1): Phase 25.1 - MIR Builder 型混乱バグ完全特定
🚨 重大発見: .hakoレベルでは修正不可能なMIR Builderバグ
🔍 根本原因特定:
- MIR Builder の型レジストリシステムが型情報を正しく追跡できていない
- new ArrayBox() で生成したValueIdが、誤った型として認識される
- PHIマージポイントで型情報が失われる/上書きされる
📊 系統的な型混乱パターン:
1. args.size() → ParserBox.size() (本来: ArrayBox.size())
2. cli_args.length() → ParserBox.length() (本来: ArrayBox.length())
3. new ArrayBox().size() → LoopOptsBox.size() (本来: ArrayBox.size())
❌ すべての.hako回避策が失敗:
- パラメータ名変更: args → cli_args → cli_args_raw
- 新しいArrayBox作成: local x = new ArrayBox()
- Fail-Fast Guard追加
→ すべて同じ型混乱エラー
✅ 決定的証拠:
- __mir__.log が一度も実行されなかった
→ エラーは MIR生成時に発生（実行時ではない）
→ .hakoコードの問題ではない
📋 成果物:
- __mir__.log マーカー追加 (lang/src/runner/stage1_cli.hako)
- stage1_main 入口ログ
- env toggles ログ
- args.size() 前後ログ
- StringHelpers.to_i64 改善 (lang/src/shared/common/string_helpers.hako)
- null/Void ガード追加
- デバッグログ追加
- 完全調査レポート:
- stage1_mir_builder_type_confusion_bug.md (最終レポート)
- stage1_mir_log_investigation.md (詳細調査ログ)
🔧 必要な修正 (推定6-10時間):
Phase 1: デバッグトレース追加 (30分)
- src/mir/builder/types/mod.rs に NYASH_MIR_TYPE_TRACE
Phase 2: トレース実行 (1時間)
- 型情報がどこで失われるか特定
Phase 3: 根本修正 (4-8時間)
- NewBox生成時の型登録修正
- PHI型伝播ロジック修正
- 型レジストリ整合性チェック追加
Phase 4: 検証 (1時間)
- stage1_cli 正常動作確認
🎯 結論:
MIR Builder の根本的インフラバグ。SSA変換とPHIノード経由での
型情報追跡に失敗している。.hakoレベルでは回避不可能。
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Task Assistant <task@anthropic.com>
|
2025-11-21 08:03:03 +09:00 |
|
|
|
3beddd6eb4
|
docs(stage1): Phase 25.1 - Stage-1 CLI ValueId(34) SSA バグ完全調査完了
🔍 根本原因特定:
- 問題箇所: stage1_cli.hako:111 の args null チェックパターン
local argc = 0; if args != null { argc = args.size() }
- 発生条件:
1. 深い制御フロー（BasicBlockId(12266) = 12,266ブロック）
2. using chain 複雑さ（BuildBox → ParserBox → 50+ファイル）
3. 多段階早期return（複数の支配フロンティアとPHIマージ）
- なぜShapeテストは通るか:
- スタブ実装（複雑な外部Box呼び出しなし）
- 単一ファイル（using chain なし）
- シンプルなCFG（数十ブロック vs 12,266ブロック）
✅ 解決策4案提示:
- Solution A: Fail-Fast Guard（最優先・最簡単）
if args == null { args = new ArrayBox() }
→ PHI merge を 1定義に潰す
- Solution B: デバッグロジック抽出
→ 問題パターンを小さな関数に隔離
- Solution C: Rust Bridge修正
→ stage1_bridge.rs で常に非null保証
- Solution D: MIR Builder根治（長期）
→ SSA構築ロジック・PHI配置アルゴリズム改善
📋 成果物:
- 詳細調査レポート: docs/development/current/main/stage1_cli_ssa_valueid34_analysis.md
- ValueId(34)の定義/使用ブロック解析
- 呼び出しチェーン追跡
- 制御フロー複雑度分析
- 4つの解決策の詳細実装手順
- Shapeテスト追加: src/tests/stage1_cli_entry_ssa_smoke.rs
- mir_stage1_cli_entry_like_pattern_verifies
- mir_stage1_cli_stage1_main_shape_verifies
- 構文とCFG形の正しさを検証（PASS）
🎯 技術的成果:
- MIRレベルのSSA追跡失敗メカニズムを完全解明
- 「テストは通るが実物は失敗」のギャップを構造的に特定
- 箱レベルでの実装可能な解決策を4案提示
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Task Assistant <task@anthropic.com>
|
2025-11-21 07:00:05 +09:00 |
|
|
|
461bdec45a
|
feat(phi): Step 5-5-H完了 - Phantom block検証＋PHI決定性向上
✅ Step 5-5-H: exit_preds検証でphantom block除外
- loop_snapshot_merge.rs line 268: CFG実在チェック追加
✅ PHI生成決定性向上（4ファイル）
- HashMap/HashSet → BTreeMap/BTreeSet変換
- if_phi.rs, loop_phi.rs, loop_snapshot_merge.rs, loopform_builder.rs
✅ 根本原因分析完了（Task先生調査）
- ValueId変動の真因: HashMap非決定的イテレーション
- 詳細: docs/development/current/main/valueid-*.md
📊 テスト結果: 267/268 PASS（退行なし）
- mir_funcscanner_skip_ws: 非決定性残存（variable_map由来）
- 後続タスクで対応予定
🎉 PHI Bug Option C実装ほぼ完了！
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2025-11-20 17:10:03 +09:00 |
|
|
|
d99b941218
|
docs: add MIR13 mode doc and set PHI-off as default; bridge lowering split (if/loop/try); llvmlite resolver stabilization; curated runner default PHI-off; refresh CURRENT_TASK.md
|
2025-09-17 10:58:12 +09:00 |
|
