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

Quote is hard to use for non-procmacro code generation #90

Closed
jsgf opened this issue Jan 2, 2019 · 8 comments
Closed

Quote is hard to use for non-procmacro code generation #90

jsgf opened this issue Jan 2, 2019 · 8 comments

Comments

@jsgf
Copy link

jsgf commented Jan 2, 2019

I'm using quote for Thrift in a stand-alone code generator. With quote 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 with libproc_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 compile quote 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.

@dtolnay
Copy link
Owner

dtolnay commented Jan 2, 2019

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.

@jsgf
Copy link
Author

jsgf commented Jan 3, 2019

Great! I'll give it a go when I get the chance.

@dtolnay
Copy link
Owner

dtolnay commented Jan 15, 2019

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.

@dtolnay dtolnay closed this as completed Jan 15, 2019
@jsgf
Copy link
Author

jsgf commented Jan 15, 2019

Well, there's the second issue of decoupling quote from proc-macro.

@dtolnay dtolnay reopened this Jan 15, 2019
@dtolnay
Copy link
Owner

dtolnay commented Jan 15, 2019

Ah, this part:

make it possible to compile quote independently from proc macros (which isn't really possible with the feature system), or some other crate with a similar API.

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?

@dtolnay
Copy link
Owner

dtolnay commented Jan 28, 2019

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.

@dtolnay dtolnay closed this as completed Jan 28, 2019
@jsgf
Copy link
Author

jsgf commented Jan 28, 2019

So that suggests that the canonical token code should be refactored out of proc-macro to be usable elsewhere?

@dtolnay
Copy link
Owner

dtolnay commented Jan 28, 2019

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.

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

2 participants