Roslyn fails to correctly infer nullability of foreach variables' types if deconstruction is used

[TessenR]

Version Used:

Branch main (4 Sep 2021)
Latest commit 9525fa5 by Tomáš Matoušek:
Options refactoring (#55686)

Steps to Reproduce:

Compile and run the following code

#nullable enable
class C<T>
{
  public T field;
  
  public C(T t) => field = t;
}

class Program
{
  public static void Main()
  {
    var x = M1("");
    x.field.ToString();
  }
    
  static C<string> M1(string? s)
  {
    var c = Infer(s);
    foreach (var (x, _) in new[] { (c, c) })
    {
      x.ToString();
      x.field.ToString();
      
      var z = x;
      z.field.ToString();
      z.field = null;
      return z;
    }

    return new("");
  }
  
  public static C<T> Infer<T>(T t) => new(t);
}

Expected Behavior:
Possible null dereference warning for x.field.ToString() in M1
Nullability of reference types in value of type 'C<string?>' doesn't match target type 'C<string>' warning for return z in M1

Actual Behavior:
No warnings at all in the program above.
It crashes with a NullReferenceException if you run it due to the missing warning for x.field.ToString();
If you comment the x.field.ToString() line in M1 it crashes at x.field.ToString() in Main due to the missing warning on return z

Notes:
It looks like Roslyn fails to infer any nullability of type arguments at all for all variables in M1 so it allows both dereferencing .field and assigning it with null values without any warnings as if it thinks their type arguments have unknown nullability.

Interestingly, you'll correctly get both warnings if you change the cycle to not use deconstruction i.e. change the foreach cycle header to the following:

    foreach (var x in new[] { c })

[RikkiGibson]

Is it possible that this issue is fixed by #52722?

[TessenR]

@RikkiGibson It looks quite similar and it might indeed also solve this issue. However, it looks like all tests and fixed issues in #52722 mention only top-level nullability whereas this issue has a problem with nullability of type arguments of foreach variables. I'd suggest adding tests to verify whether the changes in #52722 are enough to fix this as well.