Unnecessary trim analysis warnings from generics

[MichalStrehovsky]

Below program generates warnings from ILLink. There are no warnings from the analyzer or ILC. Feels like there should be no warnings.

I think we already discussed this in the past but couldn't find a bug. This pattern came up in a discussion with an internal customer.

    D:\ctor\Program.cs(8,5): Trim analysis warning IL2091: Program.<<Main>$>g__NullOrNillValue|0_0<T>(): 'T' generic argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicParameterlessConstructor' in 'Nilable<T>'. The generic parameter 'T' of 'Program.<<Main>$>g__NullOrNillValue|0_0<T>()' does not have matching annotations. The source value must declare at least the same requirements as those declared on the target location it is assigned to.
    D:\ctor\Program.cs(9,9): Trim analysis warning IL2091: Program.<<Main>$>g__NullOrNillValue|0_0<T>(): 'T' generic argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicParameterlessConstructor' in 'Nilable<T>'. The generic parameter 'T' of 'Program.<<Main>$>g__NullOrNillValue|0_0<T>()' does not have matching annotations. The source value must declare at least the same requirements as those declared on the target location it is assigned to.
    D:\ctor\Program.cs(3,1): Trim analysis warning IL2091: Program.<Main>$(String[]): 'T' generic argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicParameterlessConstructor' in 'Nilable<T>'. The generic parameter 'T' of 'Program.<<Main>$>g__NullOrNillValue|0_0<T>()' does not have matching annotations. The source value must declare at least the same requirements as those declared on the target location it is assigned to.

using System.Diagnostics.CodeAnalysis;

NullOrNillValue<Test>();

[return: MaybeNull]
static T NullOrNillValue<T>()
{
    if (default(T) is Nilable<T> nilable)
        return nilable.CreateNil();
    else
        return default;
}

public interface Nilable<
  [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]
T
>
{
    sealed T CreateNil() => Activator.CreateInstance<T>();
    bool FNil();
}

struct Test : Nilable<Test>
{
    public Test() => Console.WriteLine("Hello");

    public bool FNil() => false;
}

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/illink
See info in area-owners.md if you want to be subscribed.

[sbomer]

The ILLink behavior that warns on references to the type has the advantage of catching the following:

using System.Diagnostics.CodeAnalysis;

class RequiresHoleTest
{
    public static void Run()
    {
        Helper<C>();
    }

    static T Helper<T>()
    {
        return default(Requires<T>).Do(); // ILLink warns here
    }

    struct Requires<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)] T>
    {
        public T Do()
        {
            return Activator.CreateInstance<T>();
        }
    }

    class C { }
}

ILC doesn't warn on this. Are we ok with that hole? @MichalStrehovsky @agocke

[MichalStrehovsky]

ILC doesn't warn on this. Are we ok with that hole? @MichalStrehovsky @agocke

ILC does warn if we make Do a static method. There's likely some code somewhere that says we don't have to worry/check instance method calls, but we do for valuetypes. I extracted it into #117998.

[sbomer]

Thanks! In that case, what if the method is called through an interface?

using System.Diagnostics.CodeAnalysis;

class RequiresHoleInterfaceTest
{
    public static void Run()
    {
        Helper<C>();
    }

    static T Helper<T>()
    {
        if (default(Requires<T>) is I<T> i) // ILLink warns here
        {
            return i.Do(); // and here
        }
        return default;
    }

    interface I<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)] T>
    {
        T Do();
    }

    struct Requires<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)] T> : I<T>
    {
        public T Do()
        {
            return Activator.CreateInstance<T>();
        }
    }

    class C { }
}

ILC also doesn't warn on this.

[MichalStrehovsky]

Thanks! In that case, what if the method is called through an interface?

This one should have generated the warning in the box instruction. The warning on the interface call itself seems unnecessary since whatever can legitimately implement the interface should have been checked at the time the instance was allocated - it would be flagged there.