tomoaki/hakorune
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
c82ae2365f0fdbe7c17a1083e54f4bed96abe1cc
hakorune/CURRENT_TASK.md
nyash-codex c82ae2365f refactor(joinir): Phase 44 - Capability-based shape guard 
Refactor shape detection from function-name-based to capability-based
architecture for better extensibility and maintainability.

Key changes:
- ShapeCapabilityKind enum: P2CoreSimple/SkipWs/Atoi/ParseNumber
- ShapeCapability: Capability descriptor with future extensibility
- Helper functions:
  - capability_for_shape(): Map shape to capability
  - is_canonical_shape(): Exact shape-level check
  - is_p2_core_capability(): Broad capability family check
  - is_supported_by_normalized(): Normalized dev support

Benefits:
- Extensibility: Easy to add new capability kinds
- Clarity: Shape purpose explicit in kind names
- Maintainability: Centralized mapping vs scattered ifs
- Future-ready: Infrastructure for carrier roles, method signatures

Backward compatibility:
- Zero behavioral changes (pure refactoring)
- Canonical set preserved: Pattern2Mini, skip_ws mini/real, atoi mini
- All existing code paths unchanged

Tests: 937/937 PASS
Files: +78 lines (shape_guard.rs), design doc created
2025-12-12 04:06:03 +09:00

165 lines
16 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Current Task
このファイルは「いま何に集中しているか」と「次にやり得る候補」だけを書く軽量ビューだよ。
詳細なログや過去フェーズの記録は `docs/development/current/main/` 以下の各 `phase-*.md` と
`docs/development/current/main/joinir-architecture-overview.md` を真実のソースとして扱うよ。
---
## 🎯 今フォーカスしているテーマ（2025-12-10 時点のスナップショット）
### 0. JoinIR / ExprLowerer / Pattern2–4 + JsonParser `_parse_number` / DigitPos ライン（Phase 230–247-EX 完了）✅
- Pattern1–4（while / break / if‑PHI / continue）＋ P5(Trim) でループ lowering を JoinIR 経路に一本化。
- Phase 231/236/240-EX:
- Pattern2 の header / break 条件を ExprLowerer/ScopeManager 経由（対応パターンのみ）で本番導線化。
- ConditionEnv ベースの意味論と RC/JoinIR 構造が一致することをテストとカタログで確認済み。
- Phase 237–238-EX:
- JsonParser/selfhost の条件パターンをカタログ化し、ExprLowerer/ScopeManager/ConditionEnv の責務境界を docs/README で固定。
- Phase 241–242-EX:
- array_filter 系 3 FAIL を「構造で」解消（hardcode `"sum"` チェック削除、CarrierInfo/ExitMeta 経由に統一）。
- Pattern3 if‑sum / Pattern4 continue から legacy lowerer と by-name `"sum"`/`"count"` を完全削除。
- 複雑条件（`i % 2 == 1`）を ConditionPattern/if-sum lowerer で安全に扱えるよう整理（Fail-Fast + テスト付き）。
- Phase 243–244-EX:
- Pattern3/4 の公開 API を `can_lower + lower` の最小セットに整理し、内部 helper を箱の中に閉じた。
- `loop_pattern_detection` の classify() が代表ループを P1〜P4 に分類することをユニットテストで固定。
- Phase 245-EX / 245C:
- `_parse_number` のループについて、ループ変数 `p` の header/break 条件と `p = p + 1` 更新を Pattern2 + ExprLowerer 経路に載せて本番化。
- FunctionScopeCapture / CapturedEnv を拡張し、関数パラメータ（例: `s`, `len`）をループ条件/本体で読み取り専用なら CapturedEnv 経由で ConditionEnv に載せるようにした。
- これにより、`p < s.length()` のような header 条件や JsonParser 系ループでのパラメータ参照が、ExprLowerer/ScopeManager から安全に解決される。
- Phase 245B-IMPL:
- `_parse_number` 本体で `num_str = num_str + ch` を LoopState キャリアとして扱い、Program(JSON) フィクスチャ `jsonparser_parse_number_real` を Structured→Normalized→MIR(direct) で dev テスト固定（出力は num_str 文字列）。
- Phase 247-EX:
- DigitPos promotion を二重値化し、`digit_pos` から boolean carrier `is_digit_pos`（ConditionOnly）と integer carrier `digit_value`（LoopState）を生成。
- UpdateEnv で `digit_pos` 解決時に `digit_value` を優先し、NumberAccumulation（`result = result * 10 + digit_pos`）と break 条件の両方で DigitPos パターンが安全に利用可能に。
- 現在: `cargo test --release --lib` で 931/931 テスト PASS（既知 FAIL なし）。
- Phase 28-NORM-P2（dev-only）:
- Normalized JoinIR のミニ実装を Pattern1 に続き Pattern2 最小ケースまで拡張（Structured→Normalized→Structured を比較）。
- 対応外の Structured JoinModule では normalize_pattern2_minimal が Fail-Fast するようガードを追加し、normalized_dev テストで固定。
- Phase 29-NORM-P2-APPLY（dev-only）:
- Phase 34 の break fixture（i/acc/n の単純 break ループ）を Structured→Normalized→Structured の往復に通し、VM 実行結果が Structured 直経路と一致することを dev テストで固定。
- ガードは 3 パラメータまで緩和しつつ、DigitPos/Trim などの重いキャリアはまだ非対応のまま。
- Phase 30-NORM-P2-DEV-RUN（dev-only）:
- JoinIR runner に `NYASH_JOINIR_NORMALIZED_DEV_RUN=1` を追加し、Pattern1/2 ミニケースだけ Structured→Normalized→Structured を挟んで dev 実行できるようにした（`normalized_dev` + debug 限定）。通常経路（Structured→MIR）は不変。
- Phase 31-NORM-JP-MINI（dev-only）:
- JsonParser 系のシンプルな P2 ループ（skip_whitespace ミニ fixture）を Structured→Normalized→Structured 経由でも実行し、runner dev スイッチの比較テストで Structured 直経路と一致することを固定。
- Phase 32-NORM-CANON-PREP（dev-only）:
- JoinIR→MIR ブリッジの入口を `bridge_joinir_to_mir` に一本化し、normalized_dev スイッチ（feature + env）で Structured→Normalized→Structured の dev roundtrip を切り替える準備を整えた。P1/P2/JP mini の比較テストも VM ブリッジ経路で追加。
- Phase 33-NORM-CANON-TEST（dev-only）:
- P1/P2（Phase 34 break fixture）/JsonParser skip_ws mini について、normalized_dev ON 時は shape_guard 経由で必ず Normalized roundtrip を通すようブリッジと runner を固めた。normalized_joinir_min.rs の runner/VM 比較テストを拡張し、Normalized が壊れたら dev スイートが必ず赤になるようにした（本番 CLI は従来どおり Structured→MIR）。
- Phase 34-NORM-ATOI-DEV（dev-only）:
- JsonParser `_atoi` ミニループ（digit_pos→digit_value + NumberAccumulation）を normalized_dev 経路に載せ、Structured↔Normalized↔Structured の VM 実行結果が一致することをフィクスチャテストで固定。`jsonparser_atoi_mini` を shape_guard で認識し、既定経路は引き続き Structured→MIR のまま。
- Phase 35-NORM-BRIDGE-MINI（dev-only）:
- P1/P2 ミニ + JsonParser skip_ws/atoi ミニを Normalized→MIR 直ブリッジで実行できるようにし、normalized_dev ON 時は Structured→Normalized→MIR（復元なし）経路との比較テストで結果一致を固定。既定経路（Structured→MIR）は不変。
- Phase 36-NORM-BRIDGE-DIRECT（dev-only）:
- Normalized ブリッジを direct 実装（Normalized→MIR）と Structured 再構成に分離し、shape_guard で P1/P2 ミニ + JsonParser skip_ws/atoi ミニだけ direct 経路に通すよう整理。非対応は `[joinir/normalized-bridge/fallback]` ログ付きで再構成に落とし、テストで direct/従来経路の VM 出力一致を固定。
- Phase 37-NORM-JP-REAL（dev-only）:
- JsonParser `_skip_whitespace` 本体の P2 ループを Program(JSON) フィクスチャで Structured→Normalized→MIR(direct) に通し、Structured 直経路との VM 出力一致を比較するテストを追加。`extract_value` が `&&`/`||` を BinOp として扱えるようにし、Break パターンの param 推定を柔軟化して real 形状でも panic しないようにした。
- Phase 38-NORM-OBS（dev-only）:
- Normalized/JoinIR dev 経路のログカテゴリを `[joinir/normalized-bridge/*]` / `[joinir/normalized-dev/shape]` に統一し、`JOINIR_TEST_DEBUG` 下だけ詳細を出すよう静音化。Verifier/Fail‑Fast メッセージも shape/役割付きに整え、デバッグ観測性を上げつつ通常実行のノイズを減らした。
- Phase 43-A（dev-only）:
- JsonParser `_atoi` 本体の Program(JSON) フィクスチャを normalized_dev に追加し、Structured→Normalized→MIR(direct) と Structured→MIR の VM 出力を比較するテストで一致を固定（符号あり/なしの簡易パス対応。canonical 切替は後続フェーズ）。
- Phase 43-C（dev-only）:
- JsonParser `_parse_number` 本体の Program(JSON) フィクスチャを normalized_dev に追加し、Structured→Normalized→MIR(direct) と Structured→MIR の VM 出力を比較するテストで一致を固定（num_str は現状仕様のまま据え置き、P2-Mid の足慣らし）。
- **Phase 45-NORM-MODE（実装済み✅ 2025-12-12）**:
- JoinIR モード一本化: バラバラだったフラグ/feature を `JoinIrMode` enum に集約（StructuredOnly / NormalizedDev / NormalizedCanonical）。
- `current_joinir_mode()` でモード取得、bridge/runner で `normalized_dev_enabled()` → mode pattern matching に移行。
- Canonical P2-Core は mode 無視で常に Normalized→MIR(direct)、それ以外は mode に従う統一ルーティング。
- 937/937 tests PASS（既存挙動完全保持のリファクタ）。
- **Phase 44-SHAPE-CAP（実装済み✅ 2025-12-12）**:
- Shape検出を capability-based に変更: `NormalizedDevShape` → `ShapeCapability` 抽象化層導入。
- `ShapeCapabilityKind` 4種: P2CoreSimple / P2CoreSkipWs / P2CoreAtoi / P2MidParseNumber。
- Shape-level (`is_canonical_shape`) と Capability-level (`is_p2_core_capability`) の二層 API でパターン拡張性を確保。
- 既存挙動完全保持（canonical set: Pattern2Mini, skip_ws mini/real, atoi mini のまま）、937/937 tests PASS。
### 1. いまコード側で意識しておきたいフォーカス
- JoinIR ループ基盤（Pattern1–4 + ExprLowerer + ScopeManager + CapturedEnv）は一応の完成状態に入ったので、当面は:
- 既存パターン/箱の範囲内での **バグ修正・Fail‑Fast/invariant 追加・テスト強化** を優先する。
- JsonParser/selfhost への新しい適用や大きな仕様拡張は、docs 側で Phase 設計が固まってからコード側に持ち込む。
- 直近のコード側フォーカス候補:
- Phase 246-EX（コード）: JsonParser `_atoi` のループを Pattern2 + NumberAccumulation + DigitPos 二重値インフラ上に載せる。
- header/break 条件を ExprLowerer/ConditionEnv/FunctionScopeCapture 経由で JoinIR に lower。
- `result = result * 10 + digit_pos` を NumberAccumulation + `digit_value` carrier で扱い、従来の意味論を E2E テストで固定する。
- Pattern1–4 / ExprLowerer / ScopeManager まわりで、by-name ハードコードやサイレントフォールバックが見つかった場合は、
CarrierInfo / ConditionEnv / Scope 情報を使って「構造で」直す。
### 2. 直近で意識しておきたい設計の芯
- **Loop パターン空間**は有限で整理済み:
- P1: Simple While
- P2: Break
- P3: If‑PHI（単一/複数キャリア）
- P4: Continue（then/else‑continue 正規化込み）
- P5: LoopBodyLocal 昇格（Trim/JsonParser 用の部分適用）
- 「増やすべき」は新しい Pattern ではなく、既存 Pattern の前処理箱:
- BoolExprLowerer / ConditionEnv / LoopConditionScopeBox / LoopBodyCarrierPromoter /
TrimLoopHelper / ComplexAddendNormalizer / LoopBodyLocalEnv / UpdateEnv などで
条件式とキャリア更新を吸収し、Pattern1–4 は「ループ骨格」に専念させる方針。
- Fail‑Fast 原則:
- JoinIR 以外のループ lowering パスは存在しない（LoopBuilder は削除済み）。
- 「わからないパターン」は必ず `[joinir/freeze]` 系の明示エラーにして、サイレントフォールバックはしない。
---
## ✅ 最近まとまった大きな塊（超要約）
ここ半年くらいで終わっている主な塊だけをざっくり書くね。
細かいタスク・バグ票・議論は `docs/development/current/main/phase-*.md` と
`docs/development/current/main/joinir-architecture-overview.md` に全部残っているので、必要になったときだけそちらを読む想定。
- **LoopBuilder 削除ライン（Phase 180 前後）**
- LoopBuilder を dev‑only → hard freeze → 物理削除まで完了。
- Loop lowering の SSOT を JoinIR に一本化。
- **LoopPattern / Router ライン（Phase 170–179, 244-EX）**
- LoopFeatures / LoopPatternKind / PatternRouter / PatternPipelineContext を整備。
- Pattern1–4 の検出・ルーティングを「構造ベース＋AST features」で統一（関数名ベタ書き依存を除去）。
- Phase 244-EX で代表ループ（P1〜P4）の classify() 結果をユニットテストで固定。
- **Exit / Boundary / ValueId ライン（Phase 172–205）**
- ExitMeta / ExitLineReconnector / JoinInlineBoundary(+Builder) / LoopHeaderPhiBuilder を箱化。
- JoinValueSpace（Param/Local 領域）＋ PHI 契約 Verifier で ValueId 衝突と PHI 破損を根治。
- **P5(Trim/JsonParser) ライン（Phase 171–176, 173–175, 190–193）**
- LoopBodyLocal 昇格パイプライン（Trim, `_skip_whitespace`, `_parse_string` 簡易版）を構築。
- StringAppend / NumberAccumulation / Complex addend 正規化など、更新式まわりの箱を揃えた。
- **P3/P4 (If‑PHI / Continue) 汎用化ライン（Phase 195–196, 212–215, 220–242-EX）**
- multi‑carrier P3 の JoinIR 生成を整理し、if‑sum 最小パターンを AST ベースで一般化（sum+count まで無改造対応）。
- Pattern3/4 if‑sum/continue lowerer を分離箱にして、legacy PoC lowerer と by-name ハードコード（`"sum"`, `"count"`）を削除。
- Pattern4CarrierAnalyzer を純粋な「キャリア解析箱」として仕上げ、continue 正規化・更新式解析をユニットテストで固定。
このあたりが「JoinIR ループ基盤の芯」で、以降の Phase は JsonParser/selfhost の各ループへの適用フェーズ、という位置づけだよ。
---
## 🧭 これからの候補（まだ「やる」とは決めていないメモ）
ここは「やることリスト」ではなく「今後やるとしたらこの辺」というメモだよ。
実際に着手するタイミングで、別途 Phase/タスクを切る想定。
1. Phase 245B（コード）: JsonParser `_parse_number` の `num_str` を LoopState carrier として Pattern2/P5 ラインに統合
- UpdateExpr で `num_str = num_str + ch` 1 形だけを許可し、StringAppend 経路で JoinIR に落とす。
- ExitMeta/JoinIR/E2E テストで num_str/p/戻り値の意味論を従来どおり固定する。
2. Phase 246-EX（コード）: JsonParser `_atoi` を Pattern2 + NumberAccumulation ラインに統合
- `_atoi` のループを Pattern2 detect → Pattern2 lowerer に接続し、DigitPos 二重値 + NumberAccumulation で数値更新を扱う。
- JsonParser の `_atoi` 呼び出しテスト（既存 or 追加）で、JoinIR 経路でも従来どおりのパース結果になることを固定する。
3. JsonParser 残りループへの JoinIR 展開
- `_parse_array` / `_parse_object` / `_unescape_string` / 本体 `_parse_string` など。
- 既存の P2/P3/P4＋P5 パイプラインをどこまで延ばせるかを docs 側で設計 → コード側はその設計に沿って小さく実装。
4. selfhost depth‑2 ラインの再開
- `.hako` 側で Program/MIR JSON を読んで JoinIR/MIR/VM/LLVM に流すライン。
- JsonParser 側のカバレッジが上がったあとに、小さいループから順に移植する。
5. JoinIR Verify / 最適化まわり
- すでに PHI/ValueId 契約は debug ビルドで検証しているので、
必要なら SSA‑DFA や軽い最適化（Loop invariant / Strength reduction）を検討。
---
## 📎 このファイルの運用ルール（自分向けメモ）
- 過去フェーズの詳細な ToDo/Done リストは **CURRENT_TASK には書かない**。
代わりに `docs/development/current/main/phase-*.md` と `joinir-architecture-overview.md` を SSOT として維持する。
- CURRENT_TASK は「あくまで最新のフォーカスと次の候補だけ」に絞る。
目安として **このファイル自体は 2〜3画面程度（〜300行以内）** に収める。
- 新しい大フェーズを始めたら：
1. まず docs 配下に `phase-XXX-*.md` を書く。
2. CURRENT_TASK には「そのフェーズの一行要約」と「今のフォーカスかどうか」だけを書く。
Reference in New Issue View Git Blame Copy Permalink