NativeAOT questions

[tmds]

I've been reading through the NativeAOT and trimming docs, and I have some questions.

Some code:

using System.Diagnostics.CodeAnalysis;

EnsureCreatable<Foo<int>>(); // 1
object o = CreateFor<int>();
Use(o);

void EnsureCreatable<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>()
{ /* empty */}

object CreateFor<T>()
{
     var type = typeof(Foo<>).MakeGenericType(new[] { typeof(T) });
     return Activator.CreateInstance(type)!; // 2
}

void Use(object o)
{
    (o as IBar)!.Baz(); // 3
}

interface IBar
{
    void Baz();
}

class Foo<T> : IBar
{
    public void Baz()
    {
        Console.WriteLine("Called");
    }
}

If the call to the empty method at //1 is reachable, then the type can be instantiated anywhere (like is done here at //2)?

If anywhere in the app there is a reachable user of an interface member (like //3) then the implementation of that member is preserved on all types that implement it?

cc @MichalStrehovsky @eerhardt

[eerhardt]

If the call to the empty method at //1 is reachable, then the type can be instantiated anywhere (like is done here at //2)?

The type can be instantiated, yes. But there is no strong guarantee. You will still get AOT warnings in the CreateFor<T> method. The tools can't statically guarantee it will work.

If anywhere in the app there is a reachable user of an interface member (like //3) then the implementation of that member is preserved on all types that implement it?

The implementation of that member is preserved on all instantiable types that implement it. If a type implements that interface, but nothing creates that type, the type can be trimmed.

[tmds]

The type can be instantiated, yes. But there is no strong guarantee. You will still get AOT warnings in the CreateFor method. The tools can't statically guarantee it will work.

By there is no strong guarantee you mean: the tooling can't guarantee that I did not forget to call EnsureCreatable before calling CreateFor? You don't mean that: the native aot app for this code potentially won't work?

My question is mostly to check that the DynamicallyAccessedMemberTypes get applied independent of what is in the method. Is that right?

preserved on all instantiable types that implement it

For the above example code, what causes Foo<int> to be considered an instantiable type?
I assume it is // 1? And // 2 does not cause it to be considered instantiatable because the linker doesn't know the type is Foo<int>?

[eerhardt]

By there is no strong guarantee you mean: the tooling can't guarantee that I did not forget to call EnsureCreatable before calling CreateFor?

Correct. The tooling can't guarantee that you ensured the ctor was preserved elsewhere (or that the closed generic type Foo<int> was created), so it will issue a warning.

My question is mostly to check that the DynamicallyAccessedMemberTypes get applied independent of what is in the method. Is that right?

Yes, that is my understanding. If the tooling sees you call a method with DynamicallyAccessedMembers and passing in a Type, it will preserve those members on that Type, no matter what the method body does.

For the above example code, what causes Foo to be considered an instantiable type?

Passing <Foo<int> into EnsureCreatable<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T> tells the tooling that someone may call the ctor on Foo<int>, making it instantiable.

[tmds]

Thanks! That all makes sense.

I have a few more questions to check my understanding of the trimming analysis.

void Foo(Type t)
{
    var method = t.GetMethod("Bar");
    method.Invoke(...);
}

This doesn't cause all methods Bar to be kept?
Also calling this as Foo(typeof(Baz)) won't exclude Baz.Bar from trimming?
And, the same if it is a generic parameter (Foo<Baz>()) would also not exclude it from trimming?

Whereas:

MethodInfo Foo()
{
    return typeof(Baz).GetMethod("Bar");
}

In this case, the member Foo.Bar won't get trimmed?

[vitek-karas]

The first sample should produce a warning. The trimmer will not keep all "Bar" methods on all types (design choice).

The second sample should not produce a warning and Baz.Bar will be kept (all overloads if there are more than one, as we don't try to fully emulate runtime reflection semantics).

All of what you write is true. You could fix the first sample by adding [DynamicallyAccessedMembers(PublicMethods)] to the Type t parameter. In that case calling Foo(typeof(Baz)) would keep all public methods on Baz.

[MichalStrehovsky]

For the EnsureCreatable pattern, the recommendation is to actually use it for something.

void EnsureCreatable<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>()
{
    _myCache[typeof(T)] = typeof(T).GetConstructor([]);
}

object CreateFor<T>()
{
     _myCache[typeof(Foo<T>)].Invoke([]);
}

This way trimming can fully analyze the code. There are no warnings (CreateFor in the top post would generate at least two warnings) and the code works exactly the same between trimmed and untrimmed app (i.e. if one forgets to call EnsureCreatable, the CreateFor will fail both with trimming and without trimming).

[tmds]

This way trimming can fully analyze the code. There are no warnings (CreateFor in the top post would generate at least two warnings) and the code works exactly the same between trimmed and untrimmed app (i.e. if one forgets to call EnsureCreatable, the CreateFor will fail both with trimming and without trimming).

I understand, and that makes sense.

My questions are to understand better how the trimming/nativeaot analysis works and the code examples are somewhat "artificial" make the questions more concrete.

I tried a variation: EnsureCreatable to EnsureFooable.

void EnsureFooable<T>()
{
    EnsureCreatable<Foo<T>>();
}

void EnsureFooable2<T>()
{
    _ = new Foo<T>();
}

As expected based on the previous discussions: EnsureFooable2 works, and EnsureFooable does not.

I don't think there's a way to express this, other than new-ing up the type?

[MichalStrehovsky]

Yes, the analysis needs to see something as used by reflection. Passing something into a location annotated with DynamicallyAccessMembers counts as "used by reflection" for the analysis purposes, and so does literal use of reflection (e.g. typeof(Foo).GetProperties()).

[tmds]

@MichalStrehovsky @eerhardt

I have another question. This one is about the 'viral' nature of the DynamicallyAccessedMembers attribute.
When I follow the compiler warnings, I'm propagating it outwards. Though, I think I can ignore them at some level.

The following example gives warnings for the generic parameters of the Struct type.
I assume in this case (based on the answers to my earlier questions) it is probably safe to suppress them?

using System.Diagnostics.CodeAnalysis;

Reader reader = new();
var value = reader.Read<Struct<string, Struct<int, string>>>();
Console.WriteLine(value.Item1);
Console.WriteLine(value.Item2.Item1);
Console.WriteLine(value.Item2.Item2);

ref struct Reader
{
    public int ReadInt() => 42;
    public string ReadString() => "foo";

    public T Read<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>()
    {
        Type type = typeof(T);

        if (type == typeof(string))
        {
            return (T)(object)ReadString();
        }
        else if (type == typeof(int))
        {
            return (T)(object)ReadInt();
        }
        else if (type.IsAssignableTo(typeof(IReadable)))
        {
            var readable = (Activator.CreateInstance<T>() as IReadable)!;
            readable.ReadFrom(ref this);
            return (T)readable;
        }

        ThrowNotSupportedType(type);
        return default;
    }

    private static void ThrowNotSupportedType(Type type)
        => throw new NotSupportedException($"Cannot read type {type.FullName}");
}

struct Struct<T1, T2> : IReadable
{
    public T1 Item1;
    public T2 Item2;

    void IReadable.ReadFrom(ref Reader reader)
    {
        Item1 = reader.Read<T1>();
        Item2 = reader.Read<T2>();
    }
}

interface IReadable
{
    void ReadFrom(ref Reader reader);
}

[vitek-karas]

using System.Diagnostics.CodeAnalysis;

Reader reader = new();
var value = reader.Read<Struct<MyValue, Struct<int, string>>>();

// ...
//  Same as yours
// ...

class MyValue : IReadable
{
    public MyValue()
    {
        Console.WriteLine("Creating MyValue");
    }

    public void ReadFrom(ref Reader reader)
    {
        Console.WriteLine("Reading MyValue");
    }
}

Modified like this - then dotnet publish /p:PublishTrimmed=true and then run will produce:

Unhandled exception. System.MissingMethodException: Cannot dynamically create an instance of type 'MyValue'. Reason: No parameterless constructor defined.

In this case NativeAOT works, because of its generics analysis, but it's not guaranteed and more complex example is likely to break as well.

General guidance is: "Don't suppress trim/AOT analysis warnings". It's almost always wrong.

And to answer your question: Yes, the DynamicallyAccessedMembers annotations are "viral" in the sense that they need to be propagated to callers. This propagation stops only when the caller provides a statically known type.

In your example, you could replace the DAM with basically equivalent new constraint:

    public T Read<T>() where T : new()
    {
        // ....
        else if (type.IsAssignableTo(typeof(IReadable)))
        {
            var readable = (new T() as IReadable)!;
            // ....
        }
    }

In which case the code won't even compile, because of the mismatch of constraints between Reader.Read and Struct. But semantically the two are almost identical - in fact the trimming tools consider new() constraint equivalent to DynamicallyAccessedMembers(PublicParameterlessConstructor).

The new() constraint is also similarly "viral" and propagates to callers.

[tmds]

In this case NativeAOT works, because of its generics analysis

If I understand correctly, the example worked because it was using a struct, which required generating these methods fully at compile time. And that is no longer the case when you changed it to a class.

Yes, the DynamicallyAccessedMembers annotations are "viral" in the sense that they need to be propagated to callers. This propagation stops only when the caller provides a statically known type.

Understood.

you could replace the DAM with basically equivalent new constraint:

I had tried this at one point, but it didn't work. The new constraint requires the public constructor to exist, while the DAM preserves it when it exists. It doesn't work for this code because string doesn't have a parameterless public constructor.

[vitek-karas]

If I understand correctly, the example worked because it was using a struct, which required generating these methods fully at compile time. And that is no longer the case when you changed it to a class.

I think in NativeAOT this would work regardless of struct/class because of generic expansion the compiler does. But it's not guaranteed to work in all cases.
It doesn't work in the trimmer, because trimmer doesn't perform generic expansion of method bodies (it has no immediate need to do that).
That's why the warnings are generated - we want the tools to have some freedom to decide how to implement certain things and allow us to evolve them in the future.

You're right that the new constraint doesn't work in this case because of string (honestly this was a surprise for me :-)) - so you would have to use DAM here instead.

[tmds]

@vitek-karas @eerhardt @MichalStrehovsky thanks for all your answers to my questions!

I'm going to mark the first "Mark as answer" to close the workflow on this discussion.