-
-
Notifications
You must be signed in to change notification settings - Fork 89
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
Quote is hard to use for non-procmacro code generation #90
Comments
I believe this is fixed as of rust-lang/rust#49219. Could you try it with a 1.32 beta compiler or a recent nightly? You should see that there is no longer a dynamically linked dependency on libproc_macro. |
Great! I'll give it a go when I get the chance. |
Closing because this is no longer actionable on our end. Let me know if you find that it still does not work with a 1.32 compiler. |
Well, there's the second issue of decoupling |
Ah, this part:
Now that the libproc_macro linking story has been cleaned up such that it presents no more difficulty than linking to libcore or libstd, what do you see as the advantages of removing the dependency? Maybe that you could use quote's macros as a quasi-quoter for some other Token type? |
Closing again... As a Rust quasi-quoter, it seems essential that we produce output in the form of Rust tokens. The canonical definition of Rust tokens is what is provided by proc-macro. Other designs are possible but I would prefer to see that explored in a different crate. |
So that suggests that the canonical token code should be refactored out of proc-macro to be usable elsewhere? |
Yep! And that is proc-macro2. It provides the proc-macro canonical token representation in way that is usable elsewhere. Technically quote is implemented against proc-macro2 and not proc-macro. |
I'm using
quote
for Thrift in a stand-alone code generator. Withquote
prior to 0.4 this worked pretty well, but in more recent versions it has become more tightly coupled with proc macros. I've been working around this, but it has become increasingly difficult. Since procmacros became stabilized, it means that my codegen binary now has a dynamic linkage withlibproc_macro-*.so
which is awkward for an otherwise statically-linked binary.In the short term, it would be nice if there was also a static
libproc_macro
for this case, but I think a longer-term solution would be to either make it possible to compilequote
independently from proc macros (which isn't really possible with the feature system), or some other crate with a similar API.I'm not really sure what the practicalities of this are, but I think it would be important to make sure they share any code which depends on changes to the language so they both keep up to date as it evolves without doubling the effort.
The text was updated successfully, but these errors were encountered: