Skip to content

chore(ffi): use ruma's built-in uniffi support to eliminate some event type enums#6161

Merged
poljar merged 1 commit into
matrix-org:mainfrom
Johennes:johannes/uniffi
Jun 24, 2026
Merged

chore(ffi): use ruma's built-in uniffi support to eliminate some event type enums#6161
poljar merged 1 commit into
matrix-org:mainfrom
Johennes:johannes/uniffi

Conversation

@Johennes

@Johennes Johennes commented Feb 11, 2026

Copy link
Copy Markdown
Contributor

This is the smallest possible way that I could find to start using ruma/ruma#2338 in the FFI bindings. It eliminates the types StateEventType, MessageLikeEventType and RoomAccountDataEventType from the FFI crate and instead uses the Ruma types directly .

The only difference of the two types in the foreign language should be the use of Custom vs. Other.

  • Public API changes documented in changelogs (optional)

@Johennes Johennes force-pushed the johannes/uniffi branch 4 times, most recently from e0e9256 to 5acec1d Compare February 11, 2026 13:16
@codecov

codecov Bot commented Feb 11, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.89%. Comparing base (7b2b439) to head (bdb87ce).
⚠️ Report is 5 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #6161      +/-   ##
==========================================
+ Coverage   89.86%   89.89%   +0.02%     
==========================================
  Files         396      396              
  Lines      110260   110260              
  Branches   110260   110260              
==========================================
+ Hits        99088    99113      +25     
+ Misses       7395     7378      -17     
+ Partials     3777     3769       -8     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

@codspeed-hq

codspeed-hq Bot commented Feb 11, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 50 untouched benchmarks


Comparing Johennes:johannes/uniffi (bdb87ce) with main (e8673e4)

Open in CodSpeed

@Johennes

Copy link
Copy Markdown
Contributor Author

This is failing the complement-crypto tests now. These downgrade uniffi to 0.28.3. This no longer works because ruma's new uniffi support depends on changes from uniffi 0.31.0.

In particular:

  • doc(hidden) doesn't work in 0.28.3
  • uniffi::export only works on functions and impl blocks in 0.28.3 (ruma uses uniffi::export(Display, Eq, Hash) on an enum)
  • In 0.28.3 custom_type! only takes two type parameters and then you need to implement UniffiCustomTypeConverter. In 0.31.0 the macro takes the converters directly in a third argument

I can think of the following ways to resolve this:

  1. Split the uniffi implementation in ruma into two features, one that works with 0.28.3 and one that uses 0.31.0
  2. Change the rebuild_rust_sdk.sh script from complement to hack the changes into a local ruma checkout

I'm not sure which of these is worse but maybe I've missed a better option?

@jplatte

jplatte commented Feb 12, 2026

Copy link
Copy Markdown
Collaborator

The better option is to help move NordSecurity/uniffi-bindgen-go#86 forward, IMHO.

@Johennes

Copy link
Copy Markdown
Contributor Author

The better option is to help move NordSecurity/uniffi-bindgen-go#86 forward, IMHO.

That's still two minor versions behind what ruma needs but, yes, ideally the complement crypto tests wouldn't have to downgrade uniffi in the first place.

@jplatte

jplatte commented Feb 13, 2026

Copy link
Copy Markdown
Collaborator

Yeah, but it would unblock additional upgrades (which may be much easier than that one, if you're lucky ^^).

@poljar

poljar commented Apr 2, 2026

Copy link
Copy Markdown
Contributor

This should be unblocked as matrix-org/complement-crypto#233 is now merged.

@Johennes Johennes force-pushed the johannes/uniffi branch 6 times, most recently from 3ae18f2 to 41aaf22 Compare May 26, 2026 18:20
@Johennes

Copy link
Copy Markdown
Contributor Author

Looks like this still fails the complement-crypto tests. Will have to investigate what's wrong there.

 Error: Failed to extract data from archive member `ruma_events-2c1d40fe02f50a4b.ruma_events.21d0e9ca7cef90a2-cgu.09.rcgu.o`

Caused by:
    0: extracting metadata for 'UNIFFI_META_RUMA_EVENTS_CONSTRUCTOR_EPHEMERALROOMEVENTTYPE_FROM_STRING'
    1: Constructor return type must be Self or Arc<Self>

@Hywan Hywan left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contributions!

complement-crypto:
name: "Run Complement Crypto tests"
uses: matrix-org/complement-crypto/.github/workflows/single_sdk_tests.yml@399a1deeab0d7e4fa9604cbe83b1df6058c40193 # main
uses: matrix-org/complement-crypto/.github/workflows/single_sdk_tests.yml@1b1f86348079608fbc5276fe77c54dd66638a622 # main

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this change?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the commit that updated complement-crypto to uniffi 0.31.0 (which is the version the uniffi support in Ruma requires) and it is slightly ahead of the currently used SHA: https://github.com/matrix-org/complement-crypto/commits/main/

@Johennes

Copy link
Copy Markdown
Contributor Author

Looks like this still fails the complement-crypto tests. Will have to investigate what's wrong there.

 Error: Failed to extract data from archive member ``ruma_events-2c1d40fe02f50a4b.ruma_events.21d0e9ca7cef90a2-cgu.09.rcgu.o``

Caused by:
    0: extracting metadata for 'UNIFFI_META_RUMA_EVENTS_CONSTRUCTOR_EPHEMERALROOMEVENTTYPE_FROM_STRING'
    1: Constructor return type must be Self or Arc<Self>

The error appears to refer to this method. But confusingly that does already return Self. 🤷‍♂️

@Johennes

Copy link
Copy Markdown
Contributor Author

Sigh. I think #[uniffi::constructor] may only work on objects but not on enumerations. So we'll probably need to fix this in Ruma.

Comment thread Cargo.toml Outdated
@Johennes Johennes force-pushed the johannes/uniffi branch 4 times, most recently from f5efb05 to c8e7f7a Compare June 1, 2026 18:52
@Johennes Johennes requested a review from andybalaam June 9, 2026 06:56
@Johennes

Johennes commented Jun 9, 2026

Copy link
Copy Markdown
Contributor Author

The cargo-deny error seems to also exist on main. Apart from that, I believe this should finally be ready for review now.

@Hywan Hywan self-requested a review June 9, 2026 08:45

@andybalaam andybalaam left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks reasonable to me, without much context on the complement-crypto changes etc. Waiting for Ivan to comment, and asked one question about what I think is a merge mistake.

Comment thread .deny.toml

@andybalaam andybalaam left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good with me but I think there are unresolved conversations with other reviewers.

@Johennes

Copy link
Copy Markdown
Contributor Author

Sorry, I'm now realizing the bindings tests have uncovered a few more name clashes such as:

/Users/runner/work/matrix-rust-sdk/matrix-rust-sdk/bindings/apple/generated/swift/matrix_sdk_ffi.swift:40996:30: error: 'TimelineEventType' is ambiguous for type lookup in this context

I'm not sure why these didn't show up before. I think this will require renaming the exported FFI type names or trying to eliminate the FFI types in favour of the Ruma types.

@Johennes Johennes marked this pull request as draft June 11, 2026 06:26
@Johennes

Copy link
Copy Markdown
Contributor Author

Moving back to draft as this seems to require still further work. 😕

@Johennes Johennes marked this pull request as ready for review June 20, 2026 12:41
@Johennes Johennes force-pushed the johannes/uniffi branch 2 times, most recently from 23d068d to a496a7a Compare June 20, 2026 12:57
#[derive(Clone, uniffi::Enum, PartialEq, Eq, Hash)]
#[uniffi::export(Eq, Hash)]
pub enum TimelineEventType {
pub enum FfiTimelineEventType {

@Johennes Johennes Jun 20, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This required renaming because it caused a name-clash with the identically named Ruma type which is now also exported. Ruma's type is flat. So this wouldn't have been a drop-in replacement.

I tried renaming just the exported type name but that broke auto-generating the Eq and Hash implementations.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried renaming just the exported type name but that broke auto-generating the Eq and Hash implementations.

Not sure what this means exactly, but sounds like an upstream bug? Did you file an issue already?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I first tried adding #[uniffi::export(name = "FfiTimelineEventType")] but that then failed when generating bindings claiming that it cannot locate TimelineEventType. I have a hunch this might be because of the exported Eq and Hash implementations but haven't verified that. Reporting upstream sounds sensible assuming we can reproduce it in a minimal example.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried to reproduce it in a minimal example but couldn't. So I may have hit something else or maybe it's already been fixed.

@Johennes Johennes force-pushed the johannes/uniffi branch 2 times, most recently from 89765ef to 74c3f60 Compare June 20, 2026 13:12
@Johennes Johennes changed the title chore(ffi): use ruma's built-in uniffi support to eliminate StateEventType and MessageLikeEventType chore(ffi): use ruma's built-in uniffi support to eliminate some event type enums Jun 20, 2026
@Johennes

Copy link
Copy Markdown
Contributor Author

It looks like this is finally ready. The remaining lint error also exists on main.

@poljar poljar left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. We should just mention the rename of the exported type in the changelog as well.

#[derive(Clone, uniffi::Enum, PartialEq, Eq, Hash)]
#[uniffi::export(Eq, Hash)]
pub enum TimelineEventType {
pub enum FfiTimelineEventType {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a bit of an ugly name, hopefully the users of the bindings won't mind too much.

The more important bit here is that this is a breaking change though. We should mention this in the changelog.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's not pretty. Eventually this should just be replaced with the ruma type. That one has a different structure though. So doing that would have been a bigger breaking change than the renaming.

Maybe CC @stefanceriu for visibility on this.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And @jmartinesp as well.

Beware there's an annoying rename in this PR.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Argh, sorry for forgetting the Android side. I'm lacking coffee. 🙈 ☕

…t type enums

Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
@Johennes Johennes requested a review from poljar June 24, 2026 12:08
@poljar poljar merged commit d895344 into matrix-org:main Jun 24, 2026
54 of 55 checks passed
@jmartinesp

jmartinesp commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

I feel like I've said this quite a few times, but next time we do something breaking in the FFI side, could we have some time to test it before merging something 😅 ?

This broke a few unit tests we have on Android, since now StateEventType and MessageLikeEvenType have one case which is an Object (Custom) and that means it'll automatically try to load the native library (which isn't even built for the host's architecture) and the test won't even start. It's not like they're important tests so we can just remove them, but it would have been better to know about this in advance.

@poljar

poljar commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

This broke a few unit tests we have on Android, since now StateEventType and MessageLikeEvenType have one case which is an Object (Custom) and that means it'll automatically try to load the native library (which isn't even built for the host's architecture) and the test won't even start. It's not like they're important tests so we can just remove them, but it would have been better to know about this in advance.

Oh, I thought about requesting a real life test for it but underestimated how much this changed things.

Sorry.

If it's problematic we can revert this and reaply later, as it's a single commit.

@jmartinesp

Copy link
Copy Markdown
Contributor

No, I think it's fine, it's just a few unit tests we'll disable.

@Johennes

Copy link
Copy Markdown
Contributor Author

Apologies. I probably also should have pinged you about this much earlier than today. Sorry for the extra hassle.

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

Successfully merging this pull request may close these issues.

6 participants