Minor warning with ReadIntoArray in NativeAOT build

[theoractice]

When building with NativeAOT every warning should be treated carefully, so this is what I asked Copilot:

Function
    public static void ReadIntoArray<T>(this nint pointer, T[] destination, int count) where T : struct
    {
        if (destination.Length < count)
        {
            throw new ArgumentException("Destination array is not large enough to hold the requested number of items.", nameof(destination));
        }

        if (count == 0) return;

        var elementSize = Marshal.SizeOf<T>();
        for (var i = 0; i < count; i++)
        {
            var currentPtr = (nint)(pointer + (long)i * elementSize);
            destination[i] = Marshal.PtrToStructure<T>(currentPtr);
        }
    }
showed warning on this line when building nativeaot:
            destination[i] = Marshal.PtrToStructure<T>(currentPtr);
warning message:
SoundFlow\Src\Utils\Extensions.cs(63,0): Warning IL2091: SoundFlow.Utils.Extensions.ReadIntoArray<T>(IntPtr,T[],Int32): 'T' generic argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicConstructors', 'DynamicallyAccessedMemberTypes.NonPublicConstructors' in 'System.Runtime.InteropServices.Marshal.PtrToStructure<T>(IntPtr)'. The generic parameter 'T' of 'SoundFlow.Utils.Extensions.ReadIntoArray<T>(IntPtr,T[],Int32)' 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.

Copilot says:

You’re hitting the NativeAOT/trimming analyzer rule because Marshal.PtrToStructure requires constructors on T to be preserved, and your generic method doesn’t propagate those requirements. You have two solid options:

Option A — Keep PtrToStructure (works for non-blittable structs)

• Add DynamicallyAccessedMembers to the generic type parameter so the trimmer preserves constructors required by PtrToStructure.
• This matches the requirement of PtrToStructure and removes IL2091.
• Note: This requirement will flow to callers of this method; if they are also generic they may need matching annotations.

Example:

using System;
using System.Diagnostics.CodeAnalysis;
using System.Runtime.InteropServices;

public static class Extensions
{
    public static void ReadIntoArray<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors | DynamicallyAccessedMemberTypes.NonPublicConstructors)] T>(this nint pointer, T[] destination, int count) where T : struct
    {
        if (destination.Length < count)
        {
            throw new ArgumentException("Destination array is not large enough to hold the requested number of items.", nameof(destination));
        }

        if (count == 0)
        {
            return;
        }

        var elementSize = Marshal.SizeOf<T>();
        for (var i = 0; i < count; i++)
        {
            var currentPtr = (nint)(pointer + (long)i * elementSize);
            destination[i] = Marshal.PtrToStructure<T>(currentPtr);
        }
    }
}

Option B — Prefer AOT-friendly, fast copy for blittable types

• If T is blittable (no references; pure unmanaged layout), avoid Marshal.PtrToStructure entirely and copy with spans. This is faster and AOT/trimming-safe.
• Constrain T : unmanaged and use the pointer-based ReadOnlySpan constructor.

Example:

using System;

public static class Extensions
{
    public static unsafe void ReadIntoArray<T>(this nint pointer, T[] destination, int count) where T : unmanaged
    {
        if (destination.Length < count)
        {
            throw new ArgumentException("Destination array is not large enough to hold the requested number of items.", nameof(destination));
        }

        if (count == 0)
        {
            return;
        }

        var src = new ReadOnlySpan<T>((void*)pointer, count);
        src.CopyTo(destination.AsSpan(0, count));
    }
}

Which should I pick?

• If your T can be non-blittable (e.g., has fields that require marshalling), use Option A.
• If your T is always blittable (common for POD structs used for interop), use Option B for performance and zero warnings in NativeAOT.

Hope it helps to mitigate this warning message.

[LSXPrime]

Thanks for reporting this! For future reports, I suggest using the "Issues" section instead, as I don't receive email notifications for discussions.

The good news is v1.3.0 was released yesterday, and it fixes this issue!

However, there are some important notes about NativeAOT that you should know—I've posted all the details in the "Release Announcement".