There are still multiple objects with same key after merging warning

[NightBlaze]

Describe the bug

After update from dev.37 to dev.39 I began to receive warnings There are still multiple objects with same key after merging, thus randomly pick one

> flutter_rust_bridge_codegen generate
[2024-06-14T08:32:10.602Z WARN .../flutter_rust_bridge_codegen-2.0.0-dev.39/src/library/codegen/parser/hir/flat/transformer/merge_duplicate_transformer/mod.rs:72] There are still multiple objects with same key after merging, thus randomly pick one (key="User", objects={"name":"crate::internal::network::user_network/User","visibility":"Restricted","sources":["Normal"],"mirror":false}, {"name":"crate::internal::services::user_service/User","visibility":"Restricted","sources":["Normal"],"mirror":false})
... more similar warnings

My application features a layered structure, comprising network and service layers. The service layer employs network and storage as dependencies, and the application utilizes solely the service layer. To avoid verbosity, I elected for succinct naming conventions, where the "type" (be it network, storage, or service) of an object is indicated by the module name.

All of this code is housed within the internal folder, which is situated on the same hierarchical level as api, not within it. Additionally, I use pub(crate) instead of simply pub to avoid generating code for the code.

My flutter_rust_bridge.yaml contains

rust_input: rust/src/api/**/*.rs
dart_output: lib/src/rust

so flutter_rust_bridge_codegen generate probably should to ignore all code in internal.

Steps to reproduce

Logs

-

Expected behavior

I would like to flutter_rust_bridge_codegen generate ignore internal package or to have documentation about naming conventions.

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]

The warning appears because that: In HIR stage (first stage of parsing), we have to scan structs in the whole crate even if it is pub(crate), because there can be a pub function which uses that, and we have not enter the MIR stage (second stage) which really parses function arguments.

I agree this may be confusing to users. One way may be not to show these unless user specify a flag to print out more details. A more complicated way may be to only warn if this type is really used in a later stage.

This may not be of highest priority since it does not cause real errors, but I will try to find some time to work on it. Alternatively, feel free to PR!

[NightBlaze]

@fzyzcjy Does it mean that I can just ignore the warnings?

[fzyzcjy]

If you do not use those types, then yes just ignore it currently.

[github-actions]

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.