proc-macro2 is used by most of the procedural macros out there because of its two selling points:
- Bring proc-macro-like functionality to other contexts like build.rs and main.rs.
- Make procedural macros unit testable.
This is made possible by a fallback implementation in
proc-macro2, in the case where no connection to the compiler is available.
What is the reason (technical or otherwise) that this functionality is not integrated into the built-in
proc_macro crate? And is there work being done on changing this? (If not, then I'm semi-interested in trying to do so)
It'll need a new RFC. But before you start, have a look at the old RFC in 2016
We introduce a special configuration option:
#[cfg(proc_macro)]. Items with this configuration are not macros themselves but are compiled only for macro uses.
If a crate is a
proc-macro crate, then the
proc_macro cfg variable is true for the whole crate. Initially it will be false for all other crates. This has the effect of partitioning crates into macro- defining and non-macro defining crates. In the future, I hope we can relax these restrictions so that macro and non-macro code can live in the same crate.
Thanks for the link!
I did also just find Figure out a better story around optional proc_macro · Issue #139 · dtolnay/proc-macro2 · GitHub, so it seems like work has been done in the past to try to further enable this.
Still interested if there's any new developments that I don't know about.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.