scriptc

既知のコンパイラバグ (v0.3.0、issue #963)。ジェネリッククラスのインスタンスに対して、リテラルでないキーを用いた (obj as any)[key] = fn のような計算キーによる書き込みがどこかに存在すると、メソッド名の集計処理がそのクラスのメソッドを prototypeMethodAccesses に降格させてしまう。その結果、ローワリング後のコードは dyn.hasKey ガードなしでインスタンスごとの動的プロパティバッグを読み取り、かつ classPrototypeData はジェネリッククラス/ジェネリックインスタンスクラスに対して null を返すため、プロトタイプへのフォールバックが存在しない。バッグの読み取りは undefined を返し、呼び出しが例外をスローする。非ジェネリッククラスはプロトタイプデータヘルパーが生成されるため影響を受けない。

コンパイラの修正が取り込まれるまでの回避策:
1. ジェネリッククラスのインスタンスへの動的キーによる書き込みを排除する — 外部メタデータは別の Map/サイドテーブルに保存するか、obj[expr] = value の代わりにリテラルなプロパティ代入を使用する。
2. 可能であれば、型パラメータを削除し (Ctx<T> の代わりに具体的な型を使用する)、クラスが非ジェネリックパスでコンパイルされるようにする。このパスではプロトタイプデータヘルパーが構築され、メソッドが正しく解決される。

検討中のコンパイラ側の修正方針: ジェネリックインスタンスに対してプロトタイプデータを生成してバッグ読み取りにフォールバックを持たせるか、ジェネリッククラスのメソッドについて dyn.hasKey ガードを維持して読み取りが静的メソッドにフォールバックするようにするか。

SC1090 は、コンパイラがレシーバーのランタイムクラスを静的に証明できないことを意味します。ジェネリックメソッドは静的にディスパッチされるため、この証明が必要です。これは、オブジェクトが any を通過した後にインターフェースへキャストし直される場合に発生します（例：const restored = erased as GenericIdentity; restored.id(42)）。このパターンはまだサポートされていません（機能リクエスト #905）。回避策：(1) オブジェクトが any に消去される前に、元の型付きオブジェクト上でジェネリックメソッドを直接呼び出してください。元のオブジェクトを介した直接呼び出しはサポートされています。(2) クラスインスタンスの場合は、クラスを証明可能にするため、レシーバーをその new 式で初期化した const にバインドしてください：const r: GenericIdentity = new C(...)。注意：any や型消去されたストレージを経由して往復しなければならない、オブジェクトリテラル上のジェネリックなアロー関数プロパティについては、現時点では回避策がありません。