Closed kegsay closed 6 months ago
Yikes, this is gnarly. Seems like ffi_rust_future_continuation_callback_set
uses global state, not per-package state. I'm not sure whats the best way to move forward with this. I believe starting with uniffi-rs:v0.26.0
futures implementation was revamped with poll-based instead of callback-based architecture, and uniffiInitContinuationCallback
is not needed anymore. I doubt Mozilla upstream guys would be willing to somehow revamp futures implementation for uniffi-rs:v0.25.0
to make it compatible with multiple ffi_rust_future_continuation_callback_set
calls. I guess the "easiest" solution would be to somehow ensure only 1 bindings package invokes uniffiInitContinuationCallback
.
I'm afraid I can't provide much assistance with this at the moment, async is not a priority for our teams and I'm currently focusing on other work.
Apply this patch to the errors fixture:
Then
./build.sh
,./build_bindings.sh
and finally./test_bindings.sh
:The panic is in this function:
The problem is similar to https://github.com/NordSecurity/uniffi-bindgen-go/issues/43 in that when the runtime type cast is made, it fails because the callback is called with
C.int8_t
from thefutures
package, whereas this is type-casting toC.int8_t
from theerrors
package.In reality, the callback should not be triggered at all from the
errors
package (as the diff doesn't actually call the defined function anywhere) but this happens because it is set when the package is loaded:This init function appears in both the
errors
andfutures
package, and I guess they step on each other (errors runs first so I guess the 2nd call touniffiInitContinuationCallback()
is a no-op, causing the errors callback to be called for futures tests.