Closed dbsxdbsx closed 2 weeks ago
vec: Vec<MyEnum>
will take ownership of the MyEnum. So it seems that this is expected that the x
is not useable after calling the test
function. Just like in pure rust:
pub fn process_enum(vec: &[MyEnum]) {}
let x = MyEnum {};
process_enum(&[x]);
x.getName(); // <-- COMPILE ERROR
Try &[RustAutoOpaque<MyEnum>]
if this is supported by frb
For future readers: DO NOT DOWNLOAD THE LINK ABOVE!
The comment of @Evul88 seems to be downloading virus or something like that, e.g. look at https://github.com/valeoai/BEVContrast/issues/3 and https://github.com/search?q=commenter%3AEvul88&type=issues.
(If I get it wrong, feel free to ping me and I apologize!)
Same for @Satyam1Deepu
&[RustAutoOpaque
]
Thanks advice, it does can:
pub async fn process_enum(vec: &[RustAutoOpaque<MyEnum>]) {
// process the vector of MyEnum
// let item = (*vec.first().unwrap().read().await).clone(); // if clonnable
let item = &(*(vec.first().unwrap().read().await));
let mut vec_clone = Vec::with_capacity(vec.len());
for item in vec {
let item_ref = item.read().await;
vec_clone.push(item_ref.clone());
}
// TODO: how to get vec_ref: &[MyEnum] from vec: &[RustAutoOpaque<MyEnum>]
}
But I didn't find way directly get ref &[MyEnum]
from the input param. And the vec_clone
version poisoned the inner type to be Clonnable. Otherwise, everything is fine.
Hopefully, in future, users can directly use &[MyEnum]
with no lifetime issue. I guess maybe it need to wait until the proxy
macro feature be fully used first.
Yes I think so - maybe we need to enhance the proxy to implement this, though that may be somehow nontrivial work
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new issue.
Env: Frb v2.3.0, win10, dart Dart 3.5.0, Rust 1.79.0 I got runnning panic
within my real project, which can be reproduced with the following simple example code:
with dart code:
At first, I think it is a pure dart issue related to the dart instance lifetime copy and reference issue, so I test this pure dart code:
which occurs no panic.
I've also referred this 2 issues, but seems they are not related to the issue here. So I suspect maybe this maybe a new bug related to the lifetime handling acrros dart/rust within frb?