RustBuffer regression with nested Errors #2108
Comments
OtaK
changed the title
|
Nothing springs to mind here.
What does "passed around" mean here exactly? I assume you mean as function args/results rather than via errors? Regardless, I think we will probably need a complete example - the easiest for us would be to reproduce it in, say, https://github.com/mozilla/uniffi-rs/tree/main/fixtures/ext-types/lib - that's our fixture explicitly for external types. |
I mean passed around in the FFI via a Result carrying I'll try to whip up something, but what I can say about my investigation, is that if I turn the It's entirely possible that my use case (non-flat error with externally-defined flat-error members) falls into the cracks of this test function |
|
thanks for the info - so it might be that it's not related to "external" types at all - so maybe it might be easier to repro in https://github.com/mozilla/uniffi-rs/tree/main/fixtures/error-types |
OtaK
added a commit
to wireapp/uniffi-rs
that referenced
this issue
May 15, 2024
|
@mhammond I added a fixture testcase at https://github.com/wireapp/uniffi-rs/tree/fixture/issue-2108 I get the following error traces (I couldn't make the python work, seems my example also makes it generate non-compiling code) KotlinSwiftPython |
|
That's great, thank you! |
mhammond
added a commit
to mhammond/uniffi-rs
that referenced
this issue
May 17, 2024
mhammond
added a commit
to mhammond/uniffi-rs
that referenced
this issue
May 17, 2024
mhammond
added a commit
to mhammond/uniffi-rs
that referenced
this issue
May 20, 2024
When a `#[derive(uniffi::Error)]` didn't appear in any function signatures, the FfiConverter for the item was written to assume an error, but the bindings FfiConverter treated the item as a plain-old Enum. This caused runtime errors when trying to unpack the rustbuffers due to the disagreement about the buffer format. As part of fixing this, the `Option<bool>` to try and represent the flatness of Enums/Errors was replaced with an `EnumFlatness` enum to make these states clearer and so the ComponentInterface can better understand the layout. Fixes mozilla#2108
mhammond
added a commit
to mhammond/uniffi-rs
that referenced
this issue
May 24, 2024
When a `#[derive(uniffi::Error)]` didn't appear in any function signatures, the FfiConverter for the item was written to assume an error, but the bindings FfiConverter treated the item as a plain-old Enum. This caused runtime errors when trying to unpack the rustbuffers due to the disagreement about the buffer format. As part of fixing this, the `Option<bool>` to try and represent the flatness of Enums/Errors was replaced with an `EnumShape` enum to make these states clearer and so the ComponentInterface can better understand the layout. Fixes mozilla#2108
mhammond
added a commit
that referenced
this issue
May 24, 2024
When a `#[derive(uniffi::Error)]` didn't appear in any function signatures, the FfiConverter for the item was written to assume an error, but the bindings FfiConverter treated the item as a plain-old Enum. This caused runtime errors when trying to unpack the rustbuffers due to the disagreement about the buffer format. As part of fixing this, the `Option<bool>` to try and represent the flatness of Enums/Errors was replaced with an `EnumShape` enum to make these states clearer and so the ComponentInterface can better understand the layout. Fixes #2108
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi!
I'm having a problem I quite can't solve even after investigating.
I have the kinda following structure
crate 1, which exposes a couple of flat error enum:
crate 2, which consumes those 2 errors in a normal error enum:
On both Kotlin and Swift bindings I get those errors whenever
FfiErroris passed around:Kotlin:
java.lang.RuntimeException: junk remaining in buffer after lifting, something is very wrong!!Swift:
UniffiInternalError.incompleteData "The buffer still has data after lifting its containing value"Any idea what causes this? This used to work before I upgraded to 0.27.x, but I can't poinpoint exactly which commit causes this regression.
The text was updated successfully, but these errors were encountered: