d4597dacfa
Extend CapturedEnv to include function parameters used in loop conditions, enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`. Phase 245C changes: - function_scope_capture.rs: Add collect_names_in_loop_parts() helper - function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic - function_scope_capture.rs: Add 4 new comprehensive tests Test fix: - expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support (validation happens during lowering in MethodCallLowerer) Problem solved: "Variable not found: s" errors in loop conditions Test results: 924/924 PASS (+13 from baseline 911) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2.1 KiB
2.1 KiB
Status: Draft
Scope: _parse_number で num_str を Pattern2/P5 のキャリアとして扱うかどうかを決める設計フェーズ（コード変更なし）。
Phase 245B: JsonParser _parse_number の num_str キャリア設計
1. 目的
_parse_numberで数値文字列を蓄積するnum_strを、JoinIR Pattern2/P5 のキャリアとして扱うかを決める。- UpdateExpr の許容範囲（例:
num_str = num_str + ch）と、どのテストで意味論を固定するかを先に書き下す。
2. 論点
- キャリア化するか:
- Option A:
num_strをキャリアとして Pattern2 に含める（LoopHeader PHI/ExitLine まで通す）。 - Option B: 今フェーズは
pのみ、num_strは後続（言語仕様/意味論決定後）に回す。
- Option A:
- 許可する UpdateExpr:
- 文字連結パターン（
num_str = num_str + ch）のみを許容するか。 - それ以外の文字列操作（substring/indexOf 等）は当面禁止するか。
- 文字連結パターン（
- 依存する箱:
- CarrierUpdateEmitter が文字列連結を安全に扱えるか（型/ValueId の整合）。
- ExprLowerer/MethodCallLowerer で文字列メソッドが必要か。
3. テストで固定したいこと（候補）
- 正常系:
"42"→num_str == "42",p == len, RC/ログ従来通り。 - 非digit混在:
"7z"→ break でnum_str == "7", RC/ログ従来通り。 - 既存の JsonParser スモークがあればそれを JoinIR 経路で回して差分が出ないことを確認。
4. 進め方（小タスク案）
- UpdateExpr の whitelist を決める（文字連結のみ/その他禁止）。
- CarrierInfo に
num_strを入れるかどうかを設計メモに明記。 - どのテストで意味論を固定するかを列挙（既存/新規）。
- これらを決めてからコード側 Phase 245B（小変更）に着手する。
5. メモ
- Phase 245-EX では
pのみ JoinIR Pattern2 に載せた。num_strの扱いは未決。 - 文字列キャリアは ValueId/ExitLine との整合が崩れやすいので、Fail-Fast 原則を崩さずに小さく導入すること。