Feature request: dynamically-linked plugin system

[Nadrieril]

Would be very cute if downstream users could write transformation passes, compile them to a dylib, and Charon would load them and run them.

Seems conceptually simple: expose a pub fn transform(&mut TransformCtx) and run it from Charon at the end of the pipeline. This might even turn out to be easy.

[Nadrieril]

Claude says this is easy (I described a situation where crate A is charon_lib which exposes some Ast type, and binary B is charon):

The basic setup

// plugin side — compiled as dylib
#[no_mangle]
pub fn transform(ast: &mut crate_a::Ast) { ... }

// in B, at runtime
let lib = unsafe { libloading::Library::new("plugin.so")? };
let transform: libloading::Symbol<fn(&mut Ast)> = unsafe {
    lib.get(b"transform")?
};
transform(&mut my_ast);

That's... basically it. With same-toolchain + same crate A version, this actually works.

What you still need to be careful about

Crate A must be the same compiled instance. This is the sneaky one. If B and the plugin both depend on crate A but Cargo compiles two copies (e.g. different feature flags, or the plugin statically links its own copy), Ast is technically two different types and you'll get corruption. You need to ensure crate A is a dylib itself so there's one shared copy, or that the plugin is compiled against B's exact Cargo.lock.

Global state / allocator. If Ast contains heap allocations (Vec, String, Box, etc.), the plugin and B must share the same allocator. With the same toolchain and linking setup this is usually fine on Linux/macOS, but on Windows the CRT situation can still bite you. Worth testing explicitly.