Type inference should be able to infer U? for T when T? (and inference differs when a discard is used)

[MrJul]

Version Used:
VisualStudio.16.Release/16.8.4+30907.101
C# Tools 3.8.0-5.20604.10+9ed4b774d20940880de8df1ca8b07508aa01c8cd

Steps to Reproduce:
<LangVersion>9</LangVersion>

using System.Diagnostics.CodeAnalysis;

#nullable enable

interface IOperation<T> { }
class StringOperation : IOperation<string?> { }

class C {   
    void M() {
        TestA(new StringOperation(), out string? discard1); // 1: no warning
        TestA(new StringOperation(), out string? _);        // 2: CS8620
        TestA(new StringOperation(), out _);                // 3: CS8620
        
        TestB(new StringOperation(), out string? discard2); // 4: CS8620
        TestB(new StringOperation(), out string? _);        // 5: CS8620
        TestB(new StringOperation(), out _);                // 6: CS8620
    }

    void TestA<T>(IOperation<T> operation, [MaybeNull] out T result) => result = default;
    void TestB<T>(IOperation<T> operation, out T? result) => result = default;
}

Expected Behavior:

• Ideally, no warnings at all, I would expect the compiler to see that T?/[MaybeNull] T can be matched by string? (in effect making it string??) without warnings. Currently T is always inferred to be string instead of string?, resulting in warnings.
• At the very least, 1 and 2 should have same behavior: the specified types are the same, only the parameter name is missing in 2.

Actual Behavior:
Warnings everywhere but on 1.

[jaredpar]

At the very least, 1 and 2 should have same behavior: the specified types are the same, only the parameter name is missing in 2.

Agree. Interested to see what the bug appears to be here, that's very strange.

[TomatorCZ]

Hi, I will try to investigate the issue as an opportunity to get familiar with the platform. @RikkiGibson

[TomatorCZ]

Hi!

I made a little investigation of the issue. I managed to figure out why there is the different behaviour. See PR.

During the investigation, I noticed an additional strange behaviour in several parts of the code. I think that this causes a warning in case of the discard delegate out _ . IMO this should be without the warning because the compiler should determine that _ is a type of string or string?, since there is no user defined type or annotation.

So, the first weird thing is during resolving actual type parameter here. This code is called every time when there are candidates for the type parameter. You can see, we ignore nullability information here whenever the conversions don't include nullability. This looks fine, but the conversions never includes nullability(I tried to debug the example. The first and the second phase of inferring contains conversions without nullability resolving in the type parameter never being sth?).

The second weird thing is the type of parameter argument out _. After the first phase, the parameter types are resolved based on type parameters of generic method. In case of out _, the execution continues here, where we lose information about inferred nullability. It results in the second phase, where the parameter looks like this out string _ instead of this out string? _.

The third thing is ignoring TypeAnnotations of discard expressions here. The compiler ignores user defined ? which is a mistake IMO.

[RikkiGibson]

I think the issue is resolved by #66309. Thanks for reporting it @MrJul!