Crate darkly_macros 

darkly-macros: the #[handlers] engine-bridge macro.

Tag an impl DarklyEngine { … } block with #[handlers] and mark the methods that should be reachable over the request/response protocol with an inner #[handler] (or #[handler(returns = graph)]). For each marked method the macro derives (from the signature alone) everything the old hand-written handlers/*.rs files spelled out:

• a #[derive(Deserialize)] …Req struct, one field per parameter (the receiver is dropped; a bytes: &[u8] parameter binds to the protocol’s binary side-channel instead of a JSON field; &str/&[T] parameters become owned String/Vec<T> fields and are re-borrowed at the call);
• a DarklyEngine::__darkly_handler_<name>() associated fn returning the RequestRegistration, which decodes the Req, calls the method, and converts the return through the autoref-specialized response tags (()/T: Serialize → JSON, Result<T, String> → JSON or engine error).

The kind string is the method name verbatim, so the signature is the single source of truth. build.rs scans for #[handler] and aggregates every generated registration (no linkme: it doesn’t compile on wasm32).

Why an impl-block attribute rather than a per-method one: an attribute macro on a method may only emit associated items, but the Req structs must be top-level (nameable, TS-derivable). Wrapping the block lets one expansion emit the cleaned impl, the top-level Req structs, and the registration impl together.

Attribute Macros

handlers

Attribute for impl DarklyEngine blocks. See the module docs.