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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.