Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[P2] Tests: lazy class storage test expects erased declare fields at runtime

オープン 初心者向け
#2,829 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@nickna がすでに取り組んでいます。

2026年10月22日 から。

  • #2897 @nickna による — オープン

評価

難易度
1/5
見積もり時間
1〜3時間
初心者へのやさしさ
84/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
csharp, typescript
領域
compilers, testing

調査の方向性

LazyClassFieldStorageTests.GenericDeclareAndComputedInitializers_MaterializeAndVerifyを見つけ、提供されたTypeScriptソースと併せて期待出力を確認してください。不一致を確認するためにテストを実行してください。Nodeの結果に一致するよう期待出力のみを更新し、ソースと完全なIL検証アサーションを保持すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

bug priority: P2

The existing compiler test LazyClassFieldStorageTests.GenericDeclareAndComputedInitializers_MaterializeAndVerify expects a declare field to exist on the emitted instance and contain null.

Its unchanged source is:

const key: string = "computed";
class Box<T> {
    value: T;
    declare absent: any;
    [key]: number = 2;
    constructor(value: T) { this.value = value; }
}
const box: any = new Box<number>(3);
console.log(box.value, box.absent, box.computed,
    Object.hasOwn(box, "absent"), Object.hasOwn(box, "computed"));

Strict TypeScript accepts this source. Node prints:

3 undefined 2 false true

The test still expects:

3 null 2 true true

A declare field is erased, so the Node result is the intended runtime behavior. Both the tested compiler parent and the candidate for #2737 produce the correct result after complete IL verification with only System assembly references. The assertion therefore fails on both; this is a stale test oracle, not a runtime regression from #2737.

Update the expected output while preserving the complete source and the existing IL-verification assertion. Found while expanding #2737 validation. The original test was added with the lazy-storage work associated with #1459.

主要言語
C#
スター
156
フォーク
4
平均マージ
4時間 52分
マージ済み PR(30日)
45

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

nickna/SharpTS のほかの issue

nickna/SharpTS の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。