Closed JustSimplyKyle closed 1 year ago
Yes that's expected in the current version. Macros can create arbitrary things, while our parser executes before macros are run currently.
However, feel free to PR! One naive way may be that, we may call rust compiler to expand the macro, and run our frb only on that expanded code.
In addition, another way is that, you can check other packages that parses rust code (e.g. rust-to-c code generator?). If some packages somehow understand this, it would be great to learn from it.
Rust2C? I can only find C2rust https://github.com/dtolnay/cargo-expand#disclaimer There is this, so the second option isn't that great
Currently my "workaround" is to have a module, containing only that macro. and then use cargo expand to expand that macro. Kinda like a code generation, within a code generation. I don't think this workaround can be written within frb, it might be out of the scope of the project. A separate utility would be much suitble
Oh I mean something like https://github.com/mozilla/cbindgen or https://github.com/PyO3/pyo3 - check whether their current version support things inside macro
Yes I do expect something like cargo-expand.
flutter_rust_bridge already calls a lot of utilities inside it (e.g. cbindgen, ffigen, etc), so it is not a problem to let it call cargo-expand :)
I tried experimenting with cargo expand to get this working but it creates a few problems.
I got some stuff working without the build-scripts and by using doc-comments as mirror markers. Might be worth to create a pull request and use it as a starting point and for discussion.
All the marker macros are gone after expanding (e.g. mirror) I got some stuff working without the build-scripts and by using doc-comments as mirror markers
Hmm, one naive way may be, we parse and translate frb marker macros into a comment. For example, we can parse#[frb(apple, orange)]
into a internal struct, and use serde to serialize it into a json and become a comment like // FRB: {"apple": true, "orange": whatever}
etc
The build scrips in the tests have to be changed because they create a deadlock
One more naive idea for brainstorming: Maybe we can use environment variable to control the behavior of the build script. In other words, our frb build script may like:
fn main_function_in_build_script() {
if (env("FRB_IS_DOING_CARGO_EXPAND") == "yes!!!") {
println!("do nothing when doing cargo expand to avoid deadlock");
} else {
run_frb_codegen();
}
}
fn run_frb_codegen() {
execute_shell_command("cargo expand", environment_variables={"FRB_IS_DOING_CARGO_EXPAND": true});
...
}
I will try this next week. But I think it still doesn't work because just running cargo-expand from the buildscript already creates a deadlock. The cargo expand will hang at "waiting for file lock on build directory" or something like that. Maybe there is a way to ignore that lock.
Hmm that looks like a problem. More ideas for brainstorm:
@JustSimplyKyle This should be fixed by #1320 So you can try again after the next release
Thanks for the pr! can confirm works in my use case
Oops I forget to execute the release script, will do it now
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.
Describe the bug
It failed to generate types defined by macros.
Codegen logs with
RUST_LOG=debug
environment variableTo Reproduce
Expected behavior
To work!
Generated binding code
No response
OS
Arch Linux 6.3.7
Version of
flutter_rust_bridge_codegen
1.79.0
Flutter info
Version of
clang++
15.0.7
Version of
ffigen
8.0.2
Additional context
No response