Skip to content
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

Support generating equality operators or IEquattable<T> implementation in C# via ClangSharpPInvokeGenerator #539

Open
rzikm opened this issue Apr 22, 2024 · 2 comments

Comments

@rzikm
Copy link
Member

rzikm commented Apr 22, 2024

Consider (perhaps large) C structures received from native code and used in .NET via generated PInvoke bindings. If the structure contains padding bytes, the default equality comparison logic for ValueTypes will fallback to an inefficient implementation using runtime reflection for each struct field, not to mention boxing due to the signature of the Equals() method accepting object arguments. We would like ClangSharpPInvokeGenerator to conditionally generate IEquattable implementations for us.

I am aware that generated code uses partial annotation and so we can add IEquattable implementation ourselves, but that leaves a possibility of it getting out of sync with the generated code if new members are ever added in the future.

@tannergooding
Copy link
Member

Can you give some examples where types are being used in scenarios where equality like that is required?

It's not always valid to do element-wise comparisons and there are many C struct definitions where there is an explicitly equality method exported that you're meant to use instead.

So far this has been left off as a very niche scenario where generating it by default for all types would be likely undesirable.

@rzikm
Copy link
Member Author

rzikm commented Apr 23, 2024

Can you give some examples where types are being used in scenarios where equality like that is required?

Inside System.Net.Quic, we need to construct MsQuicConfiguration objects, the construction is expensive and those objects are expected to be reused across connections. To do this transparently, we cache these objects and one of the keys to the cache is the QUIC_SETTINGS struct

https://github.com/dotnet/runtime/blob/dcc66a7ca25696a2326f296c3d8d3ac5a13f0524/src/libraries/System.Net.Quic/src/System/Net/Quic/Interop/msquic_generated.cs#L1061-L2039

generating it by default for all types would be likely undesirable.

I understand that, it would be fine to make this opt-in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants