See if we can optimize blocks under null checks

[MichalStrehovsky]

In the below program we should know that something typed as ITestOutput won't ever be non-null. We should be able to optimize out the null check branch in Foo.

using System;
using System.Runtime.CompilerServices;

class Program
{
    [MethodImpl(MethodImplOptions.NoInlining)]
    static void Foo(ITestOutput? to = null)
    {
        to?.Log("hello");
    }

    static void Main() => Foo(null);
}

interface ITestOutput
{
    void Log(string s);
}

Cc @nagya @jevansaks @EgorBo

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[EgorBo]

@MichalStrehovsky hm.. how do we check that? I see we have

if (info.compCompHnd->getExactClasses(cls, 0, nullptr) == 0)

to check if a type can exist, but it returns -1 for this case, because the interface itself exists, just has no implementators

[MichalStrehovsky]

@MichalStrehovsky hm.. how do we check that? I see we have

Yeah, in the top-post repro case the interface method call brings the interface type to life. We have some conservative assumptions within the whole program view due to IDynamicInterfaceCastable. I'm looking if I can narrow those assumptions down somehow. What should give you 0 instead of -1 today is:

    [MethodImpl(MethodImplOptions.NoInlining)]
    static void Foo(ITestOutput? to = null)
    {
        if (to != null)
            Console.WriteLine("I'm unreachable");
    }

(i.e. do not call any methods on the interface, do not cast anything to the interface.)