Ensure that BridgedTypeArray is indirectly returned

[hjyamauchi]

On Windows ARM64, how a struct value type is returned is sensitive to conditions including whether a user-defined constructor exists, etc. See

https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#return-values

That caused a calling convention mismatch between the non-USED_IN_CPP_SOURCE (Swift) side and the USE_IN_CPP_SOURCE (C++) side and a crash.

Add this constructor so that the calling convention matches.

This is a fix for the OnoneSimplification crash in

#74866 (comment)

and is a partial fix for

#74866 (comment)

[hjyamauchi]

@swift-ci please test

[DougGregor]

Excellent detective work tracking down this issue. I expect this is going to affect pretty much any C++ class type that we bridge over to Swift, so the risk of regressing here is fairly high. Can we think of any way to make sure that these types are handled uniformly, even if it's just fixing them all and documenting the pattern so we know what to do in the future (and why)?

[hjyamauchi]

Yeah, a very good point!

I'm curious why we need to use #ifdef USED_IN_CPP_SOURCE to hide certain types (the LLVM types?) from the Swift side (I just haven't understood that yet). I assume that there are good reasons for that but I wonder if there could be some alternative ways now that we know about this issue.

I also wonder if there is a way to statically force this constraint (struct is indirectly returned as value) using static_assert or something but I'm not sure if there are ways to express the constraint in C++ itself.

If there are no alternative solution, I'd at least vote for the low-tech approach of "just fixing them all and documenting the pattern so we know what to do in the future (and why)". If that requires a lot of manual editing, I'd be happy to help with that (or I may just end up doing that :)

[hjyamauchi]

@swift-ci please test macOS platform

[DougGregor]

Thank you! Please feel free to merge. Do we also need this for 6.0?

[hjyamauchi]

Thanks. Merged! Yes, I think 6.0 also needs this because SwiftCompilerSources is enabled on 6.0 for all OSes/CPUs including Windows ARM64. Unless the alternative seems better, I'd like to defer cherrypicking this to 6.0 until SwiftCompilerSources becomes fully functional (that is, #74866 is resolved)

[DougGregor]

I agree that it makes sense to defer cherry-picking until we have all of the changes needed to make it fully functional

[eeckstein]

I'm curious why we need to use #ifdef USED_IN_CPP_SOURCE to hide certain types

This is the "PURE" bridging mode. To workaround some problems with C++ interop. See #69039.
Last time I tried, I could only build with the pure mode on windows.