Using traits from external third-party libraries

[akkumar]

I am using a third-party library / crate - for which I don't have any write / modification access at all.

1. Trait Calc is defined.
2. ThisError enum CalcError has been defined.
3. One implementation MyCalc has been defined

( all three defined in the 3rd-party crate - for which I have no read / modification rights.

use thiserror::Error;


#[derive(Error, Debug)]
pub enum CalcError {
    #[error("overflow Error")]
    OverflowError,
}


pub trait Calc {

    fn add(a: u32, b: u32) -> u32;

    fn overflow_add(a: u32, b: u32) -> Result<u32, CalcError>;
}

pub struct MyCalc {

}

impl Calc for MyCalc {
    fn add(a: u32, b: u32) -> u32 {
        a + b
    }

    fn overflow_add(a: u32, b: u32) -> Result<u32, CalcError> {
        Err(CalcError::OverflowError)
    }

}

Now - to use that traits in my flutter_rust_bridge_library

rust/src/api/calc.rs

pub use external_crate::{Calc, MyCalc};

use flutter_rust_bridge::frb;

#[flutter_rust_bridge::frb] 
pub fn new_calc() -> impl Calc { 
    MyCalc{}
}

Running flutter_rust_bridge_codegen flags the issue - Unknown ident Calc

Cmd

RUST_LOG=debug flutter_rust_bridge_codegen  generate

Output:

/home/myuser/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/flutter_rust_bridge_codegen-2.8.0/src/library/codegen/parser/mir/parser/function/real/mod.rs:115] parse_function see error and skip function: function="new_calc" error=when trying to parse DartFn

Caused by:
    Unknown ident  Calc

So - this trait Calc which is defined in an external 3rd-party library/ crate ( pub use external_crate::{Calc, MyCalc} ) is still being reported by flutter_rust_bridge as Unknown ident:

The question is - how do I tell flutter_test_bridge ( frb ) through macros as to use the external 3rd party trait definitions ?

Is there anything I need to do to redefine the same again ?

Can you help point to some docs as I could not find anything explaining as appropriate ?

[fzyzcjy]

Hmm firstly, maybe try not to use impl Calc, but something simpler, like Box<dyn Calc>

[akkumar]

1. Well - certainly that helped. ( changing impl Calc to Box<dyn Calc> ) .

2. Added the following crate to flutter_rust_bridge.yaml ( based on the contents here - https://cjycode.com/flutter_rust_bridge/guides/third-party/automatic/scanning ) .

rust_input: crate::api,<my_external_crate_name>

Get past the given issue - now I am getting a different error though , as per the following

RUST_BACKTRACE=full RUST_LOG=debug flutter_rust_bridge_codegen  generate

Error received:

[2025-03-05T14:52:34.916Z ERROR /home/myuser/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/flutter_rust_bridge_codegen-2.8.0/src/library/utils/logs.rs:54] panicked at /home/myuser/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/flutter_rust_bridge_codegen-2.8.0/src/library/codegen/generator/wire/dart/spec_generator/codec/dco/decoder/ty/enumeration.rs:10:9:
assertion `left == right` failed
  left: Simple
 right: Complex

I am not sure what the origin of this error might be.

Any ideas ?

[fzyzcjy]

Automatic scanning is experimental feature, and thus it is expected to fail on too complex third party crates, since rust has so many fancy features that it is not easy to cover all of them. But you can always use manual scanning if the automatic one does not work.

[akkumar]

Yes - disabling automatic scanning did indeed help.

As in - reverting flutter_rust_bridge.yaml to

rust_input: crate::api

( Removing <my_external_crate_name> did help , contrary to what I had mentioned previously ).

So - it generated the dart interface as below.

Future<BoxCalc> newCalc() => RustLib.instance.api.crateApiParserNewCalc();

// Rust type: RustOpaqueMoi<flutter_rust_bridge::for_generated::RustAutoOpaqueInner<Box < dyn Calc + Send + Sync >>>
abstract class BoxCalc implements RustOpaqueInterface {}

Now that I got access to a BoxCalc - how do I get access to those methods of the BoxTrait (equivalent of Box) ?

My rust interface defines as below.

pub trait Calc {

    fn add(a: u32, b: u32) -> u32;

    fn overflow_add(a: u32, b: u32) -> Result<u32, CalcError>;
}

So in dart, How exactly will I access the methods of the trait from BoxTrait dart (equivalent to the Box<dyn Trait> rust code) ?

[akkumar]

It seems there is no knowledge in the generated code for the external trait defined in 3rd-party libraries / crates.

Hence manually added the definitions right here ( copying from the trait in the 3rd party library )

#[frb(external)]
impl dyn Calc {
    pub fn add(&self, a: u32, b: u32) -> u32 {}

    pub fn overflow_add(&self, a: u32, b: u32) -> Result<u32, CalcError> {}
}

That change does not work - since it brings a whole lot of compilation errors in frb_generated.rs .

So - how do we tell flutter_rust_bridge_code generate regarding the type definitions/ function signatures of traits in 3rd party packages/crates ?

What am I missing ?

[fzyzcjy]

I will check whether it's a bug later. But a quick workaround is: Write pub type ThirdPartyCalc(Box<dyn Calc>); and define methods (which is only one-liners because it does nothing but forward everything to the external type) on the new type.

[akkumar]

I will check whether it's a bug later. But a quick workaround is: Write pub type ThirdPartyCalc(Box);

So the new code looks like this.

rust/src/api/parser.rs

pub type ThirdPartyCalc = Box<dyn Calc + Send + Sync>;


#[flutter_rust_bridge::frb] 
pub fn new_calc() -> ThirdPartyCalc { 
    Box::new(MyCalc{})
}

Running the command flutter_rust_bridge_codegen generate makes no difference to the final generated dart code.

Future<BoxCalc> newCalc() => RustLib.instance.api.crateApiParserNewCalc();

// Rust type: RustOpaqueMoi<flutter_rust_bridge::for_generated::RustAutoOpaqueInner<Box < dyn Calc + Send + Sync >>>
abstract class BoxCalc implements RustOpaqueInterface {}

and define methods (which is only one-liners because it does nothing but forward everything to the external type) on the new type.

Well - can you help how to define methods for the newly created type alias ThirdPartyCalc as above.

The original 3rd party Calc trait looks as below.

pub trait Calc {
    fn add(&self, a: u32, b: u32) -> u32;

    fn overflow_add(&self, a: u32, b: u32) -> Result<u32, CalcError>;
}

So - in summary - to keep the long story short, what should be done to make frb identify the correct type a trait , returned by a method ( mostly through a Box<dyn Trait> ).

[fzyzcjy]

Well, I mean newtype pattern, i.e.

pub struct ThirdPartyCalc(Box<dyn Calc + Send + Sync>);

impl ThirdPartyCalc {
  fn add(&self, a,b) { self.0.add(a,b)}
}

[akkumar]

I will check whether it's a bug later. But a quick workaround is: Write pub type ThirdPartyCalc(Box); and define methods (which is only one-liners because it does nothing but forward everything to the external type) on the new type.

Well - finally got to work around this one - based on what you had suggested.

#[frb(ignore)]
type ThirdPartyCalc = Box<dyn Calc + Send + Sync>;


#[frb]
pub struct ThirdPartyWrapper(ThirdPartyCalc);

impl ThirdPartyWrapper {
    pub fn add(&self, a: u32, b: u32) -> u32 {
        return self.0.add(a, b);
    }

    pub fn overflow_add(&self, a: u32, b: u32) -> Result<u32, CalcError> {
        return self.0.overflow_add(a, b);
    }
}


#[flutter_rust_bridge::frb(sync)] 
pub fn new_calc() -> ThirdPartyWrapper { 
    ThirdPartyWrapper(Box::new(MyCalc{}))
}

[ Credits : This code is very much inspired by this thread here at - #2172 (comment) . ]

The above work certainly compiles in rust and dart , although a bit round about and brittle though.

FYI.

[fzyzcjy]

Oh yes, that's what I mean!

[akkumar]

Summary: This works but a little bit convoluted for sure.

If there are other better options / suggestions - feel free to add some.

[fzyzcjy]

Yes I agree, as mentioned above,

rust has so many fancy features that it is not easy to cover all of them

so automatic scanning of 3rd party crates may not be easy...

[akkumar]

To clarify, the example mentioned above is of manual scanning.

[ Not automatic at all - as in adding the crate name to flutter_rust_bridge.yaml :: rust_input . ]

Couple of points worth mentioning:

1. Even with manual scanning - is there a simpler way to tell frb regarding the definition of the trait ( say - #[frb(external)] ) to prevent redefinition of the traits again

2. In the rust world, Box automatically imports the methods of the underlying Trait.
   In the frb world, Box merely translates to BoxTrait and the methods get translates as RustOpaqueInterface and all the context of the trait i.e. methods/functions are lost.

Perhaps a special case parsing for Box<dyn T> might be necessary. I am not sure if such a solutions exists or is feasible.

I am sharing some summary here and possible directions for future parsing. Just to make things simpler than whatever the workaround that is presently available ( as illustrated earlier in the thread ) .

so automatic scanning of 3rd party crates may not be easy...

Certainly that is not disputed at all. Thanks for the hard work - sharing some feedback to improve better.

[fzyzcjy]

Totally agree! It would be great to implement that feature in the future, also feel free to PR :)

[akkumar]

Submitted a PR https://github.com/fzyzcjy/flutter_rust_bridge/pull/2597 to capture some of the final take-away of this thread for future reference.