custom FLUTTER_RUST_BRIDGE_HANDLER needs to be declared inside a file that is a "rust_input" file

[Vollbrecht]

Describe the bug

The documentation mention that if a user declares its own custom FLUTTER_RUST_BRIDGE_HANDLER, then flutter_rust_bridge generate will not generate its own ( if it can detect it) . E.g not including the default macro.

While its not really specified what needs to be done in order to be "detectable" for frb ( At least the place that is talking about in the doc did not do that) , i would assume a pub static would just be enough.

Maybe i just assumed to much here but i thought, if i had public definition of it somewhere, than frb could pick it up. So that's why i am a bit split if that is a bug or the "intended behavior". If it's intended than the doc's should mention this critical info.

Steps to reproduce

a) have two public modules A and B. b) public module A is the one declared inside flutter_rust_bridge.yaml file as "rust_input" as "rust_input: crate::A" c) have a FLUTTER_RUST_BRIDGE_HANDLER definition like the following in a pub module B:

pub static FLUTTER_RUST_BRIDGE_HANDLER: LazyLock<RuntimeHandler<SimpleThreadPool>> = LazyLock::new(
    || {
        assert_eq!(
            crate::frb_generated::FLUTTER_RUST_BRIDGE_CODEGEN_VERSION,
            flutter_rust_bridge::for_generated::FLUTTER_RUST_BRIDGE_RUNTIME_VERSION,
            "Please ensure flutter_rust_bridge's codegen ({}) and runtime ({}) versions are the same",
            crate::frb_generated::FLUTTER_RUST_BRIDGE_CODEGEN_VERSION,
            flutter_rust_bridge::for_generated::FLUTTER_RUST_BRIDGE_RUNTIME_VERSION,
        );

        let tp = SimpleThreadPool(threadpool::ThreadPool::new(5));
        let simple = SimpleHandler::new(
            SimpleExecutor::new(NoOpErrorListener, tp, Default::default()),
            NoOpErrorListener,
        );
        simple
    },
);

In this case it will not create a pub use crate::B::FLUTTER_RUST_BRIDGE_HANDLER; inside frb_generate. But as soon as i would put it into module A it works,

That is in that way confusing as other stuff automagically gets included in the frb_generated file. For this example other stuff like a pub error enum that lives in module B find it's way into frb_generated code

Logs

no log

Expected behavior

No response

Generated binding code

No response

OS

No response

Version of flutter_rust_bridge_codegen

No response

Flutter info

No response

Version of clang++

No response

Additional context

No response

[fzyzcjy]

Hmm you are right. I guess this is because in the old days frb v1 only support one single input file, thus no such issues.

For simplicity, maybe we can mention it in doc about this requirement, and at the same time tell users "if your scenario need to put it on other files, please create an issue". Feel free to PR! Alternatively I can do it.

[github-actions[bot]]

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.