Missing nullability warnings about member initialization in constructors in structs with default struct ctor calls

[TessenR]

Version Used:

Branch master (13 Oct 2020)
Latest commit 941dc7e by Shimmy:
Default constructor suggestion between members (#48318) (#48503)

Steps to Reproduce:

Compile and run the following code

#nullable enable

new S(1);

struct S
{
  string f;
  public S(long x) : this() => f.ToString();
}

Expected Behavior:
warning CS8602: Dereference of a possibly null reference. for f.ToString()

Actual Behavior:
No nullability warnings. The code crashes at runtime with a NullReferenceException

Notes
Roslyn seems to think that : this() constructor call in struct correctly initializes all struct fields which it doesn't. Roslyn should just ignore default stuct constructor calls when enforcing nullability contract of a constructor.

[Youssef1313]

Similar issues around the same area were discussed before. This is by design. These known pitfalls are being documented in dotnet/docs#21063. See the comments in #48546

[TessenR]

This doesn't seem particularly similar to me.
There's a lot of potentially problematic areas for enforcing nullability rules e.g. nested fields aren't verified through method boundaries (example with return new ValueTask<string>();) and array initialization can't be easily verified.

This seems different as Roslyn already tracks nullability of members in constructors and already has special handling of new Struct() in lots of places across nullability analysis. So supporting this is as easy as ignoring the default struct constructor : this() call in structs whereas the issues linked above require adding new verifications and probably introducing new warnings and still won't solve the problem e.g. because I can always create a default struct with

return GetDefault<ValueTask<string>>();
T GetDefault<T>() where T: new() => new T();

/cc @RikkiGibson

[RikkiGibson]

From https://github.com/dotnet/csharplang/blob/master/proposals/nullable-constructor-analysis.md

A constructor on a value type with a : this() initializer referencing the default value type constructor has an initial flow state given by initializing all applicable members to the state given by assigning a default literal to the member.

It sounds like we failed to do this. Would be happy to address when I get the chance or review a PR that fixes this.

[RikkiGibson]

It looks like we specifically messed this up for fields. The following example gives the expected warning (as well as an exit warning, if we never warn about a bad receiver and update the state to not-null.)

#nullable enable

new S(1);

struct S
{
  string f { get; set; }
  public S(long x) : this() => f.ToString(); // Dereference of a possible null reference.
}