/azp run runtime-extra-platforms

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

I think I don't understand SwiftIndirectResult and non-frozen structs. Looking at the sample:

 private struct NonFrozenStruct
    {
        public int A;
        public int B;
        public int C;
    }

    [UnmanagedCallConv(CallConvs = new Type[] { typeof(CallConvSwift) })]
    [DllImport(SwiftLib, EntryPoint = "$s19SwiftIndirectResult21ReturnNonFrozenStruct1a1b1cAA0efG0Vs5Int32V_A2ItF")]
    public static extern void ReturnNonFrozenStruct(SwiftIndirectResult result, int a, int b, int c);

 [Fact]
    public static void TestReturnNonFrozenStruct()
    {
        // In normal circumstances this instance would have unknown/dynamically determined size.
        NonFrozenStruct instance;
        ReturnNonFrozenStruct(new SwiftIndirectResult(&instance), 10, 20, 30);
        Assert.Equal(10, instance.A);
        Assert.Equal(20, instance.B);
        Assert.Equal(30, instance.C);
    }

How does Swift know that the caller allocated a large enough buffer so the callee can rely on being able to write into it?

My understanding of non-frozen Swift types is that they allow you to link two different versions of NonFrozenStruct where one of them can have more members than the other?

How does Swift know that the caller allocated a large enough buffer so the callee can rely on being able to write into it?

There is metadata created and exported by the callee module that, among other things, includes the size of the non-frozen struct. The caller is supposed to allocate a buffer of that size. I didn't do that in the test.

@kotlarmilos's original issue has some (pseudo-)code that is more faithful to what the interop generator would end up with: #102082