I'm playing around with making a decl macro to parse Rust syntax, for use by other decl macros. The idea is to strip away all the tedious, repetitive, and tricky bits when writing most Rust-parsing decl macros, and give the user a relatively clean interface.

To do this, I've got the following structure:

#[doc(hidden)]
pub use paste::paste;

#[macro_export]
macro_rules! parse_struct {
    ( $macro_name:ident, /* some arguments n' stuff */ ) => {
        $crate::paste! {
            // in reality, these `#[macro_export]`s are conditional;
            // the defined macros can be can be crate-private

            // this inner macro is necessary to achieve ergonomic results
            #[doc(hidden)]
            #[macro_export]
            macro_rules! [< __declrsyn_inner_ $macro_name >] {
                /* ... */
            }

            #[macro_export]
            macro_rules! $macro_name {
                (/* ... */) => {
                    /* some stuff involving the above-defined, private macro */
                };
            }
        }
    };
}

The problem is that the user could, in theory, define multiple macros within their crate with the same name, in different places. Due to how macros namespace, they would then conflict at the crate root.

I could write my own paste! replacement proc macro that generates a random identifier each time, but that would force a recompilation even when nothing has changed. I could try and hash the inputs instead, and use that, but that seems too fragile (and technically doesn't entirely solve the problem).

Is there a clean solution to this? Is there even a compelling reason to make this a decl macro instead of a proc macro, given that I already have to involve proc macros for generating identifiers?

1 post - 1 participant

Read full topic