Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proc_macro_attribute dependency #866

Closed
exellian opened this issue Jul 31, 2020 · 3 comments
Closed

proc_macro_attribute dependency #866

exellian opened this issue Jul 31, 2020 · 3 comments

Comments

@exellian
Copy link

Let's assume you have two user defined proc_macro_attributes in the following order:

struct Test {}

#[depends_on_inner]
impl Test {

    #[inner]
    fn test() {

    }
}

Is there any way to hand over information between these two macro executions, so that depends_on_inner knows that impl Test has a function with a #[inner] attribute?

@ehuss
Copy link
Contributor

ehuss commented Jul 31, 2020

I'm uncertain if there's a common way to relay information. depends_on_inner can parse its input and notice the presence of the inner attribute, but I'm uncertain if that's guaranteed (see #692 and its linked issues).

Questions like these should be asked on one of the user forums, like https://users.rust-lang.org/.

@ehuss ehuss closed this as completed Jul 31, 2020
@exellian
Copy link
Author

exellian commented Aug 1, 2020

Ok thanks!

@Caellian
Copy link

Caellian commented Sep 28, 2023

For future reference if anyone stumbles upon this issue:

Instead of defining #[inner] as a separate macro, process it (assuming you're using syn) by detecting it from ImplItem::attributes and then passing it to the same processor fn you otherwise would. If you need #[inner] to work on its own you must name the version bound to #[depends_on_inner] differently as order of expansion is not guaranteed and might change depending on target/version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants