Open pattobrien opened 4 months ago
Hi! Thanks for opening your first issue here! :smile:
Hmm, feel free to PR to support that, which may not be super hard (since we already support struct Something {}
). I may also work on it later.
For workaround, you can always fallback to the manual mode. In other words, just write down a simple wrapper of the API.
Hmm, feel free to PR to support that, which may not be super hard (since we already support
struct Something {}
). I may also work on it later.
I actually don't believe that turned out to be the issue; the verbose logging created too much noise around unit structs, and after forking the yrs
repo and modifying all unit structs, I was still getting the same cryptic errors.
[2024-07-12T16:22:28.637Z ERROR /Users/pattobrien/.asdf/installs/rust/1.79.0/registry/src/index.crates.io-6f17d22bba15001f/flutter_rust_bridge_codegen-2.1.0/src/library/utils/logs.rs:55] panicked at /Users/pattobrien/.asdf/installs/rust/1.79.0/registry/src/index.crates.io-6f17d22bba15001f/flutter_rust_bridge_codegen-2.1.0/src/library/codegen/ir/mir/ty/structure.rs:36:32:
no entry found for key=MirStructIdent(NamespacedName { namespace: Namespace { joined_path: "yrs::sync::protocol" }, name: "DefaultProtocol" })
thread 'main' panicked at /Users/pattobrien/.asdf/installs/rust/1.79.0/registry/src/index.crates.io-6f17d22bba15001f/flutter_rust_bridge_codegen-2.1.0/src/library/codegen/ir/mir/ty/structure.rs:36:32:
I forked the frb repo, added yrs
to the config and cargo on the integrate_third_party
example. If you're interested, you should be able to see the same error that I'm experiencing.
I wish I could be more useful here, but I'm not familiar enough with Rust to debug this further myself!
I'm going to try to use the package with manual bindings in the mean time :)
Ok I see. IIRC that error can happen when the package has too fancy use
/mod
statements (it may not be the case here, but just one example). I hope I can check that and make frb understand the fancy code in yrs in the future, but maybe not soon, since the fix may be time-consuming and it is an experimental feature and has workarounds. Thus yes, maybe try to use manual bindings as a workaround (a lot of bridge-like packages only provide that way iirc).
Thanks so much for looking into the issue!
The manual bindings have been working well, though the process is slow for such a large package. I think it would be very helpful to be able to configure globs/types to include in the parsing process (similar toffigen
and jnigen
) so that I could auto-generate most types, and do the rest manually... but thats a topic for another ticket :)
Please feel free to re-word the description/title for the "fancy use/mod statements", or close if there's an existing issue. I can keep that repository alive so that you have something to test against.
The manual bindings have been working well, though the process is slow for such a large package
I think so, that is why I made the automatic way - to save time especially for large packages.
be able to configure globs/types to include in the parsing process
What about rust_input: crate::api,yrs::hello::this::is::subpackage
Please feel free to re-word the description/title for the "fancy use/mod statements", or close if there's an existing issue. I can keep that repository alive so that you have something to test against.
No worries, maybe we can keep it like that for a bit of time, since I have not checked it and cannot guarantee causes
Again, also feel free to PR!
What about rust_input: crate::api,yrs::hello::this::is::subpackage
Filtering doesn't work on third-party packages. No matter what combination of submodules you put there, the entire third-party crate seems to be parsed.
So there's no work around when there's any compilation errors, besides manually writing ALL third-party package code (which has turned out to be too much manually work for such a large package).
If filtering were to work, then this would be a lot less impactful of an issue.
I see. Again, feel free to PR for this! Alternatively I may work on it but again not very soon, since that feature is considered experimental and I do not have a lot of time implementing more now.
Another hacky workaround: Maybe fork the yrs package, and modify its content like:
/// flutter_rust_bridge:ignore
mod something_that_does_not_work_well;
By doing so, iirc that mod is not parsed at all.
By doing so, iirc that mod is not parsed at all.
Yeah that seems to prevent the modules from being parsed, but then the module isn't imported into the generated "frb_generated.rs" module and therefore the rust program fails to compile.
It seems like /// flutter_rust_bridge:ignore
and rust_input: some::module
are intended to do similar things: to configure exactly which modules, types, etc are generated. But it seems like there are many inconsistencies between what's generated rust-side vs. dart-side, and unfortunately the error logging also doesn't help much:
As stated in the docs, having the ability to ignore individual structs/enums would be helpful to circumvent errors.
I realize that it's hard to cover all edge cases for parsing/code-gen, and altogether I think the automatic scanning / code-gen works very well for 90% of the cases - some improved error logging and further work on ignoring structs/enums would go a long way in making the feature "good enough" IMO :)
Totally agree, that's partially why the "scan whole 3rd patry crate" feature is marked as "experimental"!
Hey, @pattobrien. Did you get any bright ideas on how to parse the yrs lib?
Did someone get it working?
Hey, @pattobrien. Did you get any bright ideas on how to parse the yrs lib?
Sorry for the delayed response! Unfortunately no, I wasn't able to get yrs
parsed - it seemed like a rabbit hole of issue after issue, and since I'm a novice at Rust it wasn't going to be simple for me to debug.
Sorry I couldn't have been of more help!
I guess yrs itself is too complex to be auto parsed by this experimental feature today. But if many people are interested in it, one way is to collaborate to manually handle the yrs, just like how people make a (semi-manual) binding from one language to another language.
Describe the bug
I'm not able to run the third party scanner on package
yrs
, due to the below error.Further in the debug logs, I see the message "struct with unit fields are not supported yet, what about using
struct DefaultProtocol {}
or#[frb(opaque)] struct DefaultProtocol;
instead" - but the struct in question cannot be modified, since it's a part of third party code.Steps to reproduce
yrs
as a dependency.flutter_rust_bridge.yaml
withrust_input: crate::api,yrs
.flutter_rust_bridge_codegen generate
Logs
Expected behavior
I would've expected two different outcomes:
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