dotnet/roslyn

Nullability warning is missing on the lock statement

Open

#76,597 opened on 2025年1月2日

GitHub で見る
 (1 comment) (0 reactions) (0 assignees)C# (4,257 forks)batch import
Area-CompilersFeature - Nullable Reference Typeshelp wanted

Repository metrics

Stars
 (20,414 stars)
PR merge metrics
 (平均マージ 6d 17h) (30d で 256 merged PRs)

説明

Version Used: 17.13.0 Preview 2.1

There is no nullability warning for lock (null) { } or lock (maybeNullExpr) { }, even though a null at runtime throws ArgumentNullException.

Expected

A nullability warning such as:

  • CS8604 - Possible null reference argument for parameter.

    • More literal, similar to how await or foreach simply reflect the warning you'd get if you had manually called GetAwaiter()/GetEnumerator().

  • CS8602 - Dereference of a possibly null reference.

    • A step back, if calling expr in lock (expr) a "parameter" is leaking too much information about how lock is being lowered.

Or, one in the same vein as "CS8597 Thrown value may be null."

コントリビューターガイド

調査方針
Roslynコンパイラのソースコードでlock文の低レベル化を調べてください。具体的には、BoundLockStatementノードとそれがどのように低レベル操作に変換されるかを確認します。次に、nullableフロー分析を調べて、lock式に対してnull警告が発行されない理由を理解します。'await'や'using'のような類似構造に対する既存のnullable警告ロジックを確認してください。
技術スタック
csharp
領域
developer experience
Issue 種別
バグ
難度新しい貢献者にとっての実装難度です。1 は非常に小さな変更、5 は専門的な作業です。
2
推定時間経験ある貢献者が調査、実装、テスト、pull request 準備にかけるおおよその時間範囲です。
1-3時間
活動状況Issue が今どれだけ取り組みやすいかを示します。新しい、活発、古い、ブロック中、またはメンテナー入力待ちなどです。
アクティブ
明確さ期待される変更、受け入れ条件、次の手順がどれだけ明確かを示します。
明確
前提条件
GitC# compiler basics
初心者向け度初回貢献者にどれだけ取り組みやすいかを 1-100 で推定したスコアです。
50