-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Swift Interop] Lowering fixed buffers #107620
Comments
Yes, I would expect fixed buffers to be supported for Swift lowering. I believe NativeAOT and CoreCLR already implement this correctly, but I may be misremembering. |
I'm pretty sure CoreCLR (preview 7) side doesn't work as well. I tried passing this struct as parameter to swift using coreclr backend and failed, which got me looking at runtime details in the first place. I haven't debuged on coreclr so I can't say whether the behaviour is the same as on mono. |
Looking at this again, it looks like we added support for I think it's fine say that legacy fixed buffers aren't supported due to the difficulties of recognizing legacy fixed buffers at the runtime level and the existing limitations of fixed buffers in interop scenarios. What do you think? |
I do think that We do lack the support for struct lowering them in mono though. Do we have a tracking issue for adding this to mono, or should I create one? The only thing which worries me about fixed buffers is that lowering them results in unexpected result. I do not know what should the convention be. Should we report an error when trying to lower unsupported type? |
Yes, please create a tracking issue for
Yes, that would be ideal. |
Support for |
We can leave this issue to track the effort on handling the fixed buffer. I do think that we should eventually either implement support for it or detect it and raise an appropriate error. |
Tagging subscribers to this area: @dotnet/interop-contrib |
Running the swift lowering algorithm on the following struct results in incorrect lowering. I did debug on mono and the resulting lowering is a single unsigned byte. I would expect this to be lowered into two int64.
@jkoritzinsky should such constructs be supported by the swift struct lowering algorithm?
cc: @kotlarmilos
The text was updated successfully, but these errors were encountered: