Pre-expanding proc macros

[crlf0710]

Just posted another topic on this today... Sorry i didn't found this topic because of the title!

I think the major point is the pre-expansion of the usage crate, and whether the proc macro crate itself is pre-compiled is less important.

pasting the major points from that post:

I'm thinking maybe it's possible to add a new kind of dependency in Cargo.toml, maybe call it [expansion-dependencies], that acts just as normal dependencies. But instead, before uploading to crates.io, the proc macros defined in these crates got expanded and inlining the expansion results into the original source code. Only the expanded source code is uploaded to crates.io, and the dependency got automatically removed.

@Nemo157

It’s very common for proc-macros to rely on an exact version of their runtime crate by using non-public semver exempt details from them. Pre-expanding would then extend this exact version requirement to the published crate, likely causing many unresolveable dependency trees.

a proc macro crate can declare itself as able to be pre-expanded or not. For crates like thiserror and displaydoc , i think they're perfectly fittable for such pre-expansion.