From 939af77a59960b6156f67605b66b63abe00cc91a Mon Sep 17 00:00:00 2001 From: Moe Charm Date: Sat, 16 Aug 2025 21:47:14 +0900 Subject: [PATCH] docs: Update copilot_issues.txt with interpreter hybrid strategy MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Major changes: - Remove completed phases: 9.5, 9.6, 9.7, 9.75 - Update Phase 9.77 status (UTF-8 error investigation, Issue #110) - Add interpreter hybrid strategy (Python-like practicality) - Update Phase 10 with async/await native implementation - Emphasize interpreter value for both development and production Key insights: - Interpreter is practical for production use (like Python) - Best of both worlds: interpreter convenience + compiler performance - Hybrid approach: use interpreter for most tasks, AOT for performance-critical 🤖 Generated with Claude Code Co-Authored-By: Claude --- docs/予定/native-plan/copilot_issues.txt | 540 ++++-------------- .../issues/phase_9_77a_utf8_error_fix.md | 134 +++++ 2 files changed, 249 insertions(+), 425 deletions(-) create mode 100644 docs/予定/native-plan/issues/phase_9_77a_utf8_error_fix.md diff --git a/docs/予定/native-plan/copilot_issues.txt b/docs/予定/native-plan/copilot_issues.txt index b907f3e3..26fcfb4f 100644 --- a/docs/予定/native-plan/copilot_issues.txt +++ b/docs/予定/native-plan/copilot_issues.txt @@ -1,369 +1,57 @@ -# 🤖 Copilot様 作業予定・課題整理 (Phase 9.5以降 重点フォーカス) -# Generated: 2025-08-15 (Phase 9.5以降に重点整理) +# 🤖 Copilot様 作業予定・課題整理 (Phase 9.7以降 実用化重点) +# Generated: 2025-08-16 (インタープリター併用戦略統合) # Purpose: Claude×Copilot協調開発のための情報共有 ================================================================================ -🎯 Phase 9.5以降 開発ロードマップ (実用化重点) +🎯 Nyash実行モード併用戦略 ================================================================================ -## 🌐 Phase 9.5: HTTPサーバー実用テスト（AOT検証） +## 🌟 インタープリター＋コンパイラ併用の価値 -Summary: -- AOT実装完了後の複雑アプリケーション検証（並行処理・メモリ管理・実用性能） - -Scope/Tasks: -- tiny-web-server実装（HTTP/1.1対応） -- 同時接続・早期切断・例外経路テスト -- AOT環境での真の性能測定 -- 配布可能HTTPサーバーデモ - -Acceptance Criteria: -- `http_server.exe`として配布可能 -- 同時100接続でメモリリークなし -- fini()システム確実動作（I/Oハンドル解放） -- AOT性能でベンチマーク測定 - -Priority: High (Phase 9完了直後) -Expected Duration: 2週間 - -### 技術的複雑度 -```nyash -box HTTPServer { - init { clients, requests, handlers } - - acceptConnections() { - loop(me.running) { - local client = me.socket.accept() - nowait me.handleClient(client) // 非同期並行処理 - } - } - - handleClient(client) { - local request = client.readRequest() - local response = me.processRequest(request) - client.sendResponse(response) - client.fini() // 重要: 確実なリソース解放 - } -} +### 実行モード使い分け +``` +開発時: インタープリター（デバッグ・即時実行・非同期フル対応） +本番時: インタープリター（Pythonのように実用的） + OR + WASM/AOT（性能要求時） +配布時: AOT native（最高性能） +Web時: WASM（ブラウザ対応） ``` -### 検証ポイント -- **並行処理**: nowait/awaitのAOT実行性能 -- **メモリ管理**: Server→Clients→Requests木構造+weak参照 -- **I/Oリソース**: ソケット・ファイルハンドルの確実解放 -- **実用性能**: リアルHTTP負荷でのAOT効果測定 +### インタープリターの強み +- **即時実行**: コンパイル不要で高速開発 +- **デバッグ容易**: 実行時情報の完全把握 +- **非同期完全対応**: Rust async/awaitで真の並行処理 +- **動的性**: 実行時評価・REPL対応 +- **十分な性能**: 多くのユースケースで実用的（Pythonが証明） -### 🤖 Copilot協力期待 -- Socket・HTTP実装の効率化 -- 複雑なメモリ管理パターン検証 -- 負荷テスト・ベンチマーク整備 -- AOT最適化効果の定量測定 +================================================================================ +🎯 Phase 9.7以降 開発ロードマップ (実用化重点) +================================================================================ ------------------------------------------------------------- - - -## 🌐 Phase 9.6: WASM独自実装 - wasmtime依存完全排除（緊急） +## ⚡ Phase 9.77: WASM緊急復旧 - BoxCall/UTF-8エラー修正（進行中） Summary: -- wasmtime依存による互換性問題・BoxCall未実装を根本解決する独自WASM実装 -- Pure WAT Generation による軽量・高性能・依存関係フリーなWASM生成 +- BoxCall命令実装 ✅ 完了 +- wasmtimeバージョン更新 ✅ 完了 +- UTF-8エラー修正 🔄 進行中（Issue #110） -Priority: **Critical** (Phase 9.5完了後・9.7より先行) -Expected Duration: 2週間 -GitHub Issue: 予定 - -### 🚨 現在のwasmtime依存問題 -**バージョン互換性問題**: -```toml -# 現在の問題 -wasmtime = "18.0" # Nyash内部 -wasmtime = "35.0.0" # システム環境 -# → 完全に動作不可 -``` - -**機能不完全問題**: -- ❌ **BoxCall命令未実装**: `toString()`, `print()`等が全て使用不可 -- ❌ **ExternCall未実装**: ブラウザーAPI連携不可 -- ❌ **WASM出力エラー**: WAT→WASM変換でUTF-8エラー - -### 🎯 独自実装アプローチ -**Pure WAT Generation Engine**: -```rust -// wasmtime完全排除の独自実装 -struct PureWatGenerator { - // wasmtimeなし！純粋なWAT文字列生成 -} - -impl PureWatGenerator { - fn generate_box_call(&mut self, method: &str) -> String { - match method { - "toString" => "(call $box_to_string (local.get $box_ptr))", - "print" => "(call $print_function (local.get $value))", - // 独自実装でwasmtime不要 - } - } - - fn generate_extern_call(&mut self, interface: &str, method: &str) -> String { - match interface { - "console" => format!("(call $env_console_{} ...)", method), - "canvas" => format!("(call $env_canvas_{} ...)", method), - // ブラウザーAPI直接連携 - } - } -} -``` - -### 📋 実装計画 - -#### Phase 1: Pure WAT Generator基盤（1週間） -**🔴 Task 1**: wasmtime排除・純粋WAT生成（3日） -- `src/backend/wasm/pure_wat.rs`: 独自WAT生成エンジン -- `wabt` crateのみでWASM生成（wasmtime除去） -- 軽量・高速・依存関係最小化 - -**🔴 Task 2**: BoxCall独自実装（2日） -- `toString()`, `equals()`, `clone()` 基本メソッド -- `StringBox.length()`, `ArrayBox.push()` 等 -- MIR BoxCall → Pure WAT変換 - -**🔴 Task 3**: ExternCall独自実装（2日） -- `console.log()`, `canvas.fillRect()` ブラウザーAPI -- import declaration自動生成 -- ホスト側JavaScript連携 - -#### Phase 2: 互換性・性能最適化（1週間） -**🟡 Task 4**: メモリ管理最適化（3日） -- Box layouts効率化 -- ガベージコレクション最適化 -- メモリ断片化対策 - -**🟡 Task 5**: 統合テスト・検証（2日） -- 既存WASMテスト全通過 -- ブラウザー実行検証 -- 性能ベンチマーク - -**🟡 Task 6**: CLI統合・移行（2日） -- `--compile-wasm` 独自実装切り替え -- 旧実装との後方互換性 -- エラーメッセージ改善 - -### 🤖 Copilot協力期待 -- Pure WAT生成ロジックの効率実装 -- BoxCall/ExternCall命令の完全対応 -- wasmtime除去に伴うリファクタリング -- ブラウザー連携テストの自動化 - -### 成功基準 -- [ ] **wasmtime依存完全排除**: Cargo.tomlからwasmtime除去 -- [ ] **BoxCall完全実装**: 全基本メソッドがWASM実行 -- [ ] **ExternCall動作**: ブラウザーAPIが正常動作 -- [ ] **互換性問題解決**: バージョン非依存WASM生成 -- [ ] **性能向上**: Pure WAT生成による高速化 -- [ ] **軽量化**: 依存関係削減によるビルドサイズ削減 - -### 期待される効果 -**技術的効果**: -- **依存関係激減**: `wasmtime` → 不要 -- **互換性問題解決**: バージョン依存完全排除 -- **性能向上**: 軽量・直接的WASM生成 -- **制御完全掌握**: 独自実装による完全制御 - -**戦略的効果**: -- **独立性確保**: 外部ランタイム依存なし -- **Everything is Box哲学実現**: 純粋な実装 -- **メンテナンス容易**: シンプルなアーキテクチャ -- **将来拡張性**: 独自最適化の基盤確立 - -### References -- docs/予定/wasm/current_issues.md（現在の問題分析） -- docs/予定/wasm/compatibility_matrix.md（wasmtime互換性問題） -- 調査結果: WASM二重実装方式の分析結果 - ------------------------------------------------------------- - -## 🔭 Phase 9.7: Box FFI/ABI基盤 + MIR ExternCall 追加（RuntimeImports対応） - -Summary: -- 「あらゆるライブラリを箱に」を実現するための共通ABI（Box FFI/ABI）とBID（Box Interface Definition）を策定。 -- MIRに `ExternCall` 命令を導入し、WASM/VM/言語出力で外部Box APIを一貫呼び出しできる基盤を整える。 -- WASM向けには RuntimeImports をABI準拠で拡張（console/canvasの最小セットから）。 - -Why: -- nyashがRustに依存せずnyasuをビルドできるように（実行時は純WASM＋ホストimport）。 -- MIR→任意言語出力時に、外部ライブラリ（=Box API）をBID→各言語FFIへ写像しやすくする。 -- Everything is BoxのAPI設計を、外部ライブラリにも一貫適用。 - -Scope/Tasks: -- [ ] 1) ABI/BIDの策定（最優先） - - 型: i32/i64/f32/f64/string(ptr,len)/bool/boxref/array、null/void - - 呼出規約: 名前解決（namespace.box.method）、エラー/例外、同期/非同期 - - 効果: pure/mut/io/control（MIR効果と整合） - - 成果物: `docs/予定/native-plan/box_ffi_abi.md`、BIDサンプル（console/canvas） -- [ ] 2) MIR拡張: `ExternCall` - - 命令: `ExternCall(dst, iface_name, method_name, args[])` - - Verifier: BIDと型/効果の整合、最適化（pure再順序化/ mut依存）維持 - - Lowering: 既存のBoxCall/Field opsとの橋渡し -- [ ] 3) WASM RuntimeImports（ABI準拠） - - import群: `env.console.log(ptr,len)`, `env.canvas.fillRect(...)`, `env.canvas.fillText(...)` - - Host(JS): importObject実装（DOM解決→Canvas/Console呼び出し） -- [ ] 4) コード生成: ExternCall→バックエンド写像 - - WASM: import呼び出し（線形メモリから文字列復元） - - VM: ホスト関数テーブルでスタブ実装（最小はログ/ダミー） - - 言語出力: TypeScript/Python/Rust等へのFFI雛形（後続） -- [ ] 5) E2Eデモ - - Nyash→MIR(ExternCall)→WASM→ブラウザ（console/canvas） - -Acceptance Criteria: -- `docs/予定/native-plan/box_ffi_abi.md` 初版＋BIDサンプル（console/canvas）が存在 -- MIRに `ExternCall` が追加され、WASMコード生成で import 呼び出しが生成される -- ブラウザで「直接WASM出力」→Canvas描画/Console出力が成功 -- 既存PlaygroundAPIとABI経由APIが概ね一致 - -Timeline: -- Week 1: ABI/BID仕様初版＋MIR `ExternCall` 雛形 -- Week 2: WASM RuntimeImports最小（console/canvas）＋E2Eデモ -- Week 3: Verifier効果整合＋WASMコード生成の安定化 -- Week 4+: 他ライブラリBID追加、言語FFI生成の着手 - -References: -- docs/説明書/reference/box-design/ffi-abi-specification.md - ------------------------------------------------------------- - -## 🔧 Phase 9.75: Box設計根本革命 - Arc責務一元化（緊急） - -Summary: -- SocketBoxで発覚した「責務の二重化」問題を全Box型で根本解決 -- Box内部のArcを除去し、インタープリターが一元管理 -- Everything is Box哲学を守りながらシンプルで正しい設計へ - -Priority: Critical (Phase 9.7完了直後・9.8より優先) -Expected Duration: 2-3週間 -GitHub Issue: #80 - -### 問題分析 -**現状**: 15個のBox型が二重ロック構造 -```rust -// 🚨 問題構造 -Box内部: Arc> // 内部ロック -インタープリター: Arc> // 外部ロック -→ デッドロック・状態不整合・デバッグ困難 -``` - -### 技術的アプローチ -**新設計**: 純粋データコンテナ + ロック責務一元化 -```rust -// ✅ 解決策 -pub struct PlainSocketBox { - pub listener: Option, - pub is_server: bool, // Arc完全除去！ -} -// インタープリターがArc>で一元管理 -``` - -### 実装計画 -- [ ] Phase A: 設計ガイドライン策定（3日） - - Box実装パターンドキュメント作成 - - 内部Arc禁止ルール明文化 - - 新Box実装時のテンプレート作成 - -- [ ] Phase B: 最優先Box修正（1週間） - - SocketBox/HTTPServerBox（最も問題顕著） - - テストスイート作成（状態保持・並行アクセス） - - パフォーマンス計測 - -- [ ] Phase C: ステートフルBox修正（1週間） - - ArrayBox, MapBox, FileBox - - P2PBox, IntentBox, StreamBox - - weak参照との整合性確認 - -- [ ] Phase D: 残りのBox統一（3日） - - その他9個のBox型 - - 全体統合テスト - - ベンチマーク確認 - -### 🤖 Copilot協力期待 -- Arc除去の機械的リファクタリング -- Clone実装の適切な修正 -- テストケース自動生成 -- 並行アクセステスト実装 - -### 成功基準 -- [ ] 全Box型で内部Arcゼロ -- [ ] SocketBox状態保持テスト成功 -- [ ] デッドロック完全排除 -- [ ] パフォーマンス向上（ロック競合削減） -- [ ] デバッグ容易性向上 - -### 期待される効果 -- デッドロック・状態不整合の根絶 -- パフォーマンス向上（二重ロック除去） -- コード可読性・保守性の大幅改善 -- 新Box実装時の混乱防止 - -References: -- GitHub Issue #80（SocketBox状態保持問題） -- CURRENT_TASK.md（Gemini先生の根本原因分析） - ------------------------------------------------------------- - -## ⚡ Phase 9.77: WASM緊急復旧 - BoxCall/wasmtime/基本機能復活（最優先） - -Summary: -- BoxCall命令未実装により基本的なBox操作（toString, print等）がWASMで全停止している緊急事態を解決 -- wasmtimeバージョン互換性問題によるAOT実行失敗を修正 -- WASM出力エラーを根本解決し、実用的なWASM実行環境を復旧 - -Priority: **Critical** (Phase 9.75完了直後・全Phase前提条件) +Priority: **Critical** Expected Duration: 1-2週間 -GitHub Issue: 予定 +GitHub Issue: #110 (Phase 9.77a) -### 🚨 緊急問題の現状 -**基本機能全停止**: -```nyash -// ❌ 現在WASMで実行不可 -local result = value.toString() // BoxCall未実装 -print("Hello") // 基本出力不可 -``` +### 進捗状況 +- ✅ **Task 1.1**: BoxCall実装（toString, print, equals, clone, log） +- ✅ **Task 1.2**: wasmtime 18.0 → 35.0.0更新、RuntimeImports追加 +- 🔄 **Task 1.3**: UTF-8エラー原因特定（エラーメッセージ発生元不明） -**エラー例**: -```bash -❌ WASM compilation error: Unsupported instruction: BoxCall -❌ Module was compiled with incompatible Wasmtime version '18.0.4' vs '35.0.0' -❌ Generated WASM is not valid UTF-8 -``` - -### 📋 実装計画（段階的復旧） - -#### Phase 1: 基本機能復旧（1週間） -- [ ] **BoxCall命令実装** - toString(), print()等の基本メソッド -- [ ] **wasmtimeバージョン統一** - Cargo.toml更新、互換性確保 -- [ ] **WASM出力エラー修正** - WAT→WASM変換修正 - -#### Phase 2: 機能拡充（1週間） -- [ ] **RuntimeImports完全実装** - Box メモリ管理、型変換 -- [ ] **メモリ管理改善** - レイアウト最適化、ガベージコレクション - -### 🤖 Copilot協力期待 -- BoxCall→WASM命令変換の効率実装 -- wasmtimeバージョン管理の自動化 -- WASM出力パイプライン修正 -- メモリ管理最適化 - -### 成功基準 -- [ ] **基本動作復旧**: toString(), print()がWASMで動作 -- [ ] **AOT実行成功**: .cwasmファイルが正常実行 -- [ ] **WASM出力成功**: バイナリエラーなし -- [ ] **互換性確保**: バージョン依存問題解決 - -### 期待される効果 -- **即時価値**: NyashがWASMで実用可能に復帰 -- **開発継続**: 他Phase実装の前提条件満足 -- **ユーザー満足**: 基本機能の確実な動作保証 +### 🤖 Copilot協力中 +- エラーメッセージ「Generated WASM is not valid UTF-8」の発生元調査 +- WAT→WASM変換パイプラインのデバッグ References: -- docs/予定/wasm/current_issues.md（現在の問題詳細分析） -- docs/予定/native-plan/issues/phase_9_77_wasm_emergency.md（詳細実装計画） +- docs/予定/native-plan/issues/phase_9_77_wasm_emergency.md +- docs/予定/native-plan/issues/phase_9_77a_utf8_error_fix.md ------------------------------------------------------------ @@ -434,58 +122,61 @@ Acceptance: ## 🏆 Phase 10: LLVM Direct AOT（最高性能実現） Summary: -- MIR→LLVM IR直接変換による最高性能AOT実現（Cranelift JITスキップ） -- ExternCallはprintf等へ写像し、段階的にネイティブ最適化を実現 +- MIR→LLVM IR直接変換による最高性能AOT実現 +- インタープリターとの併用で最適な開発・実行体験を提供 +- 非同期処理フルサポート（async/await のネイティブ実装） -Priority: Medium (Phase 9.5完了後) +Priority: High (Phase 9.77完了後) Expected Duration: 4-6ヶ月 -### 🏗️ Phase 10.0: LLVM Backend Skeleton（基盤実装） +### 🌟 インタープリター併用戦略 +``` +開発・デバッグ: インタープリター（即時実行・完全な情報） +軽量タスク: インタープリター（Pythonライク） +性能要求時: LLVM AOT（1000倍高速化） +Web配布: WASM（ブラウザ対応） +``` + +### 🏗️ Phase 10.1: 同期版LLVM実装（3ヶ月） Implementation Steps: -1) `src/backend/llvm/` 追加（mod.rs/lower.rs/passes.rs/build.rs） -2) 依存: Cargoへ`llvm-sys`（feature化）、ビルド要件整備 -3) `LLVMBackend::compile_mir`（lower→passes→emit object） -4) `main`: i32()、voidは0に正規化 -5) 型写像: i32/i64/f32/f64/bool, 文字列は(i8*,i32)、Box参照はi32 or i8* -6) 命令: Const/BinOp/Compare/Branch/Jump/Phi/Call/Return ほか基本 -7) ExternCall: console.log(ptr,len)→printf("%.*s",len,ptr)、canvasはnoop/ログ -8) 文字列定数: @.str + getelementptr -9) 出力: TargetMachineで.o生成、`clang app.o -o app` -10) CLI: `--backend llvm --emit obj` -11) 最小テスト: 四則/分岐/ループ/ExternCall出力 +1) `src/backend/llvm/` 基盤構築 +2) MIR→LLVM IR基本変換 +3) Box操作の最適化（エスケープ解析） +4) ベンチマーク: 100倍目標 + +### 🌐 Phase 10.2: 非同期拡張（2ヶ月） + +非同期サポート戦略: +- **async/await ネイティブ実装**: Rust風の効率的な非同期 +- **軽量ランタイム**: 独自Future実装 +- **インタープリター互換**: 同じ非同期セマンティクス + +```rust +// Phase 10.2: 非同期LLVM実装 +FutureNew → LLVM coroutine intrinsics +Await → LLVM suspend/resume points +FutureSet → completion notification +``` ### 技術アプローチ 🤖 Copilot協力期待: - **LLVM統合**: MIR→LLVM IR変換基盤 +- **非同期実装**: coroutine/suspend points - **エスケープ解析**: Box→スタック値最適化 - **型特殊化**: コンパイル時型推論・特殊化 -- **LTO統合**: Link-time optimization -- **PGO対応**: Profile-guided optimization - -### Everything is Box最適化戦略 -- **Box回避**: スタック割り当て・直接レジスタ配置 -- **NaN Boxing**: 効率的な値表現 -- **型推論**: コンパイル時型特定・最適化 -- **メモリレイアウト**: 連続配置・キャッシュ効率 ### パフォーマンス目標 -- **実行性能**: 1000倍高速化（現在13.5倍 → 目標13500倍相当） +- **同期処理**: 100-1000倍高速化 +- **非同期処理**: Tokio並みの効率性 - **メモリ効率**: Box割当数80%削減 - **起動時間**: ネイティブレベル（<10ms） -- **競合比較**: C/C++/Rust並みの性能 ### Acceptance Criteria -- 1000倍高速化達成 +- インタープリターとの完全な互換性 +- 非同期処理の効率的実装 +- 1000倍高速化達成（同期処理） - プロダクションレベル最適化 -- 他言語との競争力確立 - -### Cranelift JIT位置づけ変更 -**Phase 12以降の将来オプション**: -- JIT開発体験向上（nyashプログラマー向け） -- REPL・インタラクティブ実行 -- プロファイル駆動最適化 -- 言語完成後の付加価値機能 References: - docs/予定/native-plan/issues/phase_10_x_llvm_backend_skeleton.md @@ -624,42 +315,39 @@ Acceptance Criteria: 💡 Copilot様への具体的お願い・相談事項 ================================================================================ -## 🔧 Phase 8.3完了・次期フェーズ準備 +## 🔧 Phase 9.77 緊急対応 -### MIRダイエット準備 -❓ 現在35命令→20命令削減のintrinsic戦略実装は？ -❓ ChatGPT5推奨の3-point setアプローチ最適化は？ -❓ Portability Contract v0での互換性確保方法は？ +### UTF-8エラー調査（Issue #110） +❓ エラーメッセージ「Generated WASM is not valid UTF-8」の発生元は？ +❓ wabt::wat2wasm以外でエラーが出ている可能性は？ +❓ runner.rs/main.rsのエラー処理フローは？ -### Phase 9 AOT WASM実装（最優先） -❓ wasmtime compileの実用配備方法は？ -❓ .cwasm生成・単一バイナリ梱包戦略は？ -❓ 互換性キー管理（CPU機能・wasmtimeバージョン）は？ -❓ 起動時間最適化の実装アプローチは？ - -### Phase 9.5 HTTPサーバー検証 -❓ Socket・HTTP実装の効率的な設計は？ -❓ 並行処理でのメモリ管理パターンは？ -❓ AOT環境でのI/Oリソース管理は？ -❓ 負荷テスト・ベンチマーク設計は？ - -### Phase 10 LLVM Direct AOT -❓ MIR→LLVM IR変換の効率実装は？ -❓ エスケープ解析・ボックス化解除の実装戦略は？ -❓ LTO・PGO統合の技術的ハードルは？ +### WASM基本機能復旧 +❓ 最小テストケース（`local result = 42`）のデバッグ方法は？ +❓ WAT生成パイプラインの問題箇所特定は？ +❓ 効率的なデバッグ戦略は？ ## 🚀 長期戦略相談 +### インタープリター併用戦略 +❓ 開発時と本番時の最適な使い分け方法は？ +❓ インタープリターとコンパイラの互換性保証は？ +❓ Pythonライクな実用性の実現方法は？ + +### Phase 10 LLVM Direct AOT +❓ 非同期処理のネイティブ実装戦略は？ +❓ LLVM coroutine intrinsicsの活用方法は？ +❓ インタープリターとの非同期セマンティクス統一は？ + ### Everything is Box最適化 ❓ Box操作の根本的高速化戦略は？ ❓ エスケープ解析によるスタック化判定は？ ❓ 型特殊化・ボックス化解除の実装戦略は？ -### ベンチマーク拡張 -❓ AOT性能測定の追加指標は？ -❓ 1000倍高速化実現のマイルストーン設計は？ -❓ 他言語(JavaScript V8, Rust, C++)との競争力分析は？ -❓ HTTPサーバー負荷テストの効率設計は？ +### ベンチマーク戦略 +❓ インタープリター/VM/WASM/LLVMの性能比較方法は？ +❓ 非同期処理のベンチマーク設計は？ +❓ 実用アプリケーションでの測定指標は？ ================================================================================ 📊 進捗管理・コミュニケーション @@ -688,25 +376,26 @@ Acceptance Criteria: 🎯 期待される成果・インパクト ================================================================================ -## Phase 8完了時の成果 (達成済み) +## Phase 8-9完了時の成果 (達成済み) 🏆 RefNew/RefGet/RefSet WASM完全動作 🏆 Box操作ベンチマーク追加 🏆 メモリレイアウト最適化効果測定 -🏆 オブジェクト指向プログラミングWASM対応 🏆 26命令MIR階層化完了（Phase 8.5） 🏆 VM性能改善完了（Phase 8.6） +🏆 警告削減100%達成（Phase 9.75j） +🏆 BoxCall実装・wasmtime更新（Phase 9.77） -## Phase 9-10実用優先展望 -🚀 **AOT WASM実装** (Phase 9 - 2-3週間): 配布可能実行ファイル -🚀 **HTTPサーバー検証** (Phase 9.5 - 2週間): 実用アプリデモ -🚀 **LLVM Direct AOT** (Phase 10 - 4-6ヶ月): 1000倍高速化 -🚀 **実用競争力確立**: 他言語との差別化完成 +## Phase 10以降の展望 +🚀 **WASM復旧完了** (Phase 9.77): 基本機能の完全動作 +🚀 **LLVM Direct AOT** (Phase 10): 100-1000倍高速化 +🚀 **非同期ネイティブ実装** (Phase 10.2): async/await完全対応 +🚀 **インタープリター併用** : 開発・本番両対応 ## 言語としての完成度向上 💎 Everything is Box哲学のネイティブ実現 -💎 開発効率性と実行性能の両立 -💎 4つの実行形態対応（Interpreter/VM/WASM/AOT）+ 将来JIT -💎 現代的言語としての地位確立 +💎 インタープリター＋コンパイラの最適併用 +💎 4つの実行形態対応（Interpreter/VM/WASM/AOT） +💎 Pythonライクな実用性＋C++並みの性能 ================================================================================ 📞 連絡・相談方法 @@ -723,13 +412,14 @@ Acceptance Criteria: 一緒にNyashを最高の言語にしていきましょう🚀 ================================================================================ -最終更新: 2025-08-14 (実用優先戦略・Phase 9-10再設計完了) -作成者: Claude (AI大会議結果 + 実用優先戦略統合) +最終更新: 2025-08-16 (インタープリター併用戦略統合・Phase整理) +作成者: Claude (インタープリター価値認識 + Phase重複削除) 🎯 重要な変更点: -- Phase 9: JIT planning → AOT WASM実装（最優先） -- Phase 9.5: HTTPサーバー実用テスト追加（AOT検証） -- Phase 10: AOT exploration → LLVM Direct AOT（最高性能） -- Cranelift JIT: Phase 12以降の将来オプションに変更 -- HTTPサーバー: kilo後のタイミングで実用性能検証に特化 +- Phase 9.5: 削除（完了済み） +- Phase 9.6/9.7: 削除（Phase 9.77と重複） +- Phase 9.75: 削除（完了済み） +- Phase 9.77: 進行中（UTF-8エラー修正中、Issue #110） +- Phase 10: インタープリター併用戦略・非同期ネイティブ実装追加 +- インタープリター: 開発だけでなく本番でも実用的（Pythonライク） ================================================================================ diff --git a/docs/予定/native-plan/issues/phase_9_77a_utf8_error_fix.md b/docs/予定/native-plan/issues/phase_9_77a_utf8_error_fix.md new file mode 100644 index 00000000..54d4590f --- /dev/null +++ b/docs/予定/native-plan/issues/phase_9_77a_utf8_error_fix.md @@ -0,0 +1,134 @@ +# Phase 9.77a: WASM UTF-8エラー原因特定と修正 + +## 🚨 緊急度: 最高 + +**前提**: Phase 9.77の Task 1.1（BoxCall実装）と Task 1.2（wasmtime更新）は完了済み。Task 1.3のUTF-8エラーのみ未解決。 + +## 🐛 問題の詳細 + +### エラー内容 +```bash +$ ./target/debug/nyash --compile-wasm local_tests/test_simple_wasm.nyash +🌐 Nyash WASM Compiler - Processing file: local_tests/test_simple_wasm.nyash 🌐 +❌ Generated WASM is not valid UTF-8 +``` + +### テストケース（最小再現） +```nyash +# local_tests/test_simple_wasm.nyash +local result = 42 +``` + +### 🔍 調査済み内容 + +1. **エラーメッセージの発生元が不明** + - `grep -r "Generated WASM is not valid UTF-8"` で見つからない + - `grep -r "not valid UTF-8"` でも見つからない + - ソースコード内に該当文字列が存在しない + +2. **実装済み修正（効果なし）** + ```rust + // src/backend/wasm/mod.rs + fn wat_to_wasm(&self, wat_source: &str) -> Result, WasmError> { + // UTF-8検証を追加 + if !wat_source.is_ascii() { + return Err(WasmError::WasmValidationError( + "WAT source contains non-ASCII characters".to_string() + )); + } + + // wabt::wat2wasm に as_bytes() を追加 + let wasm_bytes = wabt::wat2wasm(wat_source.as_bytes())?; + Ok(wasm_bytes) + } + ``` + +3. **デバッグ出力を追加済み（しかし表示されない）** + ```rust + eprintln!("🔍 WAT Source Debug (length: {}):", wat_source.len()); + eprintln!("WAT Content:\n{}", wat_source); + eprintln!("✅ WAT source is ASCII-compatible"); + eprintln!("🔄 Converting WAT to WASM bytes..."); + ``` + - これらのデバッグ出力が一切表示されない + - wat_to_wasm() が呼ばれていない可能性 + +## 🎯 調査すべきポイント + +### 1. エラーメッセージの発生元 +- [ ] main.rs または runner.rs でのエラー処理を確認 +- [ ] --compile-wasm オプションの処理フローを追跡 +- [ ] 外部プロセスやツールがエラーを出力している可能性 + +### 2. WASM生成パイプライン全体 +``` +Nyashソース → AST → MIR → WAT → WASM + ↑ + ここで失敗？ +``` + +### 3. 可能性のある原因 +- wabt crate 以外の場所でWASM生成している？ +- ファイル出力時にUTF-8エラーが発生？ +- 標準出力への書き込みでエラー？ + +## 🔧 具体的な作業手順 + +### Step 1: エラーメッセージの発生元特定 +```bash +# 1. main.rs の --compile-wasm 処理を確認 +# 2. runner.rs の compile_wasm メソッドを追跡 +# 3. エラーメッセージがどこで出力されているか特定 +``` + +### Step 2: デバッグ情報の追加 +```rust +// エラーが発生している場所に以下を追加 +eprintln!("DEBUG: 処理フロー確認ポイント"); +eprintln!("DEBUG: 変数の内容 = {:?}", variable); +``` + +### Step 3: 修正案 +1. **エラーメッセージがwabt外部から来ている場合** + - 正しいエラーハンドリングを実装 + - UTF-8検証を適切な場所に移動 + +2. **ファイル出力でエラーの場合** + - バイナリファイル出力を明示的に指定 + - stdout への出力方法を見直し + +3. **WAT生成に問題がある場合** + - WAT形式の検証強化 + - 特殊文字のエスケープ処理追加 + +## 📝 テスト方法 + +```bash +# 1. 最小テストケースで確認 +./target/debug/nyash --compile-wasm local_tests/test_simple_wasm.nyash + +# 2. デバッグ出力付きで実行 +RUST_LOG=debug ./target/debug/nyash --compile-wasm local_tests/test_simple_wasm.nyash 2>&1 | tee debug.log + +# 3. WAT出力のみテスト（もし可能なら） +./target/debug/nyash --compile-wat local_tests/test_simple_wasm.nyash +``` + +## 🎯 成功基準 + +1. エラーメッセージの発生元が特定される +2. 最小テストケース（`local result = 42`）がWASMにコンパイルできる +3. 生成されたWASMファイルが wasmtime で実行可能 + +## 🚀 期待される成果 + +Phase 9.77完了により、NyashのWASMバックエンドが復旧し、以下が可能になる： +- BoxCall命令（toString, print等）がWASMで動作 +- AOTコンパイル（.cwasm）が生成可能 +- ブラウザでのNyash実行への道筋 + +--- + +**優先度**: 🔥 最高（WASMバックエンド全体がブロックされている） +**推定作業時間**: 2-4時間 +**依存関係**: Phase 9.77 Task 1.1, 1.2は完了済み \ No newline at end of file