search

fzyzcjy / flutter_rust_bridge

Flutter/Dart <-> Rust binding generator, feature-rich, but seamless and simple.
https://fzyzcjy.github.io/flutter_rust_bridge/
MIT License
4.18k stars 289 forks source link

[experimental-feature] Allow rust2dart to take precedence over other sources for the same type #2278

Open aran opened 1 month ago

aran commented 1 month ago

Is your feature request related to a problem? Please describe. crate 'proto' has type P. crate 'api', a rust_input, does 'pub use P' and has a rust2dart() implementation. Everything is good here. Now we add crate 'newimport', a new rust_input, has a struct which includes a proto::P.

...frb_generated.rs: error[E0119]: conflicting implementations of trait SseDecode for type P.

One implementation is the correct one, with the rust2dart implementation. The other is a standard generated one.

Describe the solution you'd like When a type has a rust2dart implementation configured, use it everywhere for that type.

Describe alternatives you've considered N/A Additional context N/A

fzyzcjy commented 1 month ago

Looks like this is because frb does not handle each and every corner case of use, and the primary use case is single-crate instead of crate-import-another-crate-import-yet-another-crate. Indeed scanning a whole 3rd party crate is an experimental feature.

The simplest way may be avoid using too many crates which may confuse frb. Also feel free to PR to enhance this "scanning 3rd party crate" experimental feature!

aran commented 1 month ago

Makes sense. To explain a little more, the main way I have been using FRB is there is some various Rust code not in the flutter project, there is the flutter project separately, and in the flutter project there is a single crate which has dependencies out to the rest of the Rust code. The Flutter project's crate is thin glue code, that's where I've been specifying mirror, external, dart2rust etc over the types to get FRB to generate the Dart code.

I'm also thinking that if I put some_crate::some_module on rust_input, it may change the behavior of FRB even for some_crate::another_module?

fzyzcjy commented 1 month ago

I see - that looks like a good use of "scanning 3rd party crate" experimental feature!

Another way may be, can you ensure you only have two crates: One for flutter (and frb), another for pure Rust. Then frb may be less confused when scanning the 3rd party crate.

I'm also thinking that if I put some_crate::some_module on rust_input, it may change the behavior of FRB even for some_crate::another_module?

Not very sure about the question, but frb does scan whole crate for struct information, since a function in some_crate::some_module may use structs in some_crate::another_module. And again, we cannot make breaking changes (until 3.0) so we may need to keep this (usually pretty reasonable) behavior.