Proc_macro in an existing library crate

language design
21

I'd like to be able to do the same for the time crate. Having the ability to use macros would be nice, but not strictly necessary.

Right now there's too much overhead (given lack of diagnostics and hygiene), but down the road if like to be able to treat a macro as an integral, lightweight part of a crate.

22

The crate mentioned in the OP is indeed using 3 crates, when 2 would suffice (the #[proc_macro_hack] pub use crate can be inlined within the fronted crate).

I think that having a:

[proc-macro]
path = "src/lib/proc_macros/mod.rs"

as sugar for the shenanigans that are currently required to achieve that effect (which include having to use something like cargo release or cargo workspaces to handle the versions of the two Cargo.toml files) would indeed be a nice ergonomic bump, especially now that rust 1.45.0 (to be released in July) is expected to support procedural macros in expression and statement position. Both changes will really help making procedural macros a first class citizen in the ecosystem.

  • I would be willing to help with the actual implementation effort in that regard
Aside

in the case of function-like procedural macros this annoying limitation can be circumvented by having a macro_rules! macro wrap the procedural one:

//! facade crate
#[doc(hidden)] /** Not part of the public API **/ pub
use proc_macros::my_macro as __my_macro__;

#[macro_export]
macro_rules! my_macro { ($($input:tt)*) => (
    $crate::__my_macro__! {
        #![crate = $crate]
        $($input)*
    }
)}
4 Likes
23

Would this need a proper RFC to move forward? It seems like a good idea, and I'd hate to see it fall by the wayside.

24

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.