You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is similar to #43 in that when the runtime type cast is made, it fails because the callback is called with C.int8_tfrom the futures package, whereas this is type-casting to C.int8_tfrom the errors 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 and futures package, and I guess they step on each other (errors runs first so I guess the 2nd call to uniffiInitContinuationCallback() is a no-op, causing the errors callback to be called for futures tests.
The text was updated successfully, but these errors were encountered:
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.
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 #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.The text was updated successfully, but these errors were encountered: