Looks great!

Firstly, I wonder whether this is related: #2172

Secondly, my brainstorm on implementing this:

• Code changes mainly are in parser/mir
• Maybe try to parse types like Pin<Box<dyn Future<Output = String> + Send + 'static>> into (1) "let's fake it as if user is writing a String here" (2) "let's mark MirFunc.rust_async = true".
• Then the code generator will do everything automatically. It will treat as if it is async fn f() -> String and generate code related to strings and async/await and done.

I think it is related to #2172, yes.

I was trying to do exactly what you propose, but when a dyn Future is encountered, it seems not to be part of src_traits here: https://github.com/vhdirk/flutter_rust_bridge/blob/2ae58f68ffd2e223199bec6c508c577a02ef49d5/frb_codegen/src/library/codegen/parser/mir/parser/ty/trait_def.rs#L16

but when a dyn Future is encountered, it seems not to be part of src_traits

One way (just brainstorm, may or may not be the best way):

Mimic what we do to parse, say, Vec<String> (https://github.com/vhdirk/flutter_rust_bridge/blob/2ae58f68ffd2e223199bec6c508c577a02ef49d5/frb_codegen/src/library/codegen/parser/mir/parser/ty/concrete.rs#L72). We may have a futures.rs that recognizes Pin<Box<dyn Future<Output = String> + Send + 'static>> and directly return something like MirType::Delegate(MirTypeDelegate::Future(String)). It can be done by matching the type to see "is it a Pin, and if so, is the inner type a Box, and if so, is inner dyn, and if so, is inner Future, and if so, ...". Similarly we can find impl Future as well.

And, we put this early on https://github.com/vhdirk/flutter_rust_bridge/blob/2ae58f68ffd2e223199bec6c508c577a02ef49d5/frb_codegen/src/library/codegen/parser/mir/parser/ty/path.rs#L36 (e.g. just above that line). Then, that will take precedence.

I've finally been able to find some time for this PR again. My latest commit makes it successfully parse Pin<Box<dyn Future<Output = String>. I haven't looked at the code generator yet, though.
I think impl Future is also supported, but it's getting late here and I can't really recall if I did or didn't do that yet :)

@fzyzcjy: could you have another look please? There's a bit of cleaning up to do still, but I was trying not to touch too much things all at once.

Great job! I will find some time to review it, probably within a day

Codecov Report

Attention: Patch coverage is 79.56989% with 57 lines in your changes missing coverage. Please review.

Project coverage is 82.05%. Comparing base (9e5c6e5) to head (ad0b1c8).

@@             Coverage Diff             @@
##           master    #2189       +/-   ##
===========================================
- Coverage   99.06%   82.05%   -17.02%     
===========================================
  Files         488      468       -20     
  Lines       20186    18368     -1818     
===========================================
- Hits        19997    15071     -4926     
- Misses        189     3297     +3108     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Well, I haven't actually tested the generated code. Not even once. But if it doesn't work immediately, I probably need some additional advice anyway :)

Sure, take your time and ping me when needing any suggestion etc!

I think I'm at a point where a proper review might be welcome. I think I broke some existing tests, but TBH, I don't quite know why that is :/

Sure!

I think I broke some existing tests, but TBH, I don't quite know why that is :/

Try to copy-paste it to frb_example/dart_minimal and play with it, which is often easier (and faster) to debug.

Btw CI may fail b/c some Dart updates, but my recent several PRs will fix it (along with other new code), so no worries about that.

So couple of things:

• apparently I've introduced a regression with struct/enum parsing where it starts to complain that enum unit variants are not supported. I've been looking at the diff and I can't really spot any obvious difference. So in depth debugging is needed, and I'd kindly ask your help for that.
• I'm on rust 1.80 and I get compile errors due to #[cfg(wasm)]. This is new for 1.80, apparently: https://blog.rust-lang.org/2024/05/06/check-cfg.html

So in depth debugging is needed, and I'd kindly ask your help for that.

Maybe try to do sth like:

• reproduce the bug in frb_example/dart_minimal
• run the new (buggy) codegen once, and the old (bug-free) codgen once
• look at what they differ. use debugger, or do printing may help. also the rust/target/frb_dump logs may also help

errors due to #[cfg(wasm)]

That one was meant to be "only compile when in wasm mode". Thus maybe try to change to #[cfg(target_family = "wasm")] etc.

Cross-link: #2234 (reply in thread)

(since github does not auto cross-link between a discussion and a issue/pr)