How feasible would be to pre-expand proc macros in libraries before distribution?

One of my issues with Rust is how much work is repeated across many users. I wonder if pre-expanding proc-macros before distribution would be worth the complexity or if proc-macros expansion is not a big part of the overall compilation of a crate.

2 Likes

For the general case? Impossible. Proc macros can rely on literally anything. While they should be deterministic, this determinism could still be predicated on a certain file existing, for example.

2 Likes

Wouldn't this effectively bake the version of the crate hosting the proc_macro used to generate the code as an effective =ver restriction?

Not just the version of the proc-macro crate, it has implications on the runtime crate the proc-macro references. In one of my crates I have the runtime crate depend on the proc-macro with an = requirement and re-export the macro from itself. You would have to use an = requirement on the runtime crate to ensure the expanded code is valid for the runtime crate you link against (I use the internal = requirement to allow arbitrary breaking changes on the interface between proc-macro and runtime crate). That would then cause issues version resolution issues if one dependency was pre-expanded against 0.1.0 and another was expanded against 0.1.1.