IDE0370 false positive, when initializing auto-property with `null!`.

[PetSerAl]

Version Used:
Locally: SDK 10.0.101
lab.razor.fyi: 5.0.0 and 5.3.0-2.25619.2

Steps to Reproduce:

class C
{
    public C() { }
    public string S { get; set; } = null!; //IDE0370: Suppression is unnecessary 
}

https://lab.razor.fyi/#42pi5OIKKMpPL0rM1UsuFipJzkksLlZw5uWq5uVSUFBQKChNyslMVnDW0FSoVqhFESsuKcrMS1cIVqhWSE8tsVYoBhG1CrYKeaU5OYrWCvr6ni6uBsbmBlYKwaUFBUWpxcWZ-XkKmcUKpXl5qcmpxcWJRZUKvFy1XmypRUX5RcVRnBxvfpw5-SFNgCWBsYIRAA

20260103-1611-05.8100910.mp4

IDE0370 on ! sign.

Diagnostic Id:
IDE0370: Suppression is unnecessary

Expected Behavior:
No diagnostic should be produced, as null assigned to not nullable property.

Actual Behavior:
False positive IDE0370. When proposed fix applied, it result in "CS8625: Cannot convert null literal to non-nullable reference type." warning.
No diagnostic, if constructor removed/commented.

[CyrusNajmabadi]

Something weird is happening here. We call:

            var updatedDiagnostics = updatedSemanticModel.GetDiagnostics(groupSpan, cancellationToken);

With the span of the property. And we get nothing back. But if i call GetDiagnostics on the full semantic model, then it returns that diagnostic within that span.

[CyrusNajmabadi]

Only repros if you have:

    public C() { }

[CyrusNajmabadi]

Seems to be an issue with GetDiagnostics when passed a span. Created repro and have pulled in compiler dev to see if we can figure out waht's up.

[CyrusNajmabadi]

ok. Have verified that hte compiler doesn' tproperly return warnings whne asking for diagnostics for the span for, say, a full property declaration.

It also does not return anything here even if you first ask for diagnostics for a constructor in the type. if you do ask for diagnostics for the type-declaratio span itself, these will show up. But that's not super desirable given that a type declaration may be super large itself.

ideally, from talking to @RikkiGibson , the compiler should see that the span is within a property decl and do the appropriate binding of constructors to make nullable warnings show up.

--

If, however, we can't get the GetDiagnostics side fixed, a poor-man's solution here is to update the analyzer to instead bind the entire type declaration, then filter the diagnostics to those that intersect the field/property.

[RikkiGibson]

This is a compiler bug. I can hopefully get to this next week. It looks like Cyrus has a workaround, and, the gap may be more expansive than we realized at first blush. So, it may be somewhat longer before we are able to get a real fix in on the compiler side.

The path in MethodCompiler.CompileNamedType, which simply binds the field initializers, doesn't actually produce the nullable diagnostics for the field initializers.

Instead, nullable analysis of field initializers is delayed until we encounter a constructor which needs to use the "after initializers" state as the constructor's initial state:

roslyn/src/Compilers/CSharp/Portable/Compiler/MethodCompiler.cs

Line 2115 in a291525

NullableWalker.VariableState? getInitializerState(BoundNode? body)

Whether the nullable warnings are reported or not for a given span, ends up depending on whether the constructor's span intersects with the filterSpan being passed in. I think when the constructor is implicitly declared, then the whole type span is used, which intersects with the filterSpan in this scenario. So we visit that constructor and therefore nullable analyze the field initializers. When the constructor is explicitly declared, the spans don't intersect, so we don't do that nullable analysis.

I believe the fix here is to simply do the nullable analysis of the field initializers, in the same path which binds the field initializers, and store the "after initializers" nullable state on the Binder.ProcessedFieldInitializers to use in constructors when we need it.

[CyrusNajmabadi]

Reactivating so we track a real fix in the compiler. @RikkiGibson if you end up fixing this, consider rolling back #81899 as it should not be necessary.