How to propagate dependencies of a proc-crate to user crate

[eadren]

I have a custom proc-macro crate called my_custom_plugin_attr which is used by my client crate my-client. my_custom_plugin_attr generates some TokenStreams which use types defined in third-party-crate. As a result, my client crate should add dependency third-party-crate besides my_custom_plugin_attr. It is implict right? How can I solve this dependency more explictly.

CMake have a keyword INTERFACE to propagate dependency. If my_custom_plugin_attr dependent third-party-crate with INTERFACE keyword, it means that my_custom_plugin_attr doesn't actually dependent third-party-crate, but the client crate which dependents it, here is my-client , actually dependent third-party-crate

//my_custon_plugin_attr/src/lib.rs
use quote::quote;

#[proc_macro_attribute]
pub fn my_custom_plugin_attr(_attr: TokenStream, input: TokenStream) -> TokenStream {
     // use types defined in third-party-crate
     let quoted = quote! {
          use third-party-crate::some_type;
          .....
    };
     TokenStream::from(quoted)
}

// my-client/src/lib.rs
#[my_custom_plugin_attr]
fn my_client_plugin() {
 ....
}

[alice]

You can re-export the third part crate from your main crate and access it via that re-export.

[eadren]

The main crate doesn't actually use third-party-crate , it only generates TokenStreams which use third-party-crate. The generated TokenStreams are in my-client-crate when using #[my_custom_plugin_attr]. Re-export cannot solve the question:

1. Since main crate doesn't use third-party-crate, if you bring types from my-client-crate into main crate, compiler will warning.
2. And also

error: `proc-macro` crate types currently cannot export any items other than functions tagged with `#[proc_macro]`, `#[proc_macro_derive]`, or `#[proc_macro_attribute]`
 --> plugin-util/src/lib.rs:5:1

[bjorn3]

You can have the main crate re-export third-party-crate and the proc macros from my_custom_plugin_attr. Then in the proc macro you can refer to main_crate::third_party_crate whenever you need third-part-crate. The user would then only depend on the main crate and access the proc macros through it.

[eadren]

I think this answer is what you mean.

Proc macros - using third party crate

The Rust solution to this, more general than just to procedural macros, are public dependencies through public reexports: //! Your `lib.rs` // 2018 edition pub use ::itertools; // old style pub extern crate itertools; and then within a macro_rules! macro, for instance, you expand to a path referring to your crate first, which must contain the itertools crate as the second element of the path / as if it were a top-level module: macro_rules! my_izip {( $($input:tt)* ) => ( $crate // …

[bjorn3]

Exactly!