Regarding Mirroring External Crate Types

[garysm]

As has been mentioned previously #1161, #1179, #1305, etc., manually mirroring external crate types can become quite tedious with nested types. Are there any alternatives to this? It was mentioned to CC @Unoqwy who implemented the awesome mirroring feature :)

For context, I am looking to create a Dart API for a large external crate (libsql).

Regarding handling types from other crates automatically and moving to remove the need for mirroring, what do you see as some of the largest roadblocks? I would love to work on a PR for any of those issues.

[garysm]

API Code example:

use std::cell::RefCell;
use std::sync::{Arc};
use tokio::{sync::Mutex};

pub struct Database {
    db: Arc<Mutex<libsql::Database>>,
    conn: RefCell<Option<Arc<Mutex<libsql::Connection>>>>,
    stmts: Arc<Mutex<Vec<Arc<Mutex<libsql::Statement>>>>>,
    default_safe_integers: RefCell<bool>,
}

[fzyzcjy]

Totally agree - It would make the usage much easier if there is no need to manually handle any mirroring. Looking forward to your PR!

IIRC, the main difficulty may be that, we have to correctly figure out the source code of that external type. There seems to have been some discussions but a quick search does not reveal that. However, this is surely implementable (and hopefully even with an existing crate now).

Another problem is that, how to allow users to customize the behavior. But this is - as you can see - a quite minor problem, since there can be a ton of ways to specify config. The simplest one may be adding #[frb(...)] or making a yaml config or whatever.

[Unoqwy]

I haven't used this project in over a year, so my involvement is a bit rusty (no pun intended).
The biggest problem is indeed gonna be getting the source code and the location of the structs to support within it.

One way I can think about getting the sources:

• Get the crate name and version for a given library name (e.g. by reading from cargo tree --prefix none --depth 1 --format '{lib}={p}')
• Find Cargo.lock (e.g. using cargo locate-project --workspace to get workspace's root) and infer what registry is being used
• Get the sources from the registry (e.g. ~/.cargo/registry/src/index.crates.io-XXX/crate_name-1.0.0)
• Consider cross-platform support, and that .cargo/config (local to project or user) may change cache path or have registry overrides

Another, perhaps more straightforward, way of doing could be to download the crate in a temp directory.
Either download by crate name + version from crates.io, and/or provide a setting to the user to specify a git repository (+ commit id to checkout at) with a specific path.

Then, a graph or whatever dark magic needs to be built from the crate's sources to find the correct struct (say in the source code you have an internal Model and a public Model).

Some libraries may re-export from internal crates too which complicates it even more.
The whole thing seems quite complex and is likely going to cost in maintenance. You should check if there is a way to re-use inference from tools like rust-analyzer or even the rust compiler itself, but consider that they may be resource intensive.

Regardless of how the above is done, I think manual struct mirroring should remain an option as it can be used to control what is exposed of a type.

[fzyzcjy]

Some brainstorming: Another way may be, we let the users to (at least partially) manually specify the crate path vs struct names, etc. But then, there is no need for users to manually write down a full "mirror struct". Instead, frb can use the provided paths to quickly find the source code of the struct.

Then, it seems that we can avoid all these engineering work, while providing a more friendly DX.