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

pull out frame-support-procedural parsing and expansion logic into a separate crate #5895

Open
sam0x17 opened this issue Oct 1, 2024 · 0 comments

Comments

@sam0x17
Copy link
Contributor

sam0x17 commented Oct 1, 2024

In rust, proc macro crates are limited in that they are only allowed to export proc macros. Within substrate, frame-support-procedural has traditionally been a dumping ground for all FRAME-related macro stuff, including the macro definitions themselves (which are all just docs + a thin veneer calling internal parsing/expansion logic), macro support functions, and all of the parsing and expansion logic for things like #[pallet], construct_runtime!, etc.

In the case of substrate, this has historically been considered fine, as the only public interface Parity wants to maintain is the macro definitions themselves. That said, there are plenty of legitimate circumstances where an outside crate might want to access the parsing logic for things like pallets and construct_runtime! as a way of validating or enforcing additional restrictions, for example in a linting environment. In fact there is at least one instance in the wild already (https://github.com/opentensor/subtensor/blob/devnet-ready/support/linting/src/pallet_index.rs) where an outside project has had to fork frame-support-procedural (https://github.com/opentensor/subtensor/tree/devnet-ready/support/procedural-fork) simply for the purpose of accessing this parsing logic, in this case to enforce that all construct_runtime!s in the workspace must use explicit pallet indexing.

So my proposal is this:

Whether or not Parity wants to maintain the stuff in frame-support-procedural as a public interface, it would still be more useful to the community if it were physically possible to access these items without having to modify the crate itself.

I think it would be perfectly reasonable to:

  • pull out all of the parsing and expansion logic in frame-support-procedural
  • put it in another crate within the support directory (maybe frame-macros-core?)
  • frame-support-procedural adds that crate as a dep and pulls all its parsing and expansion logic from there
  • add a disclaimer to frame-macros-core saying everything in this crate is semver exempt and subject to change, use at your own risk.

Crucially, this approach would create zero breaking changes (the original public interface for frame-support-procedural would remain exactly the same), would put no additional burden on Parity as long as the disclaimer is in place, and quietly give the community what it wants in this regard.

Also worth mentioning, I think in reality the core parsing/expansion logic is probably the most stable code in substrate. Changes to it are usually small and merely additive, so I for one would feel perfectly safe using things like pallet::Def in other projects even if there is no official guarantee from Parity that they won't change ;)

I'd be happy to submit a PR doing this if there is general support for it :)

cc @gupnik / @ggwpez / @kianenigma

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

1 participant