Files
hakorune/docs/development/current/main/phases/phase-285/P0-INSTRUCTIONS.md
tomoaki 58ceb3de2f feat(smoke): Phase 285 P2 - weak conformance smokes (success pattern)
Phase 285 P2: weak の意味論(weak <expr> + weak_to_strong() 成功/失敗)を integration smoke で固定

実装内容:
- Fixture A(成功パターン): exit 0 → exit 2 に変更(fail=1, success=2 で明確化)
- Fixture B(失敗パターン): 明示 drop (x = null) 方式で作成
- VM smoke success: PASS
- LLVM smoke success: SKIP(backend unavailable)
- VM/LLVM smoke fail: SKIP(hidden root 問題で理由付き)

既知の問題:
- x = null で明示 drop しても weak_to_strong が成功(hidden root が strong ref を保持)
- Phase 285 P2.1 (investigation) で root 保持箇所を棚卸し予定

スコープ:
- Block scope drop conformance は別タスク(未整合の可能性あり)
- P2 では明示 drop 方式で weak の最小意味論(non-owning)のみを検証

検証:
- quick smoke 154/154 PASS 維持
- integration smoke 4本(success 2本 PASS/SKIP、fail 2本 SKIP)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-26 11:33:12 +09:00

3.2 KiB
Raw Blame History

Status: Active
Date: 2025-12-26
Scope: Phase 285 P0docs-only手順書。コード変更なしで “Box lifecycle / weakref / finalization / GC” の SSOT と差分運用を固定する。
Related:

  • docs/development/current/main/phases/phase-285/README.md
  • docs/reference/language/lifecycle.md
  • docs/reference/language/types.md

Phase 285 P0docs-only: Box lifecycle / weakref / finalization / GC SSOT

目的: “実装が仕様” になっている Box の寿命・弱参照・最終化を、docs と smoke の SSOT に固定する。

1. このP0でやることコード変更なし

  1. 仕様SSOTを 1 ファイルにまとめる

    • 言語レベルの SSOT は docs/reference/language/lifecycle.mdlifecyle/weak/fini/GCdocs/reference/language/types.mdtruthiness と null/void)に集約する。
    • Phase 285 は「実装の棚卸し・差分追跡・受け入れ条件」を書く言語SSOTを書き換えない
  2. 用語と境界を固定する

    • strong/weak/roots/finalizer/collection の定義
    • weakref の APIweak_to_strong/生存判定)
    • finalizer の禁止事項(再入・例外・順序)
  3. LLVM harness の扱いを明文化する

    • 未対応なら “未対応” を差分として書く(差分を隠さない)。
    • 差分は「仕様差」ではなく「未実装/バグ/保留」として分類する言語SSOTは揺らさない

2. README に必ず書く事項(チェックリスト)

  • “roots” は何かstack/local/global/handle/plugin 等)
  • strong/weak の意味weak_to_strong の成否条件)
  • finalizer はあるか/いつ発火するか/何が禁止か
  • GC/解放のトリガ(自動/手動/閾値/テスト用)
  • VM と LLVM harness の差分(未対応の場合の方針)
    • 分類: (A) 仕様通り / (B) 未実装 / (C) 既知バグ / (D) 仕様外(禁止)

追加ルール(運用):

  • 新しい環境変数トグルは増やさない(既存の診断導線の範囲で)
  • 未対応は隠さず、smoke で理由付き SKIP として固定するsilent fallback 禁止)

3. 次P1/P2への導線箇条書きでOK

  • P1investigation: 棚卸し対象のファイル一覧と観測ポイント
  • P2smoke: fixture の仕様stdout/exitと LLVM 側の扱いPASS/SKIP

4. P1 調査チェックリスト(提案)

Rust VMSSOT

  • src/value.rs
    • NyashValue::WeakBox の生成箇所weak をどう作るか)
    • weak_to_strong() 失敗時の観測方法(文字列化/判定API
    • unit test: test_weak_reference_drop の仕様(何を固定しているか)
  • src/finalization.rs
    • finalizer の存在(あれば: 登録、呼び出しタイミング、順序)
    • 禁止事項(再入/例外/I/O/allocをどこでガードするか
  • src/box_trait.rs / src/scope_tracker.rs
    • Box の所有モデルArc/Weakの境界、roots の形成点)

LLVM harness差分を SSOT 化)

  • src/llvm_py/
    • weakref/finalizer の相当機能があるか(まず “無いなら無い” を明文化)
    • 未対応の場合は smoke を SKIP にし、理由をログで固定する方針