Open dbsxdbsx opened 6 days ago
I am not sure whether the error is caused by the functions you present (possibly also by combination with usage somewhere else).
As for why sometimes RustAutoOpaque is needed, this is usually because of Rust's rules. For example, if you want A
or Option<A>
or Vec<A>
as argument of a function, then you have no choice but to own the instance of A
. That means you will never be able to use that same instance anywhere else. But if RustAutoOpaque<A>
, then it is as if Arc<A>
and thus shared ownership, and no problem.
so, that means there is no need to modify the return type of any rust fn, there should be someplace elsewhere triggered the running panic.
I guess so
win10, frb 2.4.0 Similar to this issue still, it is hard to diagnose to the real place trigger it. Anyway, finally, I find it is due to this dart code:
the correspding rust code:
why I am sure this fn is the core issue part? Because when replacing the
media::init_all_cms_media_docs(cms_list, number, target_media_type)...
part intovec![]
, the issue disappeared.Here, the
MediaDoc
is defined like this :the
#[frb(opaque)]
is essential, otherwise, the generation would be failed with an ambiguity warning. Then, I tried to fix it:But still, the issue is still there.
Actually, for this issue, I would rather this likely issue could be fixed totally so that users never need to care about
RustAutoOpaque