Stream: t-compiler

Topic: Proc macros in regular crates

XAMPPRocky (May 23 2020 at 23:41, on Zulip):

Would it ever be possible to have a proc Macro definition inside of a regular crate? I keep running into the case where I want to have a compile-time and run-time version of an API, which share virtually all the same internal code with different interfaces, and currently to achieve that you have to split your single crate into three-four crates, which becomes much more of a hassle to maintain and publish on

I understand why it wouldn’t be possible to both define a proc macro and use it in the same crate, but I think allowing just the definition would still be a huge quality of life improvement for me.

RalfJ (May 24 2020 at 07:51, on Zulip):

Seems to me like the problems of "compiling multiple different crates from one set of source files" remain the same when when the crate doesnt use its "own" proc_macro.

RalfJ (May 24 2020 at 07:51, on Zulip):

and AFAIK that is what makes mixing proc_macro and lib code so hard.

XAMPPRocky (May 24 2020 at 11:06, on Zulip):

That's true, and to be honest I don't even want a proc macro. I just want to be able to perform certain operations at compile time, such as reading and parsing files from a directory, and currently proc macros are the only way I know to do that.

marmeladema (May 24 2020 at 11:11, on Zulip):

I might not understand the problem fully but what about file?

XAMPPRocky (May 24 2020 at 12:59, on Zulip):

@marmeladema I want to expose a compile time API to users, a only works inside my crate. To pick a simple example I want to have std::env::var and env!.

Josh Triplett (May 25 2020 at 18:25, on Zulip):

It wouldn't work for that particular case, but some such things could be done with const fn. For those that can't, though, a proc macro seems right, and it would be nice to be able to provide one from the same crate.

XAMPPRocky (May 25 2020 at 22:44, on Zulip):

Thinking on this more I was thinking my problem is more with Cargo than rustc and having to turn my project into a cargo workspace just to support macros, I was thinking what if instead of having to set proc-macro = true, cargo had a macro target similar to bin, that could act as the place to declare the macros that exported as part of your library. E.g.

name = derive
path = macros/
XAMPPRocky (May 25 2020 at 22:45, on Zulip):


XAMPPRocky (May 25 2020 at 23:20, on Zulip):

This could also provide the benefit of being usable in your crate if it doesn’t depend on it. So it’s easier to have macros as a private implementation detail, which I have wanted more recently.

Either way I think I’ll write a post about it on internals since it’s bigger in scope.

XAMPPRocky (May 26 2020 at 00:42, on Zulip):

Internals Thread

Last update: Jun 04 2020 at 17:55UTC