CS8602 false positive due to inferred generic type argument being nullable

[AArnott]

Version Used: 16.6 Preview 1.0 (29813.275.master)

Steps to Reproduce:

Create a C# project with this content:

using System;

#nullable enable

public class VSTHRD109AvoidAssertInAsyncMethodsCodeFix
{
    public void ApplyChangeOptimistically()
    {
        var n = new GenericParameterHelper(1);
        ApplyChangeOptimistically(ref n, i => new GenericParameterHelper(i.Data + 1));
        int x = n.Data;
    }

    public static bool ApplyChangeOptimistically<T>(ref T hotLocation, Func<T, T> applyChange)
        where T : class?
    {
        return false;
    }
}

public class GenericParameterHelper
{
    public GenericParameterHelper(int data)
    {
        this.Data = data;
    }

    public int Data { get; set; }
}

Expected Behavior:

No warnings.

Actual Behavior:

Two CS8602 warnings where the Data property is consumed.

This is evidently because the inferred generic type argument is nullable:

If I explicitly specify the generic type argument as GenericParameterHelper, the compiler warnings go away. But why would C# think that GenericParameterHelper? was the generic type argument? Nothing was nullable anywhere. The n local variable is typed as GenericParameterHelper -- not GenericParameterHelper?.

[jcouv]

I agree that method type inference (inferring ApplyChangeOptimistically<GenericParameterHelper?>(...)) is the root cause of those warnings.

I think that inference is happening because of the var (which is inferred as GenericParameterHelper? as of 16.6p1). If you change to declaration of n to use an explicit type, the warnings goes away.

[AArnott]

Yes, I came to the same conclusion and verified that result as mentioned in the issue description.

But why would var's inferred type be nullable when the assigned value is decidedly not null? Isn't that a bug?

[jcouv]

As of 16.6p1, we're inferring a nullable type for var wherever possible: https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-12-18.md#var

[AArnott]

I see. Well, the nullable flow analysis doesn't address the 'regression' this makes for generic type arguments I guess. Is it worth reconsidering the design decision?

[RikkiGibson]

Is this issue only present when using a ref to a var to infer a generic type argument?

[AArnott]

I'm not sure, @RikkiGibson

[CyrusNajmabadi]

As of 16.6p1, we're inferring a nullable type for var wherever possible:

jcouv. I agree that the type shoudl be inferred to be nullable (that way i could assign null to it later). but that doesn't mean the value when used in teh local function should be thought to be potentially null at that point. i.e. can't we have nullable locals that we know should not be null based on how they've been used?